プロジェクトのコードベースに深刻な作業が必要であることをプロジェクトマネージャーまたはリードデベロッパーに（巧みに）伝えるにはどうすればよいですか？

私は（比較的）小さな開発チームに参加しました。1年ではないにしても、数か月間プロジェクトに取り組んでいます。ほとんどの開発者がプロ​​ジェクトに参加するのと同じように、最初の数日間はプロジェクトのコードベースを確認しました。

このプロジェクト（中規模から大規模のASP.NET WebForms内部基幹業務アプリケーション）は、より具体的な用語がないため、災害です。コーディング標準には、すぐに気付く3つの問題があります。

1. 標準は非常に緩いです。すべきことよりも、すべきでないこと（ハンガリー語の表記法を使用しないなど）の詳細を説明します。
2. 標準は常に守られているわけではありません。どこでもコードのフォーマットに不整合があります。
3. この標準は、Microsoftのスタイルガイドラインに準拠していません。私の意見では、フレームワークの開発者と言語仕様への最大の貢献者によって示されたガイドラインから逸脱することには価値がありません。

ポイント3については、MCPDをWebアプリケーション（具体的にはASP.NET）に集中させるために時間をかけたため、おそらくもっと面倒です。また、私はチームで唯一のマイクロソフト認定プロフェッショナルです。私はすべての教育、自習、および実地学習（認定試験の準備を含む）で学んだことにより、プロジェクトのコードでいくつかのインスタンスを見つけました。最良の方法。

私はこのチームに1週間しかいませんが、コードベースには多くの問題があり、「自分の方法」で物事を行うためにすでに記述されているものとの戦いに費やす時間が増えると思います。たとえば、より広く受け入れられているコーディング標準、アーキテクチャパターン、ベストプラクティスに準拠したプロジェクトに取り組んでいます。これは私に私の質問をもたらします：

プロジェクトを大幅に刷新する必要があることを、プロジェクトマネージャーとチームリーダーに提案する必要がありますか（その場合はどうすればよいですか）？

彼らのオフィスに足を踏み入れたくないので、私のMCTS証明書とMCPD証明書を振って、彼らのプロジェクトのコードベースはくだらないと言っています。しかし、私は実際に高品質のソフトウェアを書きたいと思っており、最終製品を安定させて簡単に保守できるようにしたいので、私はまた、黙っていたくないし、彼らの厄介なコードの上に厄介なコードを書かなければなりません。

あなたはあなたのケースを議論することに時間を費やすことができます。または、あなたはあなたが進むにつれて片付けに時間を費やすことができます。

クリーンなコードとアジャイルソフトウェア開発の原則、パターン、および実践を取り上げ、システムでの作業中にそこで学んだことを適用します。結局、人々は気づくでしょう（良いか悪いか）。

編集 また、レガシーコードを効果的に使用する方法も確認してください。

あなたが説明したことから、問題は主にコーディング標準と命名の問題に従っていないことにあるようです。それは断然、災害ではありません。比較すると、これは実際には災害です。

多分あなたは慣れていて、高い基準を必要としていますか？その場合、完全からの逸脱は失敗と見なされる可能性があります。それはあなたの要求が高いときに陥りやすいトラップですが、物事についての視点を保つことが重要です。

これを改善として話し、チームがガイドラインを更新し、実際に使用し始めるように指導することをお勧めします。Definition of Doneを品質のベンチマークとして使用するのが本当に好きで、それを作成することはそれ自体が素晴らしいチームのエクササイズです。しかし、少なくとも新しいチームメンバーとしてではなく、それ以上のことをすべきではないと思います。

確かにあなたのMCSDを振り回さないでください、人々はあなたに非常に率直に笑います、MS証明書は持っているのは素晴らしいですが、彼らは決してプロの資格ではありません！

新しいチームに軽く参加し、変更を提案する機会を探してください。

チームのコードを実行する前に、土地が整うまで待ちます。

あなたは問題があなた自身であると考えるかもしれません。あなたが言及した3つのことのどれも、アプリケーションの完全なやり直しに値するものではありません。それらはほんのひねくれた詳細です。

アプリケーションの目標は、美しいコードを持つことではなく、ビジネス上の問題を解決することです。確かに、一貫性があり、優れた標準に従っているコードを用意するのは良いことですが、コードがないためにコードベース全体を破壊する理由にはなりません。エンジンが油っぽいからといって、エンジンを再構築する必要があるわけではありません。

見て、誰もが自分で記述していないすべてのコードベースを嫌っています。実際、3年待って自分のコードを見ると、それも嫌になり、完全に書き直す必要があると思います。真実はそうではありません。ビジネス価値を追加する機能を構築するのではなく、美的に満足のいくコードを作成するのに何ヶ月も費やすことができない場合を除いて、おそらく間違ったツリーが発生しています。

コードベースにコードが存在する可能性があるからといって、kludgyコードを記述しなければならないということは何もありません。そして、それはあなたのペットのスタイルに準拠していないという理由だけでコードが無愛想だということは何もありません。作業している部分に沿ってリファクタリングし、新しいものに取り組むときに適切なコードを記述します。

これらのことは心配しても大丈夫ですが、チームに初めて参加する場合は、ある程度の信頼を築くまで、まだボートを揺さぶらないでください。

あなたは3つの（比較的）マイナーなものを選んでフレットオーバーしたようです。私がもっと心配したい他のものがあります：

• コードは十分に文書化されていますか？
• コードは仕様/設計ドキュメントに準拠していますか？
• コードは機能しますか？
• コードが何をするかを理解するのは簡単ですか？
• このコードベースの大きなチャンクをTheDailyWTFに提出することを検討していますか？

あなたは一週間そこにいましたか？プロジェクトマネージャーに提案をするのに十分な知識があるかどうかはわかりません。このチームのコードと実践が「悪い」という疑いがあるとしても、時間をかけてこれらに影響を与える最良の方法は、彼らの信頼と尊敬を徐々に得ることです。プロジェクトに入って1週間後にチームにコードの書き換えが必要であることを伝えることは、信頼と尊敬を得るための良い方法ではありません。

最初の数か月間は、より良い例を示すことに集中し、なぜ彼らが特定の方法で物事を行ったのかについて質問します。これらの質問をするときは、口調に注意してください。「すべてを知っている」新しい人として出会った場合、物事の進め方に本当に影響を与える立場にあるときに、後で誰もあなたの意見を聞くことはありません。

時間の経過とともに、コードが本当に「より良い」場合、他の開発者はそれを目にするでしょう。彼らは彼らが彼らを修正するのを助けるリソースとしてあなたのところに来始め、彼らが物事をどのようにすべきかについてあなたの助言を求めます。その時点で、あなたはチーム（および経営陣）にコーディング標準などについてのあなたの意見を伝える絶好の立場になります。このプロセスにかかる時間は組織によって異なります。非常に順応性のある環境では数週間、よりストイックな文化では数か月から数年になる場合があります。一度に1人ずつ影響力を高めます。

コードベースが完璧で、すべてが「正しい」方法で行われたと思うような新しい仕事に決して参加することはありません。これを受け入れることを学ぶ。レガシーコードでできることは、リファクタリングと少しずつ進むことです。彼らがなぜ彼らがしたことをしたのかを理解するまでリファクタリングしたくないいくつかのこと。また、ビジネスの誰もが機能するコードを修正するためにあなたにお金を払うつもりはないので、ステップアップして時間を費やす前に、なぜそれが機能する必要があるかについてビジネスケースを作らなければなりません。とにかくコードを変更する必要がある場合は、コードのリファクタリングを待つほうがよいでしょう。いくつかの方法でそれらが行った方法を選択しなかった可能性がありますが、それが機能する場合は、それを変更し、新しいバグを導入する際に十分注意してください。特に、変更を求められていない場合。

1週間後、あなたは彼らがどのようにビジネスをしているのかについて主要な提案をする信頼性がなくなります。今あなたが物事を育てれば、人々はあなたを笑い、あなたを真剣に受け止めることは決してないでしょう。最初にいくつかの良いコードで自分自身を証明してください、そうすれば人々は聞く傾向が強くなります。

率直に言って、あなたがマイクロソフト認定プロフェッショナルであることを誰も気にしません。多くの経験を持つ誰もが、その資格を持っている多くの悪いプログラマーを良い人と見ています。認定資格を取得するのが悪く見えると言っているのではなく、有効なプログラマーが誰であるかを示しているので、彼らがどこで効果的であるかを見たことがないので、あまり信用していません。

私はおそらく、あなたが自分の立場を適切に正当化できなくなる可能性があるという意図で提案を提示する方法を理解しようとする道をたどるでしょう。その提案を作成する際に熟考するいくつかの質問：

• ここで説明する種類の変更を行うことで、どのくらいのビジネス価値が得られますか？
• アプリケーションをゼロから書き直す、既存のコードを変更してそれを完全なものにする、または時間の経過とともに少しだけ変更するなどのオプションを検討しましたか？
• あなたが望む変更を加えるのを妨げるであろうどんな機能やバグが今求められているか知っていますか？

私は貧弱なコードベースを修正したいと考えることができますが、ビジネスの観点からそれを行うことが理にかなっているように、これを比較検討する必要があります。

あなたは現在、悪いコードを防ぐ立場にないので、それを封じ込める方法を理解する必要があります。

首相とチームリーダーは、それが機能しないことを気にするだけです。彼らの次の懸念は、彼らがあなたに変更を加えるように頼むとき、そして「単純な」ものがなぜそんなに長くかかるのか疑問に思うときです。それはあなたが来るところです。

一貫性の問題から始めましょう。現在の潜在的に標準的な方法が何であれ、それを特定して、それを強制することができないかどうかを確認してください。他の誰も知らない方法論から始めると、大量の反発を受けることになります。

他のチームメンバーも認定を取得したい場合があり、あなたは素晴らしいリソースになります。うまくいけば、彼らは少なくとも改善し、彼らに道を示すためにあなたに目を向けたいと思うでしょう。

ハンガリー記法について文句を言うことはあなたに同情することはなく、おそらく優先リストの最後の戦いの1つです。

私はあなたがこれに注意する必要があることに同意します。批判を述べたり、コードやプロセスに深い変更を提案したりする前に、チーム内で評判を築く必要があります。とりあえず自分の調査結果と提案についてメモをとり、チームメンバーと経営者と知り合う機会を得て、無料のディスカッションに参加しますが、話が品質の問題、コーディングの質問などになった場合は拒否せず、場合によっては投げるだけです池への自分自身の質問のいくつか（ただし、一般的な形式では、このコードベース内で私が見た具体的な問題をあまり指摘していません）。このようにして、チームメンバーの意見を知り、潜在的な仲間を見つけることができます。

最良のケースでは、チーム（および/または経営陣）のかなりの部分があなたと同じ問題を目にすることがあります。彼らについて何かをするための率先行動がなかったり、経営陣によってそれに与えられたリソースがないだけです。必要に応じて、一緒に管理を説得するように言います。

@Mikeが示唆したように、いくつかのクリーンアップを自分で行うことは確かに必要ですが、繰り返しになりますが、それを我慢してください。早く始めすぎると、個人的な批判としてそれを受け入れるかもしれない他のチームメンバーを遠ざけるかもしれません。また、大規模なコードのクリーンアップ/リファクタリングを開始することは、実際のタスクに十分に集中していないことを示す兆候として、マネージャによって行われる場合があります。そのため、より深刻なレベルで開始する前に、リファクタリングを行う必要があります。小さなローカルな変更でもおそらく大丈夫です。

また、経営陣を説得するには、ビジネス上の根拠が必要です。コーディングスタイルの一貫性の欠如の説明によって管理が動かされることはほとんどありません。提案された変更が会社にもたらす可能性のある価値を彼らに示す必要があります-一番下の行は現金です。さまざまな提案された変更のコストと長期的なメリットに関する説得力のある計算をまとめ、全体的なバランスが明らかにプラス側にあることを示すことができれば、可能性が大幅に向上しました。

自分でやれ。特定のコーディングスタイルを重視する場合は、コーディングスタイルに違反するコードに取り組みます。問題のあるコードをソース管理からチェックアウトし、コードをスタイルの空白スペースの要件に合わせて再フォーマットし（例として）、「空白に関するスタイルガイドのルールに準拠してください」というメッセージが表示された更新済みコードをコミットします。

1週間後、おそらくあなたができる最悪のことは、これで直接管理に行くことです。おそらく彼らはコードに多くの時間を費やしており、ある程度のプライドを持っています。あなたはおそらく厳しい「それをすべて知っている」として外れるでしょう。

もし私があなただったら、あなたが進むにつれてそれを改善することです。あなたがそれに慣れてきて、より多くのことに取り組むにつれて、あなたはそれを改善する機会を持つでしょう。あなたがしていることの利点を他の同僚に示し始めるのは、その時点ででしょう。その後、新しいモジュールの設計会議が開かれたときに、最良の方法として認識していることについて議論を示します。

正直なところ、基準はある理由で存在しますが、それが機能してうまく機能すれば、私の本では100倍の価値があります（特に1週間後）。コードを開いて、大量の論理エラーまたはそのような性質を見た場合は、さらに心配になります。

この「問題」のある管理に直接行かないでください。

まず、同僚と話をして、なぜ物事が彼らのやり方であるのかを彼らから見つけます。次に、問題があるかどうかにかかわらず、より適切な評価を行うことができます。学んだことに驚かれるかもしれません。また、それをきれいにしたいという同盟国を見つけるかもしれません。

そもそもどうやって自分がどこにいるのかわからない場合は、外に出るのがずっと難しくなります。

すでに多くの良い提案がここにあり、私は他の人たちと同じようにあなた自身が最初に自分の意見を証明するまで、あなたの橋を燃やすことはありません。私が付け加えるのは、プロジェクトマネージャーまたはチームリーダーに最初に行くことによって彼らを疎外する前に、チームメイトとよく話し合うことです。そしてその前に、あなたが真剣に受け止められるべきであることを確かに示しましょう。

それはあなたがコードで持っているより文体的な問題のようでもあります。他の人のコードを乗っ取り、自分の書いた方法に慣れるまで鼻をかざすことは、たとえそれをフォーマットする方法のような些細なことであっても、仕事の一部にすぎません。自分の「赤ちゃん」を誰かに手渡して、汚い手でそれを壊すのはさらに悪いことです...

それが最終的にそれ以上であり、問​​題が単なるスタイルよりも機能的である場合、チームのリーダー/午後に行く場合は、将来的にお金と労力を節約できる場所に関して再作業の必要性を提案するのが最善です。開発プロジェクト。古き良きリファクタリング。