土壇場でコードに数百の表面的な変更を加える
厳格な期限があり、契約で「既存のコードへの変更なし」が規定されている間、プログラマーはコードに表面的な変更を加え続けます。私はこの「態度」がどこから来ているのか疑問に思っています：DevOps？アジャイル？
実行された変更：
明示的な変数を「var」に置き換える
短い変数名を長い名前に変更する
MVCコントローラークラスへのコードインジェクションのリファクタリング
既存のコードへの（コマンドパターンのような）デザインパターンの追加（機能の変更なし）
パラメーター付きのコンストラクターをViewModelクラスに追加します（パラメーター以外のものを追加するのを忘れているため、ポストが壊れます...）
テストが行われた後の数百および数百の変更、およびマージ方法の複雑化。
これはアジャイルですか？
これらのことは、熱心に適用されている一般的な良い習慣のように聞こえます。
しかし、簡単な答えがあります
契約は「既存のコードへの変更なし」を規定します
契約について議論する必要はありません。変更を元に戻し、プログラマーを懲戒します。
これらの変更の一部は賢明であり、技術的負債を削減しますが、リファクタリングの時期があり、あなたが今プレッシャーにさらされている場合、これはその時期ではありません。
それを踏まえると、彼らはちょうど先延ばしのように聞こえます。彼らは、やらなければならない難しい仕事に取り組む必要なしに忙しく見えるようにしています。
彼らがしていることの価値について彼らに尋ねます。満足のいく答えが得られない場合は、マネージャーに渡してください。
この「態度」はどこから来たのだろう
開発者が行うことを覚えておいてください。
彼らは本質的にソフトウェアソリューションを作成しますゼロから。空気が薄い。始める前に原料の木を切り倒すことはしません。座って入力を開始するだけです（まあ、一部はそうです）。
それはほとんど「神のような」ものであり、開発者は愛彼らがある神であると「考える」だけです。それで、私たちの多くが最初にintoこのビジネスを得たのはそのためです！ （そしてはい、私は彼らの自己中心的な数の中に自分自身を数えることができた[何度も]時代がありました）。さらに良いことに、組織がアジャイルまたはDevOpsを「実行」し始めると、マネジメントは実際に開発者にplay God-「自己組織化」してすべてを「自分のために」行うように指示し始めます。
それはありますか不思議この態度が続きます。
しかしながら ...
契約は「既存のコードへの変更なし」を規定しています。
ゲームオーバー。
開発者のキーボード（またはコードリポジトリを更新するためのアクセス）を取り除きます。
明示的な変数を「var」に置き換える
型推論は優れたツールですが、真にポリモーフィックな実装では、実際にコードが壊れる可能性があります。メソッドcreatingでオブジェクトがそのサブクラスを作成するときに、Base Typeの変数を使用する非常に良い理由があったかもしれません。基本クラスに盲目的に変更すると、混乱が生じる可能性があります。
短い変数名を長い名前に変更する
コンパイラーは、変数が何と呼ばれるかを気にしません。
他の開発者mightコードベース全体でこれらの変更が壊れている規則がある場合、変数が何と呼ばれるかに注意してください。
MVCコントローラークラスへのコードインジェクションのリファクタリング
Dependency Injectionがコードベース全体で使用されており、これらの変更によってこのコードがその規則に従っている場合は、OKです。多分。
これが紹介開発者を「見栄え」よくするための依存性注入の場合、いいえ。
既存のコードへの（コマンドパターンのような）デザインパターンの追加（機能の変更なし）
パターンは、私たちの仕事を支援するツールとして存在します。既存のコードがすでにdoingその仕事である場合、これらの変更は無意味です。
私はdecadesのコードを書いてきましたが、他の人が今パターンを使用していると言っています。
誰かわかったね？
パラメーター付きのコンストラクターをViewModelクラスに追加しています（パラメーター以外のものを追加するのを忘れているため、ポストが壊れます）...
...マージ方法をより複雑にします。
そして今、私たちはrealの問題に行きます。
この開発者は何かを変更しており、breakingです。
Just Say No.
彼らがビルドを壊しているなら、彼らにfixingの仕事を与えてください。毎回。
彼らがテストスイートを壊しているなら、それを修正する仕事を彼らに与えてください。毎回。
開発者は、十分なreal、付加価値のある作業があるとは思わないか、またはnotを選択して、自分がしていることを行う想定することになるが、それはまったく別の話だ。
代わりに、彼らはこの「忙しい仕事」に専念しており、タイムシートを適切に補充しながら、他のすべての人に問題を引き起こし、最終的にはプロジェクトと、場合によっては組織に損害を与えます。
複数の問題があります。
1つの問題は、間違ったタイミングで変更を加えることです。通常は、リリース候補を作成してテストし、許容できない問題を非常に慎重に修正して再テストし、QAが許容できない問題を発見したときにリリースします。
テスト中に何百もの変更を加えると、これは完全に混乱します。これは、開発者には明らかなことです。これらの変更の値はゼロ未満です。これは開発者にとって深刻な問題です。
2番目の問題は、明らかにコードレビューを行わないことです。これらの変更が会社にとって価値のないものである場合、コードレビュー時に拒否する必要があります。私が5日間の作業を行い、さらに4時間を追加してコードレビューからのコメントに対処する場合、それは予想されることです（それがコードレビューの対象です）。誰かが5日間働き、それがすべて拒否された場合、それは別のことです。無駄な5日間です。そして、それはあなたがこの開発者を正当に非難することができるものです：5日間の時間を無駄にします。コードのレビューと拒否がなければ、文句を言うことははるかに困難です。
一方、この契約の「既存のコードに変更はありません」という用語の由来は何なのかと思います。これには理由があるかもしれません。他の誰かが「既存のコード」を開発している可能性があり、彼らが新しいバージョンをリリースすると、すべての変更が失われます。彼らは正当な理由であなたのすべての変更が彼ら自身のコードの外にあることを望むかもしれません。そのような状況では、はい、既存のコードを変更しないでください。契約がそう言っているからだけではありません。
「既存のコードに変更がない」が「不要な作業にお金をかけたくない」という意味の場合、既存のコードの変更がless全体で機能する状況はたくさんあります。これは、開発者には明らかであり、開発者以外にはまったく明らかではないかもしれません。 （一方で、この男の変更はそのカテゴリーにまったく該当しないようです）。