コードチェックインのアカウンタビリティを確保するための最良の方法は何ですか？
注：これを書いた後、私はこの質問がおそらく哲学的であることを理解しましたが、私は業界がこのシナリオをどのように処理するかに興味があります。
私は最近、まだ十分にテスト可能ではないコードベースを使用しています。一部のジュニア開発者が、ユースケースを壊すコードをチェックインするのを見てきました。これは通常、チェックインの数日後に別の開発者によって識別されます。
コードカバレッジをまだ達成できないと仮定すると、非技術的なアプローチに加えて、開発者が悪いチェックインに対して責任を負うための技術的な解決策があります。コミットについて議論し、開発者に新しいコミットで問題に対処させる。
2つの簡単な方法：
- 各チェックインの前にコードレビュー（既に他のユーザーが言及）チェックインテキストにタグ「REVIEWED BY：...」が含まれていないチェックイン。
- チェックインがユニットテストに違反した場合、チェックインを実行した開発者は、それらのユニットテストが再び緑色になるまでコードを修正する必要があることをチームの他のメンバーに同意します（可能な対策：バグを記述して彼に割り当てる） /彼女）。別の方法として：チームメンバーがユニットテストに違反するチェックインを検出した場合、変更を元に戻すことができます。間違ったチェックインの作成者は、問題がローカルで修正されていない限り（ユニットテストがローカルで緑色である限り）、再度チェックインすることはできません。
[〜＃〜]ノート[〜＃〜]
ポイント2は、gnatのコメントを考慮して編集されています。
バージョン管理にgitを使用している場合は、gerritを確認してください。確かにそれはお尻の痛みになる可能性がありますが、コミットがリポジトリにマージされる前にコードレビューを行う必要があります。
TeamCityのような継続的インテグレーション（CI）システムを実装する必要があります。数日後に問題に気づく開発者ではないはずです。 CIシステムでは、チェックインが発生するとすぐにコードが自動的に構築され、自動テストが実行されます。チェックインから数分以内に、CIシステムはビルドが壊れていることと、それを引き起こしたチェックインを行った人に警告します。
このように、それはすべて完全に客観的であり、誰が過失であるかについて指さしていることはありません。開発者とは異なり、CIシステムはソース管理からの最新のコードのみを使用してテストを行います。ローカルの変更やファンキーな構成の違いはありません。ほとんどのシステムには、ビルドが壊れると赤に変わるトレイアイコンがあります。すべての開発者はそのアイコンをインストールし、ビルドが正常であるか壊れているかを追跡する必要があります。
あなたのチームはアジャイルスクラムコースに参加し、方法論に従う協定を結ぶ必要があると思います。
開発者が小さなタスクに割り当てられた小さなコードの変更をチェックインすると、開発者がRailsおよび競合するコードをチェックインする）可能性が減ります。これにより、継続的な統合が向上します。
「一部のジュニア開発者が、ユースケースを壊すコードをチェックインするのを見てきました。これは通常、チェックインの数日後に別の開発者によって識別されます。」
完璧な世界でさえ、これはまだ起こります。頻繁に発生する場合や、開発の数日後に発生する場合は、問題があります。
計画されたイテレーションにより、チームがより効果的に連携できるようになると思います。 2週間のスプリントを試すことをお勧めします。詳細なスクラム会議でスプリントを開始します。バグと作業項目のバックログを調べ、最優先事項を受け入れ、ユニット/時間の見積もりを付けたポストイットノートに書き留めます ポーカーカードを使用 。
スクラムダッシュボードまたはホワイトボードを並べ、人々が一度に1つのことだけに取り組むようにします。タスクが完了したら、そのための単体テストを作成する必要があります。実用的な単体テストを作成したら、コードレビューを取得する必要があります。建設的なコードレビューは、開発者が誤ってコードの競合をチェックインすることを防ぐための最良の手法の1つです。
コードレビューアがサインオフした後、開発者はチェックインダンスを行います。
- 重要な更新の場合は、変更が近づいていることをチームの他のメンバーに知らせます。
- ソース管理から最新のコードを取得します。
- 競合があればマージします。
- ビルドをローカルで実行し、見つかった問題を修正します。
- 単体テストをローカルで実行し、見つかった問題を修正します。
- 変更をソース管理にコミットします。
- ビルドが成功するまでコーディングを停止します。
ビルドが壊れた場合は、他のものをすべてドロップしてビルドを修正します。
Team Foundation Server（TFS）は、これらすべてをすぐに使用できるようにします。
次に進む前に、テストを修正する必要があります。しかし、コードの80％が単体テストされているからといって、それがバグの証拠になるわけではありません。開発者は、コードの社交性を積極的にテストする必要があります。このコード統合は、非ウォーターフォール手法を使用して実現する方がはるかに簡単です。
私は2番目のコードレビューです。 Githubプルリクエストのように、コードがコミットされる前にレビューできるツールもあります。 他のツールでは、SVNのせいなど、各行に誰が触れたかを確認できます。
個人的には、完璧ではなくても、チームメンバーが頻繁にコードをトランクにコミットすることを望みます。他の誰かが問題に気付く可能性が高まり、継続的な統合のメリットが得られます。
タスクの最後に正式なコードレビューを行います。私はまた、人々が働き、コミットするときに「ランダム」なコードレビューを行います。ランダムは引用符で囲まれています。なぜなら、テストの方法を人々によくトレーニングするために、最初はより重く見直すからです。また、ペアでテストして、開発者がスキルを習得できるように提案します。より悪いコード/テストを書く人は、ランダムなレビューのためにより頻繁に選ばれるため、ランダムも引用符で囲まれています。私はランダムなレビューを匿名にします-経営陣はそれらについて決して聞くことはありません-それらは純粋にチームの慣習です。
次のいずれかにより、ジュニアが不良コードを大幅にコミットするリスクを大幅に削減できます。
ペアプログラミング、できればナビゲーターとして上級開発者と
コミット前コードレビュー上級開発者による
これらの優れた点は、非難指向ではなくコラボレーション指向であることです。これは、ジュニアプログラマーを統合するときにIMOが確実に支持すべきものです。