私は3週で3回生産を壊しました

あなたは、かろうじてエラーを導入する慎重なコーダーですか?どのように、あなたはまだ生産をもたらすために管理するとき、感じますか?あなたは恐ろしいと感じるかもしれませんが、私はあなたが機会としてそれを取るべきだと思います.
あなたは新しいことを学ぶことができます.
あなたは責任を実践することができます.
あなたのチームのプロセスを強化することができます.
あなたはそれが再び発生しないように最善を尽くして行うことができます.
最近私は浮気をした.私は3週間で3生産の問題を引き起こした.あなたが我々が週に一度ロードすると思うならば、それは顕著なパフォーマンスです.
私はコンセプトを信じますextreme ownership . 私は、彼らがすべて私の責任であると話さなければなりません、そして、2つのケースで、私は大きい間違いをしました.番目の1つは、より多くの不運と少しの怠慢を考慮します.
私が書くつもりであるものは、私がインシデントの根本原因であるということを知っていることを心に留めておきます.
一般に、不完全なコードが届けられるとき、私は批評家を非難します.あなたが記事を書くとき、あなたが文書を書くとき、神は本を禁じます.あなたが自分の仕事を校正するとき、あなたはしばしばそこに書かれているものを読みません.
批評家はこの偏見を持っていない.
あなたは何かを書いて、明らかにあなたはそれが正しいと思います.評論家はそれが間違っていると仮定しなければならず、それが彼らのコードでないので、それらが誤りを見つけるのはより簡単です.
しかし、それが私のコードに関してあるとき、私はそれが私の誤りであると仮定します.私は自分の失敗を他人に責めることはできない.
時々、あなたが描く結論は、あなたの責任を越えなければなりません.
問題がどんなテストキャンペーンによっても示されないとき、彼らがどんなテストシステムにも現れないとき、何か明らかに間違っていて、彼らは固定されなければなりません.
結局、テストシステムは配送と展開プロセスを遅くするためにそこにありません.彼らは、人間が犯したエラーを検出するのに適当です.
来たるべき週に、私はあなたが最近の間に3つの誤りを共有するつもりです.
いくつかのバグの最悪の種類から始めましょう.

未定義の行動を導入することは決して素晴らしい考えではない
私はボーイスカウト規則を強く信じます

"Leave the campground cleaner than you found it."

私は個人と職業生活の両方でこの原則に従ってみます.公平であるために、私は家でより仕事でこれでより成功しています.
これは実際にはどういう意味ですか.
私はバグを修正するとき、または私は新しい機能を追加すると、私は少し周りのクリーンアップしようとします.私は過去30年間にたくさん見ているアプリケーションで動作するように、常に何かを見つけることです.
最近、約20人のメンバーと非常に長いコンストラクタを持った大きなサービスクラスに触れなければなりませんでした.
宣言は異なって散乱されたprotected and private ブロック.メンバーのほとんどは常に同じ初期値に初期化されたので、実際にはコンストラクタで定義する必要はありませんでした.
コンストラクタの本体とコンストラクタの初期化リストから初期化を取り除きました.これは良いアイデアだと思います.なぜなら、宣言時にすべてを初期化するとき、誤って命令を混乱させることができず、したがって、未定義の動作を導入することができないからです.

class A {
public:
  A();
  A(int m_foo, double m_bar);
private:
  int m_foo;
  double m_bar;
};

A::A() : m_bar(0.0), m_foo(0) {}

A::A(int foo, double bar) : m_bar(bar), m_foo(foo) {}

上の例ではm_foo はm_bar , これは以前に宣言されていましたが、これは未定義の動作とコンパイラの警告です.
長い話短い、私はこのようなものを見たいです.

class A {
public:
  A(int m_foo, double m_bar);
private:
  int m_foo = 0;
  double m_bar = 0.0;
};

A::A(int foo, double bar) : m_foo(foo), m_bar(bar) {}

それで私がしたことです.
両方の値メンバと0 , だから私はまた、初期値を更新したnullptr . 私は別の専用のステップでスマートポインタに移動することを好む.
前述のように、20名の会員が各地に散らばっていた.私はそれらのいくつかを一緒に移動したので、私は1つのプライベートと1つの保護されたセクションで終わりました.
そして、私は1つのポインタを初期化するのを逃しましたnullptr に対して0 .
それは冗談だ.
それは大きな問題ですか?
それは異なりますが、それは危険です.
私のケースでは、このポインタは多くの異なる流れに現れましたSingle Responsibility Principle - そして各ケースで初期化された.実際には、単にそれがリークされる前にポインタに割り当てられた何かがあったならば、ヒープの上に新たに割り当てられたオブジェクトに単に割り当てられました.
それは多くの流れで使用されて、初期化されました、しかし、それはすべての流れで使われませんでした.
明らかに、デストラクタは各ケースで呼ばれました.
この状況の特異性は、使用されなかった唯一の流れがタイムアウト使用ケースであったということでした.私たちには3つの異なるタイムアウトがあります、そして、3番目のものはテストでエミュレートするのが全く難しいです.
したがって、テストはこのコードを行使しませんでした、そして、我々が生産を打つまで、我々は問題に気がつきませんでした.
初期化されていないポインタを削除するのは未定義の動作であるため、コアダンプが正確な原因を明らかにしないということは常にあります.
少なくとも、それはどのクラスから来ているかを示しました、それは一種の若干の破壊についてです、そして、加えて、各々の中心ダンプで－私を信じてください、多くがありました!タイムアウトが続いた.
簡単なpeasy、右?
それは確かに問題だった.そして、私が発見したとき、私はすでにそれについてもう一つのコミットを持っていましたstd::unique_ptr s.
唯一の問題は、私たちが同じロードアイテムのいくつかのコールバックも変えたので、これがコアダンプの唯一の根本的な原因であるという仮説以上のものではないということでした.
あなたは、そのような変更が一緒に行かなければならないと主張するかもしれません.私は同じコミットにそれらを入れないようにします、しかし、あなたが週につき1つの荷を持つとき、いくつかのコミットはしばしば次の荷に詰め込まれます.
私は何を学びましたか.

ダブルだけではなく、トリプルチェック重要な変更

それは常に赤ちゃんのステップ行く価値がありません.コンストラクタの単純化をrawポインター置換から分離しました.私は用心深くなりたかった.しかし、すぐにスマートポインタの導入は、より慎重だったでしょう.

巨大なクラスを書くな.クラスがそれほど巨大でなかったならば、この問題は避けられたかもしれません.すべての置換クラスが全くこのポインタを必要としていたわけではありません.また、より小さなクラスはテストするのがより簡単でした.

テスト、テスト、テスト!

結論
このミニシリーズでは、私は生産に達したコード問題のカップルを共有しています.この最初のエピソードでは、初期化されていないポインターによってどのように定義されていないかを共有しました.
次回、私は他の2つのバグを共有します.調子を合わせなさい.

接続深い
この記事が好きなら

ボタンのようにヒット

subscribe to my newsletter

そして、接続しましょう!