私たちのコードが悪いことを経営陣に伝える正しい方法は何ですか？

私たちのコードは悪いです。常に悪いとは考えられていなかったかもしれませんが、悪いことであり、下り坂になっています。私は大学を卒業してから1年も経たないうちに、コードの多くの部分が信じられないほど困惑しました。最初は、新しい人として、コードベースについてもう少し学ぶまで口を閉ざしておくべきだと考えましたが、それが悪いことを知っていることはたくさんありました。

ハイライトのいくつか：

• まだフレームを使用しています（クエリ文字列から何かを取得してみてください、ほとんど不可能です）
• VBScript
• ソースセーフ
• .NETを「使用」します。つまり、COM DLLを呼び出す.netラッパーがあり、簡単にデバッグすることはほとんど不可能です。
• すべてが基本的に1つの巨大な機能です
• コードは保守できません。各ページには、新しいページが作成されるたびに作成される複数のファイルがあります。メインページは基本的にResponse.Write（）を何回も実行してHTMLをレンダリングします（runat = "server"？方法はありません）。その後、クライアント側（VBScript）に多くのロジックがあり、最終的にページはそれ自体に送信し（多くの場合、多くの情報を非表示フィールドに保存します）、そこで保存などの処理を実行できる処理ページに投稿しますデータベースへのデータ。
• 私たちが得た仕様は笑えます。多くの場合、フィールドYまたはフィールドZを選択するタイミングを指定せずに、「フィールドYまたはフィールドZのいずれかを使用してフィールドXを自動入力」などを呼び出します。

これのいくつかはソフトウェア会社に雇われていないことの結果だと確信していますが、ソフトウェアを書いている人は少なくともコードの品質に注意を払うべきだと思います。期限が迫っているので、何かがすぐに行われるということを考えたとしても、想像もできません。しかし、私たちは悪いコードを書き続け、悪い慣行を使い続けています。

私に何ができる？どうすればこれらの問題を持ち出すことができますか？私のチームの75％が私に同意し、過去にこれらの問題を提起しましたが、何も変わりません。

過剰に反応していないことを確認してください。あなたは新鮮で、おそらく他の多くの場所で（まだ？）働いたことがないので、「実生活のコード」の世界に備えていません。実際のコードは恐ろしいものです。それは、あなたの素敵な学校のコードと、ひたすら微調整した個人的なプロジェクトのコードが原子炉の地下でセックスし、赤ちゃんが有毒廃棄物の下水道で育ったようなものです。それは恐ろしいミュータントです。

しかし、あなたが正しいと仮定し、コードがあなたが言うほど悪い（つまり、典型的な悪いコードよりも悪い）ならば、あなたは心配する権利があります。チームに相談して、他の全員が味方かどうかを判断します。状況を改善するには作業が必要です。チームの他のメンバーが問題を認識していても気にしない場合は、時間を無駄にしています。

ジュニアであるため、おそらくあなたはリードする立場にないでしょう。あなたが管理職に就くと、後輩でもある新入社員として、あなたの意見はおそらく無視されるでしょう。リード開発者または最も上級の開発者を関与させてください。繰り返しますが、高齢者の誰も興味を持っていない場合、あなたはあなたの時間を無駄にしています。

上級の技術者に興味を持ってもらうことができると仮定して、私は問題領域と可能な解決策を特定することに取り組んでいます。たとえば、「すべてが基本的に1つの巨大な機能」である場合、次にその「巨大な機能」で作業しているときには、少しリファクタリングする必要があります。繰り返しになりますが、全員をオンサイドにする必要があります。問題のほんの一部を削ぎ落とし、少しずつ改善していくと、最終的には問題がはるかに少なくなります。コードに触れるたびに、コードを改善できるかどうかを検討してください。

経営陣と一緒に座って「すべてが悪いので書き直す必要がある」と言うつもりはありません。それは彼らにとって意味がありません-費用がかかり、潜在的に非常に危険です。代わりに、問題があること、および変更が加えられるにつれて徐々に改善する計画があることを認識させる必要があります。保守可能なコードの利点について教育する必要があります。これは、あなたからではなく、技術的にも専門的にも信頼できるシニアの人からのものでなければなりません。

完全に書き換えますか？ほとんど常に悪い考えです。

最終的には、あなたが新しいのでできることはあまりありません。誰も物事を改善したくない場合は、あなたの経験を収集し、次の場所に移動します。

Joel On Softwareをお読みください-絶対にすべきではないこと。彼の推論を理解し、プログラマーではなくマネージャーによって書かれた、悪いソフトウェアとその修正方法に関する他の記事をいくつか読んでください。この情報を使用して、管理者が理解し、気にする用語で、それを修正するためのケースを提示することができます。ヒント：優れたマネージャーは、プログラマーの意見や、何をしなければならないかという感情だけに基づいて時間とお金を費やすことはありません。

「このコードはくだらないため、書き直しが必要です」は、たとえ技術的に正しいとしても、確かにあなたに投げ返されます。

「現在のプロジェクトスケジュールから数か月を短縮し、コストを削減し、信頼性を高めることができます。」彼らの注意を引くでしょう（彼の段階でこれを行うつもりであることに言及していないことに注意してください）。

あなたが言うことは何でも、あなたが正しいことを確認してください。それが悪いと言うなら、あなたの書き換えは血まみれの良いものでなければなりません。1週間かかると言うなら、あなたはそれが1週間であることを確信し、良いことをしなければなりません。再加工されたコードに欠陥があると、再加工を行わなかった場合に何が起こったかにかかわらず、個人的に、多大な費用がかかります。誰かがあなたの前にいて、書き換えを台無しにしたり、売り過ぎたり、あきらめた場合、マネージャーは馬鹿にされるのを嫌い、それを二度とさせません。そのトークンによって、それに続く人のためにそれを台無しにしないでください、あなたはこれで1つのショットしか得ません...

期間またはプロジェクトの数にわたってコストを分散する方法を見つけます。マネジャーはリスク、投機的投資、ネガティブなキャッシュフローを嫌います-あなたのマネジャーの許容範囲内で作業してください。小さな、低リスク、低コストの提案から始めます。正しいことが証明されたら、より大きな魚を探すことができます。

まず最初に、あなたがプログラマーとして働いているどこでも、あなたがスタートアップで働いていて、あなたがオリジナルの間抜けなレガシーコードを作成する人でなければ、間抜けなレガシーのものを見つけるでしょう。プログラミングでキャリアを積むつもりなら、これらのパンチでロールバックできなければなりません。

第二に、多くの場合、古いシステムの改善にはコストの考慮事項があります。たとえば、10年前のVB6と従来のASPアプリケーションがまだ稼働している会社が複数あります。場合によっては、これは.NETを移動する大きなプロジェクトがひどく失敗したためでした。他の人では、理由は「壊れていないなら、直さないで」だった。しかし、レガシーシステムによって引き起こされる問題は無視するには大きすぎるため、他の場合には、移動のコストは正当化されます。

過去に大きな失敗があった状況では、変化をもたらすことはほとんど不可能です。その場合、履歴書を磨き、新しい仕事を探し始めます。それが壊れていなければ、おそらくコード自体について不平を言う理由はないでしょうが、あなたが充実して成長しているキャリアパスにいなかったということでしょう。それが壊れていて、それがあなたの場合のように聞こえるなら、それはあなたが変化の機会を持っているときです。

私が見た最善のアプローチは、あまり多くを食い止めるのではなく、最もプラスの影響を与える漸進的な変更から始めることです。説明に基づいて、変更要求をより適切に管理することが開始点となります。それが制御できたら、サービスフレームワークの作成やその他の設計/コードの漸進的な改善を検討することができます。

私が見た最悪のアプローチは、レガシーシステムから最新かつ最高のものに直接飛躍しようとすることです。たとえば、動作しているが不格好なVB6 / Classic ASP / COM +システムからMVC / Entity Frameworkシステムにジャンプすることです。

「Hey Boss、Big Projectの後、私とチームはコードを整理するのに理想的にはXか月かかります。数分でできるはずのことは、すべてが非常に混乱しているので、数時間かかります。 Big Projectの直後に、現実的なスケジュールを計画したいと思います。」

（質問に対するAzkarのコメントから部分的に言い換え）

ソフトウェアに関するJoel（Joel Spolsky / Stack Exchangeの創設者）の読み始め...

最初にやることはジョエルテストをすることです。

これにより、「開発者として改善する方法を探していたときに、開発環境に関するこの12の質問テストに出くわしたので、楽しみのために自分の勤務先について回答しました。」...これにより、個人的にではなくコードの何が問題なのかを概説するサードパーティになります。

Pragmatic Practicesの詳細を読むと、自分自身を改善し、red / green / refactorなどを実装することになります。これにより、コードベースをクリーンアップして、メンテナンスが可能になります。（時間とともに）

お役に立てば幸いです！プログラミングへようこそ（昨日のコードはたいていひどいです）;-)

クイックヒント：あなたが理由のリストで管理を提案行う場合は、なぜあなたは異なったコーディングする必要があり、引数「プログラマのための改善された士気/労働条件」として含まれています。

テクノロジーチームは、この現在の混乱よりもクリーンなコードを記述し、維持するコンテンツが多くなることを明確にしてください。これにより、仕事に対する態度が確実に向上します。有用な引数になる可能性があります。

• 管理は実際に設計を決定しますか？チームのほとんどが背後にいる場合、何があなたを止めていますか？積極的に行動し、グループとして決定します。それを段階的に実行する計画を考え出してください。じゃやれ。
• 管理は、使用する開発ツールを決定しますか？ツール管理の交換に時間的なコストがない限り、通常は気にしません。積極的に取り組み、使用する開発ツールをグループとして決定します。経営陣から購入する必要がある場合は、移行計画と費用便益分析を提示します。じゃやれ。
• 管理は使用する言語を決定しますか？積極的に行動し、VBScriptの代わりに何を使用するかをグループとして決定します。 それを段階的に実装し、実行する計画を立てます。 経営陣が買収する必要がある場合は、計画を提示します。じゃやれ。
• 仕様については何もありません。それは通常、職場の人とプロセスに大きく依存します。何が壊れているのか、プロセスを修正するのに必要な最小限の変更を特定するには、現在の動作と動作の方法を分析し、理解するのに時間がかかります。計画を立てて、経営陣を説得してみてください。

表示するビジネス価値がない（またはソフトな）大量の専用時間を必要としない変更方法を提案すると、より多くの変更と敬意を得ることができます。

経験から言えば：簡単ではありません。それはほとんど不可能です。経営陣は、コードの悪さを気にせず、おそらく完全に無知であるか、直面している問題について無知であるか、またはずっと前に修正していたので、今日はそれで立ち往生することはありません。あなたができる最善のことは、コードが吸う理由のリストを作成し、それからリファクタリング/リライトの実際のビジネス価値を実証するために吸う理由の背後にある理由を作成することです。

たとえば、「コードは保守できません」の場合があります。

現在のコードは、X、Y、Zのためにメンテナンスできません（メンテナンスできない理由をリストしてください）。X、Y、Z（変更が難しい理由）のため、これは変更要求と新機能の実行を非常に困難にします。変更は難しいため、開発チームはバグの修正や改善に簡単に対応できません。

あなたの唯一の望みは、上司と上級管理職が愚かすぎてコードにどんな影響があるのか​​理解できず、問題に対処するための新機能のリクエストを出そうとしないことです。そうしないと、努力が無駄になります。過去の経験から言えば、彼らはコードに何の問題も見ない可能性が非常に高く、そして/またはあなたの同僚は彼らの懸念を経営に持ち込むにはあまりにもひどいです。

幸運を。必要になります。

「大学を卒業したばかりです」-あなたの質問に答えるべきです。

管理者はおそらく、コードが最適ではないことを知っています。ほとんどのコードは、レイゴスリング、グイドヴァンロッサム、またはそれを書くのに本当に優れた高価な人を雇わない限りです。

また、経営陣は、会社に適用される「作品」の定義を使用して機能することを認識しています（レポートをクラッシュ、販売、配信しないなど）。

彼らはあなたがコードを最小限のコストで「機能する」ように保ちたいと思っています。彼らはすべてを書き直すための高価なプロジェクトの提案を望んでいません。

あなたの成果物は、洗練されたコードではなく動作するソフトウェア（既に持っているもの）であるため、ビジネスケースを作成することはほとんど不可能です。

ソフトウェアでは、機能を最初に市場に投入することから大きな機会費用がかかるという事実を加えてください。本当に考えてみれば、時間投資に対する長期的な見返りは保証されていません。

とはいえ、管理しやすいバイトに沿って、小さなものをリファクタリングして修正する（良いVSSを取得するなど）ことは、依然として良い計画です。最終的に、これは管理上の問題ではなく技術的な問題です。あなたが約束したことを実現しながら、やるべきことをやるだけで、あなたは元気になります。経営者は、たとえあなたが強い主張をしたとしても、コード品質の核心な詳細に興味を持つことはおそらくないでしょう。

できるだけ早く出発してください（ジョブホッパーのようになりたくないので、すぐに出発しないでください）。彼らがコーディングするのは混乱であり、人々がそこに留まっているという事実は、あなたが貧しい開発者と一緒に働いている可能性が高いことを意味します。自分の仕事に関心のあるまともな開発者は、そのようながらくたに長く取り組むことはありません。

書き換えが非常に明確に実証されない限り、書き換えが発生する可能性は、$$$投資の価値があります。

管理者はコードを気にしません。彼らは販売する製品を持っていることに関心があります。

レガシーシステムが本当にひどく、チームの大部分に途方もない量のオーバーヘッドが追加されている場合（私は大部分を言います。なぜなら、大きなチャンクまたはそのすべてをコーディングし、それを知っている人が常にいるからです。彼の手）は、彼らに近づき、開発時間にビジネスコストがかかると言い、顧客満足度に影響を与えます。

しかし、もう一度、彼らはまだコードを気にせず、製品を気にします。その答えは彼らに「うん、それをやらせます」かもしれませんが、あなたはマネージャーの許可を求めずにコードを片付けるかもしれません。船外に出ないでください。最初にチームと話し合ってください。誰も来て、書くのに3か月かかった機能を使用してみてください。ハッキングされたために機能しないようです。

コードに大きな変更を加えることによる予算への影響と、変更を行わないことによる予算への影響を理解することを示すような方法で管理にアプローチします。エミリオの言葉遣いが好きでした。

「古い」コードは常にひどいものになることを念頭に置いておくことが重要です。つまり、開発者として絶えず成長しています。良いコードを書いてから、後でもっと良いコードを書くことを学ぶと、以前の「良い」コードはひどいようです。開発者の数が多すぎると、長期的に改善し続け、より多くのお金を無駄にしようと絶え間なくかかります。それはバランスのとれた行為です。言われているように、あなたが行くようにあなたがそれをより良くすることができるならば、それは常に素晴らしいです。その巨大な機能を変更するときは、分割してください！最終的にはどこかに行きます。

しないでください。

とにかく、ほとんどの場合、大規模なプロジェクトをゼロから書き直すことは大きな間違いです。

マネージャー、特にプロジェクトマネージャーに悪いコードとリファクタリングについて伝えるのは簡単だとは思いませんでした。第一に、彼らはあなたを信頼しなければなりません。たとえあなたが年長者であっても、あなたはまだ信頼される時間が必要です。第二に、彼らは単に問題がどれほど悪いか理解していない。今日が新しいビルドをリリースする最終日であり、ビルドが失敗した場合。彼らはそれがどれほど深刻かを知っていますが、悪いコード、不十分なテストなどの多くの問題のために、ビルドが失敗したことを決して知りません。

Webプロジェクトで構成タスクと展開タスクを完了しました。新しいビルドを展開するたびに、予期しない問題を修正するのに多くの時間がかかります。問題のほとんどは、セキュリティと統合（いくつかのWeb / Windowsアプリケーション間）でした。私たちのコードはひどく、他人のコードはひどく、完全にスパゲッティコードです。

新しいバージョンを計画していたので、バグが頻繁に発生するログイン/認証コードに詳細ログを追加するだけで、リファクタリングを強く求めました。マネージャーは同意しましたが、それは素敵なリストに入れられました。機能の大きなリストと厳しい時間枠がすでにあったので、それが行われるかどうかはわかりません。

マネージャーには2種類あります。何をするのかを理解するふりをするマネージャーとそうでないマネージャーです。ソフトウェアを理解するふりをする人はあなたに敵対的です。そうでないものは、単にあなたに悩まされます。

いずれにせよ、マネージャーはすべて嘘つきであるため、他の全員がそうであると想定する強い傾向があります。

私のポイントは、あなたがソフトウェアが古くなっていると言うなら、彼らは言い訳としてそれをとるだけだということです。彼らは気にしません。