高度なコードレビューと単体テストの実践
コードレビューと単体テストの経験がなく（必要もない）開発者のグループを管理するチームリーダーとして、コードレビューと単体テストの実践をどのように進めることができますか？
コードのレビューと単体テストが開発者のフローに自然に適合するようにする方法をどのように作成しますか？
これら2つの領域の抵抗の1つは、「日付変更が常に厳しいため、コードのレビューや単体テストを行う時間がないこと」です。
コードレビューのもう1つの抵抗は、現時点ではその方法がわからないことです。チェックインのたびにコードを確認する必要がありますか、それとも特定の日にコードを確認する必要がありますか？
チームのメンバーは、コードレビューとユニットテストは良いことだと実際に同意していますか？
または、彼らはこの言い訳でアイデアを拒否しようとするだけですか？
最初のケースでは、解決策は今すぐ開始です。 （そうです、大きなマイルストーンの前の最後の日であれば、後まで待つことができるかもしれませんが、それ以上はありません。）私の前の職場では、コーディングプラクティスの改善を担当する品質エンジニアである状況で、全体的な品質。コードレビューの開始を来週まで延期しました。ある日、これが1か月ほど続いていることに気づき、別の方法を試さない限り、おそらく最後まで続くでしょう。そこで、その週の最初のコードレビューを発表しました。私は彼らに「それが不完全になるか、私たちがまだ何をすべきか正確にわからない場合は問題ありません-私たちはそれを始めるだけで、それがどのように進むかを見て、私たちが学ぶにつれて物事を改善します」。少なくとも私が会社を辞めるまではうまくいきました。
2番目のケースでは、より多くの教育とチームとのオープンディスカッションが必要になる場合があります。コード品質の問題について話し合います（theyが開発プロセスの問題と見なしていることを尋ねます（またはその欠如）/コード内/テストなど。そしてこれらを解決する方法について一緒にブレインストーミング。最終的な目的は必ずしもコードレビューを行うことではありません。これらは単なる手段であり、目標は開発プロセスとその出力の品質を改善することです。簡単に改善でき、より多くの利益をより早くもたらす可能性のある他のより痛みを伴う問題があることが判明する場合もあります。次に、これらを最初に取ります。それらは環境やプロセスのささいな変化でさえあり得ます。これらすべてがチームの士気を高め、相互信頼を築き、チームの絆を助けるでしょう。
肝心なのは誰にも品質を強制することはできません-品質の作成の障害を取り除くことしかできませんです。事前のチームの合意なしに厳格なルールと必須の慣行を適用することで、チームを疎外し、最終的には目的の品質向上を妨げることがあります。 OTOHはオープンディスカッションを行い、チームにとって最も差し迫った問題とは何か、状況を改善する方法についての合意を目指すことで、チームのサポートを受ける可能性が高くなります。これは、長期的に品質向上の推進力を維持する上で決定的な違いをもたらします。
古典的な問題。正しく実行するのに十分な時間はありません。常に作業をやり直すのに十分な時間です。人々がベストプラクティスを開始するまで、ベストプラクティスを実行するのに十分な時間がないように思われます。特に勝利は開発以外の人々には見えないからです。
コードレビューの鍵は、できるだけ少ないコードをできるだけ早くレビューしたいということです。そうすることで、レビューする時間を確保するのが簡単になり、コードは人々の心に新鮮になり、提案された改善を実装するのが簡単になります。極端な場合は、すべてのチェックインを確認する必要があります。これを自動化する優れたツールは http://code.google.com/appengine/articles/rietveld.html です。これは、Googleが内部で使用するツールの一種で、すべてのチェックインでコードレビューを強制的に実行します。
コードレビューの課題は、数十年前の古典的なThe Computer Psychology of Computer Programmingで説明されています。問題は、プログラマーが自分のイメージをプログラミングスキルに結び付ける傾向があることです。つまり、プログラマーのスキルが十分ではないという証拠に直面するときはいつでも、個人的にそれを採用する傾向があります。これは深刻な衝突を引き起こす可能性があります。 Steve McConnellのクラシックRapid Developmentを手に入れると、そのような競合の可能性を低減するコードレビュープロセスの設定方法に関する多くの提案を提供します。 （重要な要素は、経営陣がプロセスに関与しないことを確認することです。）これにより、競合の可能性は減少しますが、競合の発生は防止されません。
とはいえ、メリットはコストをはるかに上回ります。 IBMは、1つの指標を引用すると、バグを見つけて排除するための最も効果的な方法は、コードレビューが1ドル1ドルであることを発見しました。これは、QA部門に取って代わるものではありません。しかし、その結果、発見する問題ははるかに少なくなります。そしてそれは、学習のスピードや知識の普及などのメリットを得る前のことです。
それらにオプションを与えないでください。テストとレビューを必須にします。彼らが協力しない場合は、テストされていないまたはレビューされていないプロモーションを拒否するなど、いくつかの強硬な戦術に頼ることができます。物事が本当に悪い場合は、最悪の犯罪者を解雇してください。
テストとレビューで検出されるべきバグを常に修正しているため、チームが常に予定より遅れているケースを見てきました。少し前もって作業を進めることで、長期的にははるかに多くのコストを節約できます。また、チームを一直線にするのが早ければ早いほど、チームのパフォーマンスが向上します。
残念ながら、実際に結果を確認するには時間がかかる場合があります。実践を奨励するために、バグレポートの割合、バグ修正までの平均時間、および機能実装の割合のグラフを作成できます。私は通常、約6か月のテストとレビューの後に、これらのメトリックが改善し、チームが最終的にそれを取得することがわかりました。
開発者の意に反してtddを導入することは困難です。それはtddを愛することを学ぶのは難しい方法です。
Tddはグリーンフィールドで最も効率的である（または、テストが後で実行される場合、ハードでコストがかかり、非効率的です）ので、何か新しいものを実装する小さなチームから始めます。チームで2人の開発者を見つけた場合、他の開発者よりもtddに反対ではなく、それが良い出発点です。 tdd開発者がtddに慣れていない間は、tdd開発者の生産性が低下することを覚えておいてください。
このtddの開発は、コードレビューの出発点として適しています。 tddがプログラムアーキテクチャにどのように影響したか、それがどのようにソフトウェアメンテナンスを容易にしたかを説明します。