コード1行を変更するのに6日かかる（2015）

• 工場の稼働率は10%未満です。
• 会社の方針では、3か月を超えるバックログを作ることが制限されています。
• 方針を4か月に変更すれば、問題は解決します。
• レガシーソフトウェアの設定変更には、コード1行の変更が必要です。
• 変更を実装する過程には、チケットの提出、必要な項目の記入、取締役の承認取得が含まれます。
• その変更は、解雇を避けるために緊急です。
• プログラマーはコードの変更に成功しますが、ハードコードされた変数やその他のエラーによって問題が発生します。
• コードにはコピー・レビューとテストが必要で、その後でなければ本番環境へ移行できません。
• 必要なテスト環境へのアクセスは、権限と利用可能性の問題により遅延します。
• パラメータレコードは名前を変更し、監査証跡を持たなければなりません。
• プログラマーは必要な変更を行い、コードを再びレビューのために提出します。
• テストには、ユーザーが選択したテストケースと期待結果を含む適切なテスト計画が必要です。
• 6日後、プログラムは本番環境へ移行する承認を受けます.

[GN⁺]

Hacker News の意見

• レビュアーがコードベースの他の部分に影響する変更を求めてきたときに、それを拒否することが核心的な問題です。
• 集中したプルリクエストとスコープクリープへの反対は重要な教訓です。
• コードレビューのプロセスは、細かく厳しい指摘や些細なコメントで埋め尽くされがちです。
• セキュリティチームは、権限申請にすぐ応答しないことがあります。
• 記事のタイトルは誤解を招く可能性があり、6日間のあいだに追加の改善もありました。
• 1行の変更は、予想外の結果を引き起こすことがあります。
• コードレビューのプロセスはゲートキーパーとなり、進行を遅らせることがあります。
• コミットをブロックせずコメントを許可するほうが、より効率的な開発につながることがあります。
• 形式的なコードレビューを行うチームから、行わないチームへ移ることは、新鮮で権限を与えられる体験になりえます。
• 工場労働者とソフトウェア開発者では、管理のされ方に違いがあります。
• 変化し続けるチームの理想を基準に変更を保留するのは機能不全です。
• 問題は会社のプロセスにあり、コードレビューそのものにあるわけではありません。