開発者が自分の作品のエッジケースを継続的に無視することに対処する

私のチームの開発者の1人に、興味深い、かなり一般的な問題があります。この男は優れた開発者であり、高速かつ生産的であり、かなり良い品質のコードなどを生成します。良いエンジニア。しかし、彼には問題があります-非常に多くの場合、彼はコードのエッジケースに対処できません。

私たちは彼と何度も話しましたが、彼は試みていますが、彼はこのように考えていないようです。そのため、最終的にQAがコードに関する多くの問題を発見し、何度も何度も開発に戻して、最終的に納期を逃し、チームの全員が不満に陥ることになります。

私は彼に何をすべきか、そして彼がこの問題を克服するのをどのように助けるかを知りません。おそらく、より多くの経験を持つ人がアドバイスできますか？

彼は自分のコードの自動化された単体テストを書くことを要求します。単体テストを書くと、エッジケースを考えるように強制されます。

いくつかの詳細：

1. 彼が選ばれたと感じないようにするために、これはあなたのチーム全体に対して始められるべきです。新しいコードまたは変更するコードの自動化された単体テストの作成を全員に要求します。
2. 単体テストの名前には、テストするケースを説明する名前を付ける必要があります。
3. コードレビューで自動化された単体テストを高レベルでカバーします。レビュー担当者に、逃したテストケース（つまり、彼が頻繁に見逃しているエッジケース）を探してもらいます。彼のチームから見逃されたエッジケースについてのフィードバックがある程度あれば、レビュー前にそれらを検討することをおそらく学ぶでしょう。
4. チーム全体にこのルールを適用します。QAがバグを見つけた場合、責任のある開発者は、障害を確認し、修正したことを証明する自動テストを負います。（他の作業を行う前）

彼にチェックリストを与えます、例えば

• ヌル入力
• 範囲の極端に大きい入力
• 範囲の極小端での入力
• 組み合わせ
• 想定される不変条件に違反する入力（x = yの場合など）

QA担当者はチェックリストの作成を支援できます

これだけでなく、すべての開発者にチェックリストを提供します。

良いエンジニア。

はい。

しかし、彼には問題があります-非常に多くの場合、彼はコードのエッジケースに対処できません。

優れたエンジニアが共有しない品質です。

エッジケースを監視することは、人に存在するかどうかの特徴です。エンジニアやプログラマーとは関係ありません。この特性の発達は、文化的背景、生活環境、子供時代の出来事、および人生経験に影響されます。それから、態度は単に個人がしている仕事に適用されます。

あなたが必要なのは、あなたの男が、この特定の感覚が（おそらくまだ）発展していないタイプかどうかを調べることです。また、何らかの理由で彼が気にかけない可能性も非常に高いです。彼が仕事に満足しているかどうか、状況全体を分析する必要があります。そうでない場合は、おそらく彼を助けるために何かをする必要があります。

彼は仕事に満足しているが、まだエッジケースの危険性を経験していない場合は、彼を教育し始めることができます。彼がそれを真剣に受け止めれば、彼は時間の経過とともに彼のやり方を変えるかもしれません。これには懐疑的ですが、試してみることもできます。

しかし、彼がエッジケースが苦手なタイプの人であることが判明した場合、チームから彼を取り除く以外に何も残っていない可能性があります。この特性は、実用的なプログラミングに不可欠です。悲しいことに、それなしでは偉大な人でさえ良い仕事をすることができません。

プロセスの早い段階でコードレビューやデザインレビューを行うことはできますか？

テストファーストをプログラムするように彼に教えてください。彼とペアリング。テストケースを作成し、テストに合格するためのコードを作成します。

QAを機能開発の早い段階で関与させることで、カバーする最初に近いエッジケースのリストを提供できますか？開発者がすべてをカバーすることを期待していないと考える人もいるかもしれませんが、テスターが最初にキャッチする可能性のある境界ケースを見逃す傾向がある場合、これはこの問題を回避する方法かもしれません。

私がここで持っている他のアイデアは、彼がこの問題をどのように見ているかということです。彼は本当にこのパターンに腹を立てて自分自身をカチカチさせたのでしょうか、それとも彼はこれを通常のように見ているだけで、解決するために心配するものではありませんか？確かにこれには大きな信頼が必要であり、彼の視点で彼をオープンにする必要がありますが、彼の視点から物事を見ることができるなら、ここにある程度の共感があると思います。

エッジケースは無限にあり、それらをすべてカバーすることは不可能です。誰かがどうしたら#define TRUE FALSE？それはエッジケースを追加します、あなたもそれらをチェックしますか？

また、プライベートクラスまたは内部関数のすべての関数をだますことを検討しません。

非常に堅実で安定している必要があるコードに私が選択するアプローチは次のとおりです。

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

このようにして、QAで確実なアプリケーションダンプを取得し、リリースに到達するまでに、アプリは確実で安全になります。

エラーの回避は悪いです。ファイルハンドルがnullでnullを返す場合、関数を保存できますが、ほとんどの場合、どこかにデザインエラーがあり、アプリのクラッシュは原因を見つけることを強制するより良い方法です。ほとんどのエッジケースは、問題を隠すことでエラーをマスクするだけです。たとえば、ボタンは機能しなくなりました。クラッシュは、製品に関するいくつかの仮定が間違っていることを伝え、クラッシュの原因となったロジックを修正する必要があります。

それがエッジケースである場合、それを考慮する必要さえありますか？エッジケースが重要な場合、エッジケースを要件/機能/ユーザーストーリーにフィードする必要があります。

エッジケースが作業の一部と見なされ、デバイスを所定の場所に配置する必要がある場合、それらはワークアイテムの一部である必要があり、定義により、エッジケースを処理するメカニズムが完了するまでワークアイテムは完全ではありません所定の位置に。

これにより、チームリーダーとして、作業後の議論で作業が完了した後にチェックオフするものが得られ、開発者が作業を完了するときにチェックオフすることができます。

エッジケースをキャッチすることがQAの存在理由です。プログラマには、タイムリーに作業をプッシュする責任があります。エッジケースを探すためにすべての時間を費やすことは非常に非効率的です。適度に速い反復サイクルがある場合、これはまったく問題ないはずです。エッジケースの数は無限に近いです。「コア」のケースに問題がある場合、少し心配になるでしょう。開発者が開発の専門家であるように、テスターはテストの専門家でなければなりません。テスターが問題を見つけると、開発者に送り返します。開発者が問題を修正します。問題が解決しました。開発者がすべてのエッジケースを追跡する時間は、反復テストサイクルに要するよりもはるかに長くなります。また、テストについて説明するとき、ホワイトボックスユニットテストではなく、厳密にブラックボックステストを意味します。

これは、テストドリブン開発が救助に役立つと考えているケースの1つです。これは、エッジケースやコードを破壊する可能性のあるものについて考えるのに役立つためです。