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