プロジェクトのコードベースに深刻な作業が必要であることをプロジェクトマネージャーまたはリードデベロッパーに（巧みに）伝えるにはどうすればよいですか？
私は（比較的）小規模な開発チームに参加しました。1年ではないにしても、数か月間プロジェクトに取り組んできました。ほとんどの開発者がプロジェクトに参加するのと同じように、最初の数日間はプロジェクトのコードベースを確認しました。
プロジェクト（中規模から大規模のASP.NET WebFormsの内部基幹業務アプリケーション）は、より具体的な用語がないため、災害です。コーディング標準には、すぐに気付く3つの問題があります。
- 標準は非常に緩いです。何をしないか（ハンガリー語の表記を使用しないなど）は、何をするかtoします。
- 標準が常に守られているわけではありません。コードの書式設定に一貫性がありませんどこでも。
- 標準はMicrosoftのスタイルガイドラインに準拠していません。私の考えでは、フレームワークの開発者が定めたガイドラインから逸脱することには価値がありません。言語仕様への最大の貢献者。
ポイント3に関しては、おそらく [〜＃〜] mcpd [〜＃〜] を取得するために時間を割いてWebアプリケーション（特にASP.NET）に焦点を合わせているため、私はもっと面倒です）。また、私はチームで唯一のマイクロソフト認定プロフェッショナルです。私はすべての教育、自習、および実地学習（私の認定試験の準備を含む）で学んだことにより、プロジェクトのコードでいくつかのインスタンスを見つけました。最良の方法。
私はこのチームに1週間しかいませんが、コードベースには多くの問題があるので、「自分の方法」で実行するためにすでに記述されているものとの戦いに費やす時間が増えると思います。たとえば、より広く受け入れられているコーディング標準、アーキテクチャパターン、ベストプラクティスに従ったプロジェクトに取り組んでいます。これは私に私の質問をもたらします：
プロジェクトを大幅に刷新する必要があることをプロジェクトマネージャーとチームリーダーに提案する必要がありますか（その場合はどうすればよいですか）？
彼らのオフィスに足を踏み入れたくないので、MCTSとMCPDの証明書を振り回して、彼らのプロジェクトのコードベースはくだらないと言っています。しかし、私はまた、黙っていたくないし、上に汚いコードをそれらの上に書かなくてはいけない汚いコードを私は実際に高品質のソフトウェアを書きたいので、最終製品に安定していて、簡単に保守できます。
あなたはあなたの事件を議論することに時間を費やすことができますまたは、あなたはあなたが進むにつれて片付けに時間を費やすことができます。
クリーンコード と アジャイルソフトウェア開発の原則、パターン、およびプラクティス を選択し、システムでの作業中にそこで学んだことを適用します。結局、人々は気づくでしょう（良いか悪いか）。
Editまた、チェックアウト 従来のコードで効果的に機能
あなたが説明したことから、問題は主にコーディング標準と命名の問題に従っていないことにあるようです。 それは断然災害ではありません。比較のために、 this は実際には災難です。
多分あなたは慣れていて、高い基準を必要としていますか？その場合、完璧からの逸脱は失敗と見なされる可能性があります。それはあなたの要求が高いときに簡単に陥る罠ですが、物事の見通しを保つことが重要です。
これを改善として話し、チームがガイドラインを更新し、実際に使用し始めるように指導することをお勧めします。 Definition of Doneを品質のベンチマークとして使用したいのですが、Define of Doneを作成すること自体が素晴らしいエクササイズです。しかし、少なくとも新しいチームメンバーとしてではなく、それ以上のことをすべきではないと思います。
確かにあなたのMCSDを振り回さないでください、人々はあなたにかなり率直に笑うでしょう、MS証明書は持っているのは素晴らしいですが、彼らは決してプロの資格ではありません！
新しいチームに軽く参加し、変更を提案する機会を探します。
チームのコードを実行する前に、土地が整うまで待ちます。
あなたは問題があなた自身であると考えるかもしれません。あなたが言及した3つのことのどれも、アプリケーションの完全なやり直しに値するものではありません。それらはほんのひねりの効いた詳細です。
アプリケーションの目標は、美しいコードを持つことではなく、ビジネス上の問題を解決することです。確かに、一貫性があり、優れた標準に従っているコードを作成するのは良いことですが、コードがないためにコードベース全体を破壊する理由にはなりません。エンジンが油っぽいからといって、エンジンを再構築する必要があるわけではありません。
見て、誰もが自分が書いていないすべてのコードベースを嫌っています。実際、3年待って自分のコードを見ると、それも嫌になり、完全に書き直す必要があると思います。実はそうではありません。ビジネス価値を追加する機能を構築するのではなく、美的に満足のいくコードを作成するのに何ヶ月も費やすことができない限り、あなたはおそらく間違ったツリーを樹立しています。
コードベースにコードが存在する可能性があるという理由だけで、Kludgyコードを記述しなければならないということはありません。そして、コードは何も言いませんIS kludgyそれはあなたのペットのスタイルに固執しないからです。作業する部分に沿ってリファクタリングし、新しいものに取り組むときは良いコードを書いてください。
これらのことは心配しても大丈夫ですが、チームに初めて参加する場合は、ある程度の信頼を築くまで、まだボートを揺さぶらないでください。
あなたは3つの（比較的）マイナーなものを選んでフレットオーバーしたようです。私がもっと心配したい他のものがあります：
- コードは十分に文書化されていますか？
- コードは仕様/設計ドキュメントに準拠していますか？
- コードは機能しますか？
- コードが何をするかを理解するのは簡単ですか？
- このコードベースの大きなチャンクをTheDailyWTFに提出することを検討していますか？
あなたは一週間そこにいましたか？プロジェクトマネージャーへの提案をするのに十分な知識があるとは思いません。このチームのコードと実践が「悪い」という疑いがあるとしても、時間をかけてこれらに影響を与える最良の方法は、彼らの信頼と尊敬を徐々に得ることです。プロジェクトに参加して1週間後にチームにコードの書き換えが必要であることを伝えることは、信頼と尊敬を得るための良い方法ではありません。
最初の数か月間は、より良い例を示すことに集中し、なぜ彼らが特定の方法で物事を行ったのかについて質問します。これらの質問をするときは、口調に注意してください。 「すべてを知っている」新しい人として出会った場合、物事の進め方に実際に影響を与える立場にあるときに、後で誰もあなたの意見を聞くことはありません。
時間の経過とともに、コードが本当に「より良い」場合、他の開発者はそれを目にするでしょう。彼らは彼らが彼らを修正するのを助けるリソースとしてあなたのところに来始め、彼らが物事をどのようにすべきかについてあなたのアドバイスを求めます。その時点で、あなたはチーム（および経営陣）にコーディング標準などについてのあなたの意見を伝える絶好の立場になります。このプロセスにかかる時間は組織によって異なります。非常に順応性の高い環境では数週間、よりストイックな文化では数か月から数年になる場合があります。一度に1人ずつ影響力を高めます。
コードベースが完璧で、すべてが「正しい」方法で行われていると思うような新しい仕事に決して参加することはありません。これを受け入れることを学ぶ。レガシーコードでできることは、リファクタリングと少しずつ進むことです。 whyについて理解を深めるまで、リファクタリングしたくないものもあります。また、ビジネスの誰もが機能するコードを修正するためにあなたにお金を払うつもりはないので、ステップアップして時間を費やす前に、なぜそれが機能する必要があるかについてビジネスケースを作らなければなりません。とにかくコードを変更する必要がある場合は、コードのリファクタリングを待つほうがよいでしょう。あなたは彼らがいくつかのことのためにした方法を選択しなかったかもしれませんが、それがうまくいくなら、それを変更して新しいバグを導入することについて非常に注意してください。特に、変更を求められていない場合。
1週間後、あなたは彼らがどのようにビジネスをしているのかについて主要な提案をする信頼性がなくなります。今あなたが物事を育てれば、人々はあなたを笑い、あなたを真剣に受け止めることは決してないでしょう。最初にいくつかの良いコードで自分自身を証明してください、そうすれば人々は聞く傾向が強くなります。
率直に言って、あなたがマイクロソフト認定プロフェッショナルであることを誰も気にしません。多くの経験を持つ誰もが、その資格を持っている多くの悪いプログラマーを良い人と見ています。認定資格を取得するのが悪いと言っているわけではありません。有効な場所が優れたプログラマーであることを示しているので、私たちはそれらをあまり信用していません。
私はおそらく、あなたが自分の立場を適切に正当化できなくなる可能性があるという意図で提案を提示する方法を理解しようとする道をたどるでしょう。その提案を作成する際に熟考するいくつかの質問：
- ここで説明する種類の変更を行うことで、どのくらいのビジネス価値が得られますか？
- アプリケーションをゼロから書き直す、既存のコードを変更してそれを完全なものにする、または時間の経過とともに少しだけ変更するなどのオプションを検討しましたか？
- 必要な変更を加えるのを妨げる、現在必要な機能やバグを知っていますか？
私は貧弱なコードベースを修正したいと考えることができますが、ビジネスの観点からそれを行うことが理にかなっているように、これを比較検討する必要があります。
私はあなたがこれについて注意する必要があることに同意します。批判を述べたり、コードやプロセスに深い変更を提案したりする前に、チーム内で評判を築く必要があります。とりあえず自分の調査結果と提案についてメモを取り、チームメンバーと経営者と知り合う機会を得て、無料のディスカッションに参加しますが、話が品質の問題、コーディングの質問などになった場合は拒否せず、場合によっては投げるだけです池への私の独自の質問のいくつか（ただし、一般的な形式では、このコードベース内で私が見た具体的な問題をあまり指摘していません）。このようにして、チームメンバーの意見を知り、潜在的な仲間を見つけることができます。
最良のケースでは、チーム（および/または経営陣）のかなりの部分があなたと同じ問題を目にしていることに気付くかもしれません。彼らについて何かするためのイニシアチブがないか、経営陣によってそれに与えられたリソースがないだけです。必要に応じて、一緒に経営陣を説得するように言います。
@Mikeが示唆したように、クリーンアップのいくつかを自分で行うことは確かに必要ですが、繰り返しになりますが、それを我慢してください。速すぎると、個人的な批判と見なされる可能性のある他のチームメンバーを遠ざける可能性があります。また、大規模なコードのクリーンアップ/リファクタリングを開始することは、実際のタスクに十分に集中していないことを示す兆候として、マネージャによって行われる場合があります。したがって、より深刻なレベルでそれを開始する前に、リファクタリングする必要があります。ローカルでの小さな変更はおそらく大丈夫です。
また、経営陣を説得するには、ビジネス上の根拠が必要です。コーディングスタイルの不整合がどのように説明されているかによって、管理が動かされることはほとんどありません。提案された変更が会社にもたらす可能性のある価値を彼らに示す必要があります-一番下の行は現金です。さまざまな提案された変更のコストと長期的なメリットに関する説得力のある計算をまとめて、全体的なバランスが明らかにプラス側にあることを示すことができれば、可能性が大幅に向上しています。
あなたは現在、悪いコードを防ぐ立場にないので、それを封じ込める方法を理解する必要があります。
首相とチームリーダーは、それが機能しないことを気にするだけです。彼らの次の懸念は、彼らがあなたに変更を加えるように頼むとき、そして「単純な」ものがなぜそんなに長くかかるのか疑問に思うときです。それはあなたが入るところです。
一貫性の問題から始めましょう。潜在的に標準的な方法が現在どのようなものであっても、それを特定して、強制することができないかどうかを確認してください。誰も知らない方法論から始めると、プッシュバックが大量に得られます。
他のチームメンバーが認定を取得したい場合は、素晴らしいリソースになります。うまくいけば、彼らは少なくとも改善し、あなたに彼らの道を示すことを望んでいるでしょう。
ハンガリー記法について文句を言うことはあなたに同情することはなく、おそらく優先リストの最後の戦いの1つです。
自分でやる。特定のコーディングスタイルを重視する場合、コーディングスタイルに違反するコードに取り組む。ソース管理から問題のあるコードの一部をチェックアウトし、コードをスタイルの空白スペースの要件に合わせて再フォーマットし（例として）、「スタイルガイドの空白に関するルールに準拠してください」というメッセージとともに更新されたコードをコミットします。
1週間後、おそらくあなたができる最悪のことは、これで直接管理に行くことです。おそらく、彼らはコードに多くの時間を費やしており、ある程度のプライドを持っています。あなたはおそらく厳しい「それをすべて知っている」として外れるでしょう。
もし私があなただったら、あなたが進むにつれてそれを改善することです。あなたがそれに慣れてきて、より多くのことに取り組むにつれて、あなたはそれを改善する機会を持つでしょう。あなたがしていることの利点を他の同僚に示し始めるのは、その時点ででしょう。その後、新しいモジュールの設計会議が開かれたときに、最良の方法として認識していることについて議論を示します。
そして正直なところ、標準はある理由で存在しますが、それが機能し、うまく機能すれば、私の本では100倍の価値があります（特に1週間後）。コードを開いて、大量の論理エラーまたはそのような性質を見た場合は、さらに心配になります。
この「問題」を直接管理に行ってはいけません。
まず、同僚と話をして、なぜ物事が彼らのやり方であるのかを彼らから見つけてください。次に、問題があるかどうかにかかわらず、より適切な評価を行うことができます。学んだことに驚かれるかもしれません。また、それをきれいにしたいという同盟国を見つけるかもしれません。
そもそもどうやって自分がどこにいるのかわからない場合は、外に出るのがずっと難しくなります。
すでに多くの良い提案がここにあり、私は他の人のようにあなたが自分自身を最初に証明するまで、あなたの橋を燃やさないでいます。私が付け加えたいのは、最初にプロジェクトマネージャーまたはチームリーダーに行くことによって、彼らを疎外する前にチームメイトと十分に話し合うことです。そしてその前に、あなたが真剣に受け止められるべきであることを確かに示しましょう。
それはあなたがコードで持っているより文体的な問題のようでもあります。他の人のコードを乗っ取り、彼らの書いた方法に慣れるまで鼻をかざすことは、たとえそれをフォーマットする方法のような些細なことであっても、仕事の一部にすぎません。自分の「赤ちゃん」の1つを他の人に手渡して、汚い手でそれを壊すのはさらに悪いことです...
それが最終的にそれ以上であり、問題が文体よりも機能的である場合、チームのリーダー/午後に行く場合は、将来的にお金と労力を節約できる場所に関して再作業の必要性を提案するのが最善です。開発プロジェクト。古き良きリファクタリング。