policy - 「壊せば買う」が最善策か？

Question

それが良くないかもしれない微妙な理由があります: 何かを壊したことの責任は、関係のないはずの変更を加えてコードを壊した人ではなく、自動化されたテストなしで壊れやすいコードを書いた個人に本当に責任を負わせるべきです.何処か別の場所。

想像できる例の 1 つは、誰かが実装時の動作に固有の動作を想定しているが、既存のコントラクトでは保証されていない方法で、インターフェイスに対してプログラミングを行う場合です。次に、他の誰かが契約に適合する実装に変更を加えますが、依存するコードを壊します。依存するコードに対してテストが作成されていないため、失敗するテストはありません。本当に誰のせい？

これは人のせいにするのではなく、責任を理解することを目的としており、「壊せば買う」というのはとても良い方針です。

編集：私はこれを本当に下手に言いました。隠れた依存関係を含め、依存関係に関して正しいソフトウェアを作成する方法について説明するつもりでした。これは、予期せぬバグが見つかったときにどうするかではなく、バグを回避することはプログラマーの責任であるという問題であることを意味していました。しかし、すでに多くの回答が寄せられているので、質問をそのままにして、それに応じて回答を示します。

Answer 1

非難と非難の雰囲気を助長することで、得るものは何もなく、失うものはすべてあると思います。何かが壊れたときは、その問題を修正するのに最適な人に割り当てる必要があります。その人がその領域を知っているためにその領域に最後に触れた人であろうと、それを最初に書いたので設計哲学を最もよく知っている人であろうと。 、またはそれ以上の差し迫ったことのない人でさえ。

Answer 2

「壊せば買う」というのは、ビルドを壊すという意味では理にかなっていますが、より深刻な問題ではありません。

ビルドをコンパイルできない状態にしたり、基本的なテストを実行したりすると、他の人の作業がブロックされます。簡単で簡単な修正が見つからない場合 (簡単で簡単なバグを導入したため)、変更をロールバックして (おそらくその間に作業したもののローカル コピーを使用して) コミットします。

ビルドを壊したという事実が最終的にはより広範な問題によるものである場合は、修正、報告、割り当てのいずれかによって、そのより広範な問題に対処してください。

短期的には、コードベースを動作不能にした人は、すぐに再び動作可能にします。長期的には、（さまざまな要素のバランスをとって）その仕事に最適な人が仕事をします。

Answer 3

それを修正することは、責任を負わない目的です。壊れやすいコードの元の作成者が移動した場合、誰が問題を所有するでしょうか? 彼または彼女が単に別のプロジェクトに割り当てられたとしますか? 問題に遭遇した人は、問題が修正されるまでその所有者である必要があります。彼または彼女は、現在そこにいて、アプリケーションに変更を加えるタスクに現在割り当てられている人です。

将来回避すべき問題を抱えてコードが作成され、元の開発者がまだそこにいることがわかっている場合は、問題とそれが問題を引き起こした理由について彼または彼女に知らせるのは良いことですが、最終的には問題に遭遇した人は、新しいコードを機能させるために問題を修正する必要がある人です。

Answer 4

災害が発生しやすい人に所有権を割り当てることが、常に最も生産的な戦略であるとは限りません。それはおそらくそれ自体の報酬です。

Answer 5

最後に触れた人に責任があるはずです。リファクタリングはソフトウェア開発の大部分を占めています。誰かがコードに触れて、コードを適切に文書化、作成、テストしなかった場合は、その人が書いたものよりも優れています。見積もりの​​一部として、コードを見つけたよりも良い形にするための時間を含める必要があります。

そうは言っても、何かがうまくいかない場合は、チーム全体で失敗する必要があります。

Answer 6

人々が協力しなければならない環境では、責任を追及するよりも協力が重要です。誰かのモジュールが壊れやすく、仲間がそれについて何かをする必要があることに同意した場合、優れたチームプレーヤーが問題を解決します。つまり、彼は単体テストなどを作成します。

いずれにせよ、プログラマー自身のコードは最終的にプログラマーの責任であり、自分のコードを他の人のコードと連携させる責任を処理できない場合は、正当に責任を負わなければなりません。しかし、彼らに彼らの行為を片付ける機会を1つか2つ与える前ではありません.