大きな変更の提案/インターンとしての書き換え
コンテキスト：
- これは内部プロジェクトです（多くの人が使用しているとは思いません）。
- それは古いです
- 私たちはそれを更新しています
問題：
- mVCフレームワークを悪用します（モデルの使用、ビューでのビジネスロジックなど）
- 私たちが求められていることは小さいですが、凝集度が低いため、2つの選択肢があります。
- 物事を失敗させ続ける
- 大量のコードを移動したり、書き直したりする
ソリューション（なるほど）：
- 引き続き作業し、ベストプラクティスを無視して、すぐに完了するようにし、リファクタリング/リライトによって新しいバグを導入しないようにします
- リファクタリング/書き換え
私の質問は本当にそうだと思います：このプロジェクトに大きな変更を加えたい場合、誰を侮辱せずにそれを提案するにはどうすればよいですか？または、たとえそれが（比喩的な）ダクトテープを意味する場合でも、単に流れに進む方が良いでしょうか？
OKはい。
あなたは、アプリケーションが不適切に構造化され、不適切に記述されていると考えています。
顧客はそれが仕事をしていると思っています。
あなたは、その「内部の美しさ」を改善すること以外の理由でそれを書き直したくないのです。
そのため、アプリケーションに現在の機能を正確に実行させるためにお金をかけるよう顧客に求めています。ユーザーが見たり理解したりできない部分だけが何らかの形で「より良く」なります。
不適切に書かれた不適切に構造化されたコードに対する主な反論は、理解するのが難しいということです。
このコードは理解するのが難しく、適切に構造化されていないアプリケーションに簡単に実装できる機能を備えています。したがって、これが非常に得意でない限り、新しいアプリケーションは現在のアプリケーションとまったく同じことを行うことはありません。また、元のコードが何をしているかを完全に理解していないため、おそらくそれは間違っています。
したがって、お客様は現在、元のアプリケーションよりも著しく悪いアプリケーションを入手するために多くのお金を費やしています。あなたは人気がなくなるでしょう！
幸いなことに、あなたのより経験豊富な大学はあなたをユーモアを向ける準備ができています（おそらく彼らが始めたときに同じ過ちを犯したためであり、そのような悪い運命のプロジェクトのために経営者の承認を得ることさえ不幸にさえしたかもしれません）。
したがって、私のアドバイスは、古いコードベースを実行し続け、静かにすることです。お客様は、コードが醜いと思っても機能しないシステムを望んでいます。
変更を提案します。それぞれのビジネスケースについてclearになる：提案された変更がシステム全体に役立つのはなぜですか？そうでない場合は、プッシュバックを期待してください。なぜ壊れていないものを修正するためにお金を使うのですか？システムをより拡張可能にすることや懸念の分離などの理由かもしれないは有効です（だれと話しているかによって異なります）が、99％の場合、「正しく実装されていない」とだけ言うことになります。あなたはどこにも。 （コードをクリーンアップしても）make workを提案するだけでなく、プロジェクトに付加価値があることを確認してください。
残念ながら、プロの世界では、何かが間違って実装されたからといって、それが壊れているという意味ではなく、したがって修正の必要もありません。また、それを修正する際に、プロジェクトの他の領域に影響を与える可能性のある予期しないノックオン問題が発生する可能性があります。
あなたの質問を読んで、I'm実際には、アプリケーションを書き直すことは価値があるかどうか懐疑的です。たぶん、あなたはあなたの質問で完全な主張をすることを気にしなかったでしょう。しかし、それが古く、めったに使用されない内部アプリケーションである場合、書き換えの利点がコストに見合うものである可能性はどのくらいありますか？書き換えのコストは、それが持つすべての更新とパッチの合計よりも高くなる可能性があります。
それが真実ではないと思われる場合は、ここで行ったよりも多くのケースを作成する必要があります。
アプリケーションの改善に関しては、更新の過程で自然に発生する少しのリファクタリングの可能性があります。
あなたはインターンです。おそらく、あなたは真新しいです。 おそらくばかを疑っている
だからあなたが提案をし始めると、軽く踏みます。控え目で気取らないこと。他のメンバーがコードベースについての自分のアイデアやメンバーのプレッシャーについて話し合うことができるように、アイデアを会話で流します（クリーンアップのために努力が払われていない理由は非常にあります）。
あなたは彼らの信頼を獲得したいのです。 これは、与えられたタスクに適したコードを記述することによって行います。明確に記述し、実装したいベストプラクティスを使用しますが、あなたに割り当てられていることについて。これらはおそらく小さなものであり、チームの他のメンバーはおそらく重要ではないと考えるものです。それらのことをうまくやってください。あなたがいる場所の隅を明るくしてください。チームがあなたのコードを好意的にレビューするようになると、あなたのアイデアもまた成長していきます。
最終的には自分の能力と知識を実証するときに、1つまたは2つの提案を引き出すことができる場合があります。
私は完全にこの提案をしますしかし仲間の開発者にのみ。経営陣がそれをある種の境界を越えるようなものとして見ていると想像するので、私は経営陣にそれを持ち出しません。
一緒に作業している開発者に提案をした後、彼らはおそらく、コードベースがどういう理由でそれがそうであるかについていくつかの良い理由を持つでしょう。その理由は、「いいえ、実際にはコードは問題ありませんが、MVCを理解していない（それがインターンの理由です）」から「それは素晴らしいアイデアです。新しいアプリケーションを一緒に構築しましょう！」
このアプリケーションのリファクタリングに対する答えはおそらくノーであることに留意してください。私は、インターンが内部アプリケーションの書き換えを引き継ぐことを望んでいません（インターンシップが完了し、書き換えが半分しか終わっていない場合はどうなりますか？）さらに、内部アプリケーションを操作することよりも、もっと重要な作業を行うことができます。 。
しかし、仲間に尋ねることは決して害はありません。そうすれば、あなたは何かを学びます。そして、7983879342がインターンシップのすべてです。
何が起こっても、次のメッセージを削除してください。上記の応答の一部でコードの書き換えが指摘されている場合があるため、最良の技術的な理由から、ビジネス/コストの理由で実行できない場合があります。あまりにも多くのプログラマーが技術的なソリューションに住んでおり、技術的な優雅さ/読みやすさ/ベストプラクティスに対する彼らの個人的な探求は、物事を成し遂げるためのビジネスのニーズによってバランスをとられるべきだと考えることを拒否します。私の個人的な経験では、そのバランスを（どちらの方向からも）打たない人は、チーム内の責任と見なされることがよくあります。
しかし、物事に疑問を投げかけるのをやめないでください。ノックバックがあったとしても、それは私たちが学び、成長する方法です。
他の答えはあなたの状況の政治について多く話しました、そして私は同意する傾向があります。説得力のあるビジネスケースを提示できない限り、書き換えはおそらくカードにはありません。
ただし、これは Boy Scout Rule を忘れてはならないという意味ではありません。
あなたがそれを見つけたより常にキャンプ場をきれいにしておいてください。
このコードベースに何かを実装しているときに、設計または実装の一部の側面をクリーンアップする方法を考え出すことができる場合は、それを考慮する必要があります。 MVCモデルをより有効に利用するためにアプリケーション全体を書き直す必要は必要ありません。また、新しいビジネスロジックを実装する場合特定のビューでは、ロジックを古いビューからモデルに移動し、それに新しいロジックを追加することを検討できます。
他の人が述べたように、実装の方法/理由を理解できるように、別の開発者（このアプリケーションに詳しい人）に簡単なウォークスルーを依頼してください。技術的な側面は理解できるが、ドットをビジネス要件に関連付けることができるようにしたいことを説明します（ビジネス要件はすべてに勝ります）。
この情報を入手したら、評価を行うことができます。個人的には書き直すべきだと思っていても、他の人がそれを時間の有効な利用法だとは思わない場合は、個人的なプロジェクトとして考えてください。ここに1時間/ダウンタイムがある場合でも、「正しく」実装してください。完了したら、それを他の開発者に「ちょっと、これでクリーンアップができると感じたので、ダウンタイム中にいくつかの副次的な作業を行いました。どう思いますか？」と提示します。それらに変更を押し付けないでください-「ちょっと、あなたたちはこのような人たちですか？」そこから行きます。
あなたが上手に尋ねて論理的なケースを作るならば、書き直しを提案することに害はありません（単なる直感またはそれを行うためのより良い方法ではありません）。使用頻度の低いアプリケーションの書き換えは失敗する可能性が高く、最初にシステムを作成した人がまだそこにいて（そしてあなたよりも階層が高く）、好意的に批判を受け入れない可能性があります。
したがって、「基本的なMVCの原則に違反する、この恐ろしく設計されたシステムを書き換える必要がある」とは言わないでください。適切な上級者（真上にいる人）に公開質問してください。 「MVCモデルでシステムを書き換えることで、長い目で見れば多くの時間を節約できるのではないかと思っています。どうすればよいでしょうか。大規模な書き換え（たとえば2週間）でメンテナンス時間を半減できると思います。 MVCモデルを組み込んだり、TDDなどが行われたり、2か月の定期的なメンテナンスの後でさえ、我々は壊れます。」私たちがあなたの時間の見積もりと新しいシステムが適切な代替品になる可能性には同意しません。または、応答はそれでいいかもしれませんが、新しいシステムが、人々があなたを非難するだろうと提案した期間内の新しいシステムよりも良い/良いように動作しないかどうか覚えておいてください。そして、システムがほとんど使用されていなくても、書き換え期間中は、マイナーな修正で更新を停止することは受け入れられない場合があります。
ほとんどの変更は、原則として段階的に行われます。
覚えておくべきいくつかのこと;
- アプリケーションの履歴は何ですか？
- 今日はなぜ醜いのですか？
- アーキテクチャの変更のメリットは何ですか？
良い戦略は、小さなことに取り組み、ものについてたくさんの質問をすることです（Googleまたはソースから学ぶことができない質問、人々の時間を無駄にしないでください）。コードベースと開発者に慣れたら、なぜコードが現状通りであるかをよく理解できるはずです。時々、それは「ええ、私たちは何かを一緒にハックしてドアの外に押し出さなければなりませんでした」というだけです。通常の作業を進めるときに発生するシステムの小さな部分に穏やかな変更を提案できる場合は、根本的な書き換えよりも多くの牽引力が得られます。