私たちのコードが悪いことを経営陣に伝える正しい方法は何ですか？
私たちのコードは悪いです。常に悪いとは考えられていなかったかもしれませんが、それは悪いことであり、下り坂になるだけです。大学を卒業して1年も経たないうちに、コードの内容の多くが信じられないほど私を困惑させました。最初は、コードベースについてもう少し学ぶまでは、新しい人として口を閉ざすべきだと思いましたが、それが悪いことだと知っていることはたくさんあります。
ハイライトのいくつか：
- 私たちはまだフレームを使用しています（クエリ文字列から何かを取得してみてください、ほとんど不可能です）
- VBScript
- ソースセーフ
- 私たちは.NETを「使用」しています-つまり、COM DLLを呼び出す.netラッパーがあり、簡単にデバッグすることはほとんど不可能です
- すべては基本的に1つの巨大な機能です
- コードは保守できません。各ページには、新しいページが作成されるたびに作成される複数のファイルがあります。メインページは基本的にResponse.Write（）を何度も実行してHTMLをレンダリングします（runat = "server"？方法はありません）。その後、クライアント側（VBScript）に多くのロジックが存在する可能性があり、最後にページがそれ自体に送信され（多くの場合、多くのことを非表示フィールドに格納します）、保存などの処理を行う処理ページにポストします。データベースへのデータ。
- 得られる仕様は笑える。多くの場合、彼らは「フィールドXにフィールドYまたはフィールドZを自動入力する」のようなものを要求し、フィールドYまたはフィールドZをいつ選択するかを示しません。
これはソフトウェア会社に雇われていないせいだと思いますが、ソフトウェアを書いている人は少なくともコードの品質に気を配るべきだと感じています。締め切りが迫っているので、何かを起こせばすぐに何でもできるとは想像もできませんが、私たちは悪いコードを書き続け、悪い習慣を使っています。
私に何ができる？これらの問題を解決するにはどうすればよいですか？私のチームの75％は私に同意し、過去にこれらの問題を提起しましたが、何も変更されません。
過剰反応していないことを確認してください。あなたはフレッシュで、おそらく他の多くの場所で働いたことがないので、「実際のコード」の世界に備える準備ができていません。実際のコードは恐ろしいものです。それはあなたのニースの学校のコードのようであり、あなたの執拗に微調整された個人的なプロジェクトのコードは原子炉の地下室でセックスし、赤ん坊は有毒廃棄物の下水道で育ちました。それは恐ろしい変異体です。
しかし、あなたが正しいと仮定し、コードがあなたが言うほど悪い（つまり、通常悪いコードよりも悪い）場合、心配することは正しいでしょう。チームに相談して、他の全員が味方になっているかどうかを判断します。それは状況を改善するための作業を必要とします-チームの他のメンバーが問題を認識しても気にしない場合は、あなたの時間を無駄にしています。
あなたはジュニアなので、おそらくあなたはリードする立場にありません。自分で経営に行った場合、後輩も兼ねた新入社員として、あなたの意見はおそらく無視されます。あなたのリード開発者または関与している最上級の人の1人を入手してください。繰り返しになりますが、関心のある高齢者がいない場合は、時間を浪費しています。
上級の技術者に興味を持ってもらえるとしたら、問題のある領域と考えられる解決策を特定することに取り組みます。たとえば、「すべてが基本的に1つの巨大な関数」である場合、次にその「巨大な関数」で作業するときには、少しリファクタリングする必要があります。繰り返しますが、すべての人を内面に取り込む必要があります。問題の小さな部分を削ぎ落とし、少しずつ改善していけば、最終的には問題がずっと少なくなります。コードに触れるたびに、改善できるかどうかを検討してください。
あなたは経営陣に腰を下ろして「すべてが悪いので書き直す必要がある」と言うつもりはありません。それは彼らにとって意味がありません-多くの費用がかかり、潜在的に非常に危険です。代わりに、問題があること、および変更が加えられたときに徐々に改善する計画があることを彼らに知らせる必要があります。彼らは、保守可能なコードの利点について教育されるべきです。これは、あなたからではなく、技術的および専門的に信頼できる上級者からのものでなければなりません。
完全に書き直しますか？ほとんど常に悪い考えです。
結局のところ、あなたが新しいのであなたができることは多くありません。誰も物事を改善したくない場合は、あなたの経験を集めて次の場所に移動します。
読む Joel On Software -絶対にしてはいけないこと彼の推論を理解してから、不良ソフトウェアに関する他のいくつかの記事とそれを修正する方法を読んでください。この情報で武装すると、マネージャーが理解し、気にするという点で、それを修正するためのケースを提示することができます。ヒント：優れたマネージャーは、プログラマーの意見や何をすべきかについての感情だけに基づいて時間とお金を費やすことはありません。
「このコードはがらくたで、書き直しが必要です」は、たとえあなたが技術的に正しいとしても、間違いなくあなたに投げ戻されるでしょう。
「現在のプロジェクトスケジュールから数か月を費やすことができ、コストを抑えて信頼性を高めることができます。」彼らの注意を引くだろう（彼の段階でこれを行う方法についての言及がないことに注意してください）。
何を言おうと、あなたが正しいことを確認してください。それが悪いと言うなら、あなたの書き換えは血まみれの良いものでなければなりません.1週間かかると言うなら、それは1週間であることを確認し、良いことをすべきです。手直しを行わなかった場合に何が起こったかに関係なく、手直ししたコードに欠陥があると、個人的に、非常に高くつきます。誰かがあなたの前にそこにいて、書き直しを台無しにしたり、売り過ぎたりした場合、あきらめて、マネージャーは馬鹿にされるのを嫌い、それを2度起こさせません。その意味で、後続の人たちのためにそれを台無しにしないでください、あなたはこれで一発しか得られません...
一定期間またはプロジェクト数にわたってコストを分散させる方法を見つけます。マネージャーはリスク、投機的な投資、マイナスのキャッシュフローを嫌います。これらのマネージャーの許容範囲内で作業してください。小規模でリスクが低く、低コストの提案から始めます。正しいことが証明されたら、より大きな魚に行くことができます。
まず第一に、あなたがスタートアップで働いて、あなたが元の間抜けなレガシーコードを作成したのでない限り、プログラマーとして働いているどこにでも間抜けなレガシーなものを見つけるでしょう。あなたがプログラミングのキャリアを持つことを計画しているなら、あなたはこれらのパンチで転がることができなければなりません。
第二に、古いシステムを改善するためにコストを考慮することがよくあります。たとえば、10年前のVB6とクラシックASPアプリケーションがまだ動作している会社が複数あることを確認しました。場合によっては、.NETを移動する大きなプロジェクトがひどく失敗したことが原因でしたその他の理由は、「壊れていなければ修正しない」という理由でしたが、レガシーシステムによって引き起こされた問題は無視できないほど大きいため、移動のコストは正当化できます。
過去に大きな失敗があった状況では、変化をもたらすことはほとんど不可能です。その場合は、履歴書を磨き、新しい仕事を探し始めます。コードが壊れていない場合は、コード自体について不満を言うことはないでしょうが、充実したキャリアパスを進んでいませんでした。それが壊れていて、それがあなたのケースにあるように思えるなら、それはあなたが変更の機会を持っているときです。
私がこれまで見てきた最善のアプローチは、過度に食い込むことではなく、最も良い影響を与える漸進的な変更から始めることです。あなたの説明に基づいて、変更リクエストをより適切に管理することから始めます。それが制御できるようになったら、サービスフレームワークの作成やその他の段階的な設計/コードの改善を検討することができます。
私が見た中で最悪のアプローチは、レガシーシステムから最新かつ最高のものに直接飛躍することです。たとえば、機能しているが不格好なVB6 /クラシックASP/COM +システムからMVC/Entity Frameworkシステムにジャンプします。
「やあボス、私とチームはコードを整理するのに理想的にはXか月かかります。すべてが非常にまとまっていないため、数分でできるはずのことには数時間かかります。それができない場合ビッグプロジェクトの直後に、現実的なスケジュールを計画したいと思います。」
（質問に対するAzkarのコメントから部分的に言い換え）
読み始めてください Joel on Software （Joel Spolsky/Founder of Stack Exchange）...
私が最初に行うことは Joel Test を実行することです。
これにより、「開発者として改善する方法を探していたときに、開発環境に関するこの12の質問テストに出くわしたので、楽しみのために、自分がどこで働いているかについて回答しました」と提示できます。 ...これにより、サードパーティとなり、個人的にではなく、コードの問題点の概要を説明します。
Pragmatic Practices の詳細を読むと、自分を改善し、red/green/refactorなどを実装することになります。これにより、コードベースをクリーンアップして、保守が可能になります。 （時間とともに）
お役に立てば幸いです。プログラミングへようこそ（昨日のコードは通常最低です）;-)
クイックヒント：理由のリストを使用して管理を提案する場合なぜ別の方法でコーディングする必要があります。「プログラマの士気/労働条件の改善」を引数として含めます。
技術チームは、この現在の混乱よりも多くのコンテンツを記述してクリーンなコードを維持することを明確にしてください。これにより、作業に対する態度を確実に向上させることができます。有用な議論になる可能性があります。
- 経営陣は実際にデザインを決定しますか？チームのほとんどがあなたの後ろにいる場合、何があなたを阻んでいますか？積極的に行動し、グループとして決定します。 段階的に実装する計画を考えてください。じゃやれ。
- 経営陣が使用する開発ツールを指示していますか？ツール管理を交換するための時間コストがない限り、通常は気にしません。積極的に行動し、どの開発ツールを使用するかをグループとして決定します。経営陣からの買収が必要な場合は、移行計画と費用対効果分析を提示してください。次にそれを実行します。
- 経営陣が使用する言語を規定していますか？積極的に行動し、グループとしてVBScriptの代わりに何を使用するかを決定します。 それを段階的に実装する計画を考え出して、それを実行します。経営陣が必要な場合は、計画を提示します。じゃやれ。
- スペックはありません。これは通常、職場の人とプロセスに大きく依存します。何が壊れているかを特定し、プロセスを修正するために必要な最小限の変更を行うには、現在、物事がどのように機能し、どのように機能すべきかを分析、理解するのに時間がかかります。あなたが計画を考え出して、経営陣を説得することができることを知っているなら。
表示するビジネス値がない（またはソフト）専用の時間を大量に含まない変更方法を提案する場合、より多くの変更と尊敬を得るそれ。
経験から言えば、それは簡単ではありません。それはほとんど不可能です。経営陣は、コードがひどいことを気にしておらず、直面する問題を完全に無知または無知であるか、またはまったく知らないか、または彼らはずっと前にそれを修正していて、今日それで立ち往生しないでしょう。あなたができる最善のことは、コードが吸う理由のリストを作成し、それから背後にある推論whyは、コードのリファクタリング/書き換えで実際のビジネス価値を実証するために吸うことです。
たとえば、「コードは保守できません」の場合があります。
[〜＃〜] x [〜＃〜]、[〜＃のため、現在のコードはメンテナンスできません〜] y [〜＃〜]と[〜＃〜] z [〜＃〜]（リストの理由なぜそれが維持できないのか）。 [〜＃〜] x [〜＃〜]、[〜＃〜] y [〜＃〜]、[〜＃〜] z [〜＃〜]（変更を加えることが難しい理由）。変更は難しいため、開発チームはバグの修正や改善に簡単に対応できません。
あなたの唯一の希望は、上司と上級管理職がコードにどのような影響を与えるかを理解するのにあまりにも愚かではなく、問題に対処するための新機能のリクエストを出さなくても構わないことです。それ以外の場合、あなたの努力は無駄になります。 。過去の経験から言えば、彼らはコードに何も問題がないと思う可能性が非常に高く、そして/またはあなたの同僚は管理に彼らの懸念をもたらすには余りにも鋭くないです。
幸運を。必要になります。
「私は大学を卒業したばかりです」-あなたの質問に答えるべきです。
経営陣はおそらく、コードが最適ではないことを知っています。ほとんどのコードは、Ray Gosling、Guido Van Rossum、またはそれを書くのに本当に優れた、そして高価な他の誰かを雇わない限りです。
経営陣はまた、あなたの会社に当てはまる「機能」の定義を使用して機能することも知っています（クラッシュしない、販売しない、レポートを配信しないなど）。
彼らは、最小限のコストでコードを「機能させる」ことを望んでいます。彼らはすべてを書き直すための高価なプロジェクトの提案を望んでいません。
あなたの成果物はエレガントなコードではない実用的なソフトウェア（すでに持っているもの）なので、ビジネスケースを作ることはほとんど不可能です。
ソフトウェアでは、最初に機能を市場に出すことによって大きな機会費用が発生するという事実を付け加えてください。あなたが本当にそれについて考えるならば、時間投資の長期的な回収は保証されません。
そうは言っても、管理可能なバイトの途中で小さな要素（適切なVSSを取得するなど）をリファクタリングして修正することは、依然として良い計画です。結局のところ、これは管理上の問題ではなく技術的な問題です。あなたが約束したことを実行しながら、やらなければならないことをやればいいのです。たとえあなたが強い主張をしたとしても、経営者はおそらくコード品質の骨の粗末な詳細に興味を持っていないでしょう。
できるだけ早く出発してください（仕事のホッパーのようになりたくないので、あまり早く出発しないでください）。彼らのコードがめちゃくちゃで、人々がそこにとどまっているという事実は、あなたが貧しい開発者と協力している可能性が高いことを意味します。自分の仕事に関心があるきちんとした開発者は、そのようながらくたに長く取り組むことはありません。
あなたがそれが非常に明確にそれを示すことができない限り、書き直しがかなり低い確率で起こる可能性は、投資の$$$の価値があるでしょう。
管理者はコードを気にしません。彼らは販売する製品を持っていることを気にします。
レガシーシステムが本当に、本当に悪くて、チームの大部分に途方もない量のオーバーヘッドを追加している場合（私は大多数と言います）大きなチャンクまたはすべてをコード化し、それをバックのように知っている人が常にいるからです彼の手）次に、それらに近づき、開発期間にビジネスコストがかかると言います。これは、顧客満足度に影響を及ぼします。
ただし、繰り返しになりますが、彼らはコードを気にせず、製品を気にします。そのため、その答えによって「そうすることができます」と思われるかもしれませんが、マネージャーの許可を求めることなくコードを整理することもできます。やり過ぎないでください。最初にチームと話し合ってください。誰も来て、3か月かけて書いた関数を使ってみませんか。ハッキングされたため機能しないようです。
コードに大きな変更を加えることによる予算への影響と、変更を行わないことによる予算への影響を理解していることを示すような方法で、管理に取り組みます。エミリオの言葉遣いが好きだった。
「古い」コードは常にひどいものですが、覚えておくことが重要です。つまり、私たちは皆、開発者として常に成長しています。良いコードを書いて、後でより良いコードを書くことを学ぶと、以前の「良い」コードはひどいようです。あまりにも多くの開発者が絶えずそれを改善し、長期的にはより多くのお金を浪費しようとすることに夢中になっています。それはバランスをとる行為です。そうは言っても、あなたがあなたが行くにつれてそれをより良くすることができればそれは常に素晴らしいです。その巨大な関数を変更するときは、分割してください！最終的には、どこかに到達します。
しないでください。
とにかく、大規模なプロジェクトを最初から書き直すのは、たいていの場合大きな間違いです。