コードを整理することは、期限を守るよりも優先すべきだと上司を説得する必要がありますか？
私のマネージャーは厳しい期限があります。
私が取り組んでいる現在のプロジェクトは現在予定通りですが、コードの非常に不適切に記述された非常に重要ないくつかの領域に気づきました。 （コードのビットは、1回だけ呼び出す必要があるときに、2〜3回呼び出されます。）
問題は、私のマネージャーに関する限り、プログラムが機能することです。彼がそれを見ているように、彼が見ることができる具体的な改善のために、リリース日を見逃すことになるコードに長い変更を加える意味はありません。彼は、「それは優先事項ではありません。現状では問題なく機能しています。」と言い続けています。
私は彼を説得しようと試み続けるべきでしょうか、それとも彼が提案することをしてそれを残すべきでしょうか？なぜか、なぜそうでないのか？経営陣を説得するための how はすでにカバーされていることに注意してください。
彼はボスであり、それは彼の決定です。そして私は彼に同意します。コードを変更するためにコードを変更しないでください。変更の正当な理由がある場合（たとえば、以下の要件をそのまま実行するとします）は変更する必要がありますが、「十分ではないと思う」は正当な理由ではありません。
あなたの宗教的熱意（そしてそれがこの段階であるか、そうであるように見える）は費用がかかり、リスクをもたらします（コードを変更するたびに製品が破壊され、より多くの変更、より多くのテスト、より多くの遅延が必要になります）。それは決して良いことではありません。
代わりにメモを作成し、アプリケーションの影響を受ける部分を変更する必要がある場合はいつでも変更をピックアップします。
私のマネージャーは厳しい期限があります。
ほとんどがそうです。
現在取り組んでいるプロジェクトは現在予定通りです
良い。そのままにしている！
コードの非常に重要な部分が2つあり、それらの部分が実際に不適切に記述されていることに気付きました。 （コードのビットは、1回だけ呼び出す必要がある場合、2〜3回呼び出されます。）
それが大きな正しさやパフォーマンスの問題ではない場合は、それほど悪くは聞こえません。同じコードを不必要に2回呼び出すことは、多くの場合、1回呼び出して結果をキャッシュするよりも優れています。キャッシングロジックの欠陥に起因する多くのバグを見てきました。しかし、これは悪いコードであるとあなたの言葉で考えてみましょう。
問題は、私のマネージャーに関する限り、プログラムが機能することです。彼がそれを見ているように、彼が見ることができる具体的な改善のために、リリース日を見逃すことになるコードに長い変更を加える意味はありません。 「それは優先事項ではありません。現状では問題なく機能しています。」
あなたのマネージャーは正しいです。あなたは、利害関係者に価値を提供するビジネスに携わっており、コードのプリティフィケーションビジネスに携わっていません。コードをきれいにすることでリリース日を打つよりも多くの価値が利害関係者にもたらされるという主張をすることができない場合は、その主張をしないでください。
私は彼を説得しようと試み続けるべきですか？
番号。
私は彼の提案をそのままにし、それを残すべきでしょうか？
番号。
むしろ、締め切りに間に合った後、「コード品質マイルストーン」のスケジュールを立てるように管理者を説得する必要があります。期限が切れて次のバージョンを計画している場合、最初に行うべきことは、リリース後の分析をスケジュールして、何がうまくいったか、何がうまくいかなかったかを詳しく調べます。これには、将来の成功へのリスク、などのリスクの分析、既知の問題でチェックインされた品質の悪いコードが含まれます締切に間に合うように。 「品質マイルストーン」のために取っておいた時間を使用して、それらのリスクを軽減します。対処したい問題の正確なリストを備えた会議に出席できれば、助かります。
そうすることの議論は、そうすることによって、あなたのマネージャーが将来の締め切りを守り続けることを保証するのを助けることです。
ここにいくつかのポイントがあります：
- すべての変更により多くのエラーが発生します。複雑なコードを変更すると、修正できないエラーが発生します。理想的には一度書いて、決して変更しないことです。新しいコードを追加してもかまいませんが、既存のロジックを変更すると、さらにエラーが発生します。最終結果が初めての混乱である場合、元の混乱をもたらしたすべてのルールを覚えておかずに修正すると、どれほど悪い結果になるか考えてください。
- 複雑なコードは常に悪いように見えます。コードは理由により複雑です。重要なビジネスロジックをエンコードしますが、これは常に複雑です。すべての複雑なコードは、コードが従う規則を知らない人にとって混乱のように見えます。ルールが分かれば、正しく機能するのは素晴らしい論理システムです。ルールを忘れて（最悪の場合、誰かがコードを書いて、ルールを持っていなかった）、重要なビジネスロジックは混乱していると考えるようになります。このようなコードのクリーンアップは大きな間違いです。
- 時間の経過とともに、ビジネスルールは古くなります。これで巨大な混乱が発生し、ソフトウェアにエンコードされたルールの半分が古くなっています。もう書き直す時ですか？絶対にありません。すでにソフトウェアのソースコードにエンコードされているビジネスルールを取り除く唯一の方法は、システム全体をダンプすることです。そうしないと、ソフトウェアの1つの欠けている部分が、過去10年間正常に機能していた無関係なコードの障害をアクティブにするカスケード障害になってしまいます。
- メンテナンスは難しいアクティビティです。混乱を維持するにはスキルが必要です。変更を加えるには、過去10年間に収集されたすべてのビジネスルールを知る必要があります。それらの1つを忘れると、変更により、修正よりも多くの損傷が発生します。新しいロジックを挿入することをお勧めしますが、古いロジックは変更しないでください。リファクタリングまたはリライトは、問題に対処するための間違った方法です。動作するコードを書き始める必要があり、後で修正する機会に決して頼らないでください。チャンスは決して現れません。コードにエンコードすると、具象のようになります。常にそこにあり、破壊するのは危険です。
多くのマネージャーは、「技術的負債」の概念を理解していません。これは、あなたが積み上げを止めようとしているものです。
修正したいこのセクションだけのコンテキストでは、マネージャーは正しいですが、時間の経過とともに多くのセクションが劣化し、他の開発者がその上に構築する場合、これは本当に問題になります。
次に、コードの一部でバグが発見されますが、1つのセクションでのみ修正され、コピーおよび貼り付けられたセクションでは修正されません。
あなたはまだライブに行っていませんが、管理者がおそらく考えていることを覚えておく必要がある他の事柄があります。
たぶん、このコードの作り直しは、大規模なテスト段階を繰り返す必要があることを意味します。以前に機能していた機能にバグが発生する可能性もあります。
これらのことを指摘するのはあなたの仕事ですが、それでもマネージャーの決定です。
ただし、今後これらの問題を回避するために、開発プロセスに変更を加えるようにしてください。
- 繰り返し発生する問題を特定し、すべての開発者を望ましい方法でトレーニングします。誰もが最初にこれを正しく行うつもりはないので、コードレビューでキャッチする準備をしてください。このようにして、マネージャーがコードが十分に機能していることを確認する前に、時間をかけて変更を加えることができます。
- 見積もりに＃1の因数分解を開始します。チームは時間とともに改善しますが、前もって期待をうまく管理できます。
うまくいけば、あなたの締め切りは、開発者が構築するのにかかるだろうと思った時間に基づいて確立されたものであり、他の恣意的な方法ではない。一部の開発者は、長期にわたるプロジェクトの見積もりを行う場合、悪いニュースの担い手であると感じているため、過度に楽観的になることでそれを回避しています。
これは主観的な質問であり、これが私の見解です。
あなたは彼を説得しようとするべきです。ここでこの質問を書いたという事実がそれに答えます。どれだけ難しいかは別の質問です。
システムのさまざまな部分について考えます。
- そのモジュールの開発はどのくらい進んでいますか？
- 同じモジュールが将来大幅に変更される可能性はどのくらいありますか（仕様変更）。
- モジュールのパブリックインターフェイスは変更されていますか？
これらの質問を自問して、自分の長所/短所を作成してください。
たとえば、モジュールがほぼ完成し、リリース後に変更される可能性が高い場合は、後で使用するためにリファクタリングをそのままにします。しかし、それが初期段階にあり、仕様が変更される可能性が低い場合は、できるだけ早くリファクタリングしてください。仕様が変更されるため、2年間で厄介なコードを調べなかった後は、新しい仕様の実装に苦労することになります。変更。モジュールを最初から作成して、以前のバージョンのモジュールのコードの一部のみを使用することを決定するほど悪い場合があります。
マネージャーにあなたにリファクタリングをさせさせるいくつかのトリックがあります。
- 既存のコードのバグを見つけます。バグを修正する間、リファクタリングに時間を費やすことができます。
いいえ、すべきではありません。 締め切りはコードの整理よりも重要です。なぜなら、最初に締め切りが設定された理由がおそらくわからないからです。多分あなたはあなたの顧客を盗むだろうあなたの競争相手の前に終えなければならない。または、いくつかの法律が施行されます。あるいは、飢えたCIOにとっては高額になりすぎているのです。または...
リリースすることが大きなリスクになると思われる場合は、上司に説明してください。有効な理由は次のとおりです。顧客データが失われる可能性がある、会社の評判が損なわれる、または会社に悪影響を与える何か他のもの。しかし、あなたのマネージャーはリスクと機会を熟考する必要があり、彼は締め切りを移動する価値があるかどうかを決定しなければなりません。
しかしマネージャーに追加のリソースをスケジュールするように依頼します次回。ソフトウェアが大きくてメンテナンス不可能なモノリスにならないようにします。そうすれば、マネージャーは期限を守ることができ、十分なソフトウェアを作成するのに十分な時間を確保できます。
何をするにしても、プログラマーを、ビジネスについて何も知らない象牙の塔の人々と考える理由をマネージャーに与えないでください。
新しく作成されたアプリケーションであると読んだので更新します。
あなたの第一の優先事項は根本原因分析をして最初に悪いコードが書かれた理由を見つけることです。要件は変更されましたか？プログラマーの1人は十分なスキルがないのですか？締め切りは忘れ去りの態度を引き起こしますか？
特に問題がコード内のコメントで適切に文書化されていない場合は特に、コードの問題により、メンテナンスの非現実的なタイムラインが作成される可能性があります。
ほとんどのマネージャーは、自分の仕事を遂行するのに十分な技術的理解を持っていますが、コーディングの方法を知らず、問題が将来のタイムラインにどのように影響するかを理解していません。
私はあなたのマネージャーに近づきます書面でそして、問題が手付かずで未解決のままでいることを許可することによって、今後何が起こり得る（そしておそらくそうなる）かを彼らに概説します。これには、更新のために将来変更するときに影響を受けるタイムライン、アプリケーションのパフォーマンスの低下（ユーザー満足度の低下）などが含まれる場合があります。問題の影響を理解して決定を下したら、それを受け入れて次に進みます。 。この時点で、あなたは信頼できる信頼できるプログラマーとして（あなたが持っていることを証明する書面で）仕事を終え、ボールはあなたが概説した問題に関連する問題の責任を負うことで彼らの法廷にいます。