大きな変更を提案する/インターンとして書き直す[終了]

コンテキスト：

• それは内部プロジェクトです（多くの人が使用するとは思わない）
• 古いです
• 私たちはそれを更新しています

問題：

1. mvcフレームワークを悪用します（モデルの使用、ビューでのビジネスロジックなど）
2. 求められていることは小さいですが、凝集度が低いため、2つのオプションがあります。
   1. 物事をやり続ける
   2. 大量のコードを移動したり、コードを書き直したりする

ソリューション（私が見る）：

1. 引き続き作業し、ベストプラクティスを無視して、すぐに行われ、リファクタリング/リライトによって新しいバグを導入しないことを支持する
2. リファクタリング/書き換え

私の質問は本当にそうだと思います：このプロジェクトに大きな変更を加えたい場合、誰をin辱せずにそれを提案するにはどうすればよいですか？それとも、それが時々（比means的な）ダクトテープを意味していても、単純に流れに行く方が良いでしょうか？

OK

あなたは、アプリケーションがひどく構造化され、ひどく書かれていると思います。

顧客はそれが仕事をしていると考えています。

「内部の美しさ」を改善する以外の理由で書き直したくない場合。

そのため、顧客にアプリケーションに現在の動作を正確に実行させるためにお金を使うように求めています。ユーザーが表示または理解していない部分のみが何らかの形で「より良く」なります。

ひどく記述されたひどく構造化されたコードに対する主な反対は、理解するのが難しいということです。

コードを理解するのは難しく、機能や機能は構造の悪いアプリケーションでのみ簡単に実装できます。したがって、これが非常に得意でない限り、新しいアプリケーションは現在のアプリケーションが行うことを正確に実行できません。元のコードが何をしていたかを完全に理解していなかったため、おそらく間違っているでしょう。

そのため、顧客は元のアプリケーションよりも著しく悪いアプリケーションを取得するために多額のお金を費やしています。あなたはポピュラーになるつもりはありません！

幸いなことに、あなたの経験豊富な大学はあなたをユーモアで準備する準備ができています（おそらく、彼らが始めたときに同じ間違いを犯し、そのような不運なプロジェクトのために経営陣の承認を得る不幸があったからです）。

したがって、私のアドバイスは、古いコードベースを実行し続け、静かにしておくことです。顧客は、機能するシステムを望んでいるだけで、コードがいと思っても気にしない。

変更を提案します。ことが明確にそれぞれのビジネスケースで：なぜ、あなたの提案になる変更のヘルプは、システム全体として？そうでない場合は、プッシュバックを期待してください。なぜ壊れていないものを修正するためにお金を使うのですか？システムの拡張性を高めたり、懸念の分離を行うなどの理由は有効な場合があります（話し相手によって異なります）が、99％の確率で「正しく実装されていない」と言うだけでは何も得られません。（コードをクリーンアップしても）make workを提案するだけでなく、プロジェクトに価値を追加していることを確認してください。

残念ながら、プロの世界では、何かが間違って実装されているからといって、それが壊れているわけではなく、したがって修正する必要はありません。また、それを修正する際に、プロジェクトの他の領域に影響を与える可能性のある予期しないノックオンの問題を引き起こす可能性があります。

あなたの質問を読んで、私は実際にアプリケーションを書き換えることはそれだけの価値があると懐疑的です。たぶん、あなたはあなたの質問で完全なケースを作ることを気にしませんでした。しかし、古い、めったに使用されない内部アプリケーションである場合、書き換えの利点はコストに見合うだけの可能性がありますか？書き換えのコストは、それが持つすべての更新とパッチの合計を上回る可能性があります。

そうでないと思う場合は、ここで行ったよりも多くのことを主張する必要があります。

アプリケーションの改善に関しては、更新の過程で自然に発生する少しのリファクタリングの機会があるかもしれません。

あなたはインターンです。おそらく、あなたは真新しいです。彼らはおそらくあなたがばかだと疑っています。

したがって、提案を行う際には、軽く踏み込んでください。謙虚で控えめであること。他のメンバーがコードベースに関する独自のアイデアや彼らが受ける可能性のある圧力について話し合うことができるように、あなたのアイデアを会話で流してください（物事を整理する努力がなされていない非常に良い理由があるかもしれません）。

あなたは彼らの信頼を獲得したい。これを行うには、与えられたタスクに適したコードを作成します。きれいに書いて、実装したいと思うベストプラクティスを使用します。ただし、自分に割り当てられているものだけを使用してください。これらはおそらく小さなものであり、他のチームがおそらく重要ではないと考えるものです。それらのことをうまくやる。あなたがいる場所の隅を明るくし、チームがあなたのコードを好意的にレビューするようになると、あなたのアイデアも順番に成長します。

最終的に、あなたの能力と知識を実証するとき、あなたは提案を1つまたは2つ引き出すことができるかもしれません。

私は完全にこの提案をしますが、仲間の開発者に対してのみです。経営者がそれをある種の境界の踏み越えとして見ていると想像するので、私は経営者にそれを持ち出しません。

作業している開発者に提案を行った後、彼らはおそらくコードベースがなぜそうなのかについていくつかの正当な理由を持っているでしょう。理由は「いいえ、実際にはコードは問題ありません。MVCを理解していないだけです（だからインターンです）」から「素晴らしいアイデアです。新しいアプリケーションを一緒に設計しましょう！」

このアプリケーションのリファクタリングに対する答えは、おそらくノーであることに留意してください。私はインターンが内部アプリケーションの書き換えを引き継ぐことを決して望んでいません（インターンシップが完了し、書き換えが半分しか終わっていない場合はどうなりますか？）さらに、おそらく内部アプリケーションを突くよりも重要なことがあります。

しかし、仲間に尋ねることは決して痛くないし、もしそうなら、あなたは何かを学ぶだろう。そして、それは7983879342であり、インターンシップのすべてです。

何が起こっても、次のメッセージを取り去ってほしい。上記の回答のいくつかはコードの書き直しを時々指摘しているので、技術的な理由で最高の理由でビジネス/コストの理由で実行不可能な場合があります。技術的解決策に生きるプログラマーが多すぎて、技術的な優雅さ/読みやすさ/ベストプラクティスを求める個人的な探求は、ビジネスを遂行するためのニーズとバランスを取るべきだとは考えません。私の個人的な経験では、（どちらの方向からも）そのバランスをとらない人は、チーム内の責任と見なされることがよくあります。

たとえ何かのノックバックを受け取ったとしても、物事を疑問視するのをやめないでください。

他の答えはあなたの状況の政治について多くのことを話しました、そして、私は同意する傾向があります。説得力のあるビジネスケースを提示できない限り、書き直しはおそらくカードにありません。

ただし、それはボーイスカウトルールを忘れてはならないという意味ではありません。

キャンプ場は、見つけたときよりも常にきれいにしておきます。

このコードベースに何かを実装しているときに、設計または実装のいくつかの側面をクリーンアップする方法を考え出すことができる場合は、それを考慮する必要があります。MVCモデルをよりよく利用するためにおそらくアプリケーション全体を書き直す必要はありません。特定のビューに新しいビジネスロジックを実装する場合は、古いビューからモデルにロジックを移動することを検討できます。新しいロジックを追加します。

他の人が述べたように、実装の方法/理由を理解できるように、別の開発者（このアプリケーションに精通している開発者）に簡単なウォークスルーを依頼してください。技術的な側面は理解できますが、ドットをビジネス要件に接続できるようにしたいことを説明します（ビジネス要件はすべてに勝ります）。

この情報を入手したら、評価を行うことができます。書き直すべきだと個人的に考えているが、他の人がそれを時間の有効な利用とみなすとは思わない場合は、個人プロジェクトとして引き受けてください。ここ/時間でダウンタイムが発生した場合でも、「正しく」実装してください。終了したら、他の開発者に「クリーンアップを使用できると感じたので、ダウンタイム中にサイドワークを行いました。どう思いますか？」それらに変更を押し付けないでください-「ちょっと、君たちはこれが好きですか？」として彼らにそれを提供してください。そしてそこから行きます。

原則として、ほとんどの変更は段階的に行われます。

留意すべきいくつかのこと。

• アプリケーションの歴史は何ですか？
• 今日はなぜugいですか？
• アーキテクチャの変更の利点は何ですか？

良い戦略は、ささいなことに取り組んで、ものに関するたくさんの質問をすることです（Googleやソースから学べない質問、人々の時間を無駄にしないでください）。コードベースと開発者に慣れた後、コードがそのようになっている理由をよく理解する必要があります。時々、「ええ、何かを一緒にハックしてドアの外に押し出さなければなりませんでした」だけです。通常の作業を進めながらシステムの小さな部分に軽度の変更を提案できる場合、根本的な書き換えよりも多くの牽引力が得られます。

きちんと尋ねて論理的なケースを作成すれば、書き直しを提案しても害はありません（単なる予測やそのより良い方法ではありません）。使用頻度の低いアプリケーションの書き直しが失敗する可能性が高く、システムを最初に作成した人がまだ存在し（そして、あなたよりも階層が高い）、批判に親切にならない可能性があります。

したがって、「MVCの基本原則に違反する恐ろしく設計されたこのシステムを書き換える必要はありません」と言ってはいけません。「MVCモデルでシステムを書き換えると、長い目で見れば時間を大幅に節約できるのではないかと思います。どうでしょうか。大規模な書き換え（たとえば2週間） MVCモデル、TDDなどが組み込まれ、2か月の定期的なメンテナンスの後に損益分岐点に達する」応答は、私たちがそれを求めているとは思わないかもしれません-私はあなたの時間の見積もりと新しいシステムが適切な代替品になる可能性に同意しません。または、応答は大丈夫かもしれませんが、新しいシステムが 人々があなたを責めるだろうとあなたが提案した時間枠で、新しいシステムよりも良い/良い仕事をします。また、システムがほとんど使用されていない場合でも、書き換え期間中にマイナーな修正を加えて更新を停止することは受け入れられない場合があります。