保守不可能なコードベースを継承した場合はどうしますか？
重複の可能性：
ゴミをリファクタリングして健全性を維持するためのテクニック？
スパゲッティコードの200K行を継承しました—今はどうなりますか？
私は現在、2人の他のPHP=私以外の開発者と1人のジュニア開発者と一緒に会社で働いています。
私たち全員が取り組んでいるシステムを最初に構築した上級開発者は辞任し、ここに数週間しか滞在しません。システムについて何かを知っている唯一の人である他の開発者は、ここで不満を抱いており、新しい仕事を探しています。このコードベースの経験豊富な開発者として、私が取り残される危険性は非常に高いです。
私はこの会社に入社してから、より良いコーディング標準やプロジェクトドキュメントなどを求めてプッシュを試みましたが、順調に進んだと思いますが、コードの大部分は単に保守不能でコメントもありません。これの多くは、私が参加する前のプロジェクトのある時点で物事を迅速に行う必要性に関係していますが、今では、搭載されているシステムを理解している2人の開発者であっても、技術的な負債が莫大です。それらがなければ、それで何かをすることは単に不可能です。シニア開発者は、彼が去る前に少なくともすべてのコードにコメントを付けるよう努めていますが、コードベースが広すぎるため、残りの時間を適切に文書化できないと思います。その上、彼がコメントするとき、それはまだそれが可能な限り明確にすることをしません。
システムがよりよく整理されて文書化されていれば、おそらく段階的にリファクタリングを開始できますが、全体が緊密に結合されているため、他のモジュールで意図しないノックオン効果なしに1つのモジュールで変更を行うことは非常に困難です。当然、単体テストもありません。正直に言って、このコードベースは、実装方法を考えると、とにかく単体テストできるとは思いません。
また、3人の開発者と1人のジュニア開発者がいても、物事を完了するのに十分な時間がないようです。 1人の開発者と1人のジュニアがいて、どちらもシステムの初期設計に重要な入力をしていなかったため、現在のシステムを機能させ、必要に応じて新しい機能を実装し、代替を開発することで、何ができるかわかりません。より適切に編成された現在のコードベース。
この状況に対処するために取れるアプローチはありますか、またはこの時点で自分のCVも順番に取得する必要がありますか？もし私とジュニアデザイナーだけが去るのであれば、私は後者のオプションにほとんど疑問なく行きます。ただし、フロントエンドの開発者とコンテンツマネージャーのチームもあり、開発者がいないような立場に置いておくとどうなるのか心配です。そのような状況下では、部署が完全に閉鎖される可能性があり、私は彼らの失業も私の良心にあると思います！
あなたの状況と私が3年ほど前に経験した状況との類似性は恐ろしいものです。
- 同じ設定：ドキュメント化されていない、カウボーイコーディング
- 物事を作った「先輩」の男はなくなった
- 残りの人たちは既存のコードベースについてある程度知っていますが、多くは知りません。
- それは「機能する」として提示され、私の仕事は「いくつかの追加機能を追加するだけで、大きな再コーディングは必要ない」として紹介されたと思いました。
これに対する最善のアプローチは何なのかわかりませんが、私がどのように対処したかをお話しします。
まず、カウボーイコーディング環境とドキュメントの欠如（そして私の場合はテスト）は誰にとっても良いことであると考えられていたため、ドキュメントの作成、テストインフラストラクチャの実装などに時間を費やしたという意味で変更を提案しました。最初から正しい。私がやったことは、これらすべてを「最低限で」実装することです。実際にそれをタスクとして宣言せずに、コードを整理し、svnに入れ、ドキュメントを作成し、基本的なユニットと統合を行うだけで、1日1〜2時間（最初の2〜3週間など）を費やしてみましたテスト。機能テスト、CI、およびより高次の組織的なものは、そのようなセットアップでは問題外だったので、無視しましたが、少なくともある程度の進歩はありました。
次に、実際にそのように宣言することなく、「新しい機能を追加するだけ」というタスクをそのまま受け入れましたが、代わりに、そのタスクの影響を受けたモジュール全体を再処理しました（実装可能なタスク）。私は単に追加の時間を要求しましたが、実際にそれを宣言せずに、まず既存の製品コードを作り直してから、追加の機能を追加しました。ここでの良い点は、元のコードは、しばらくは製品化されていたにもかかわらず、非常に悪く、パフォーマンスが悪かったため、単純で常識的なリファクタリングによって大幅に高速化され、追加の時間の承認を得たことです。要求した。
結局、この2〜3か月後、私は別の仕事を探し始めました。これは長期的にやりたいことではないことが明らかだったからです。要するに、私は約5か月後にこの仕事をやめました。その間に、私が要求した機能のすべてではなく、適切な部分を実装することができました。
さて、ここで私がすべてから学んだことは次のとおりです。確かに、可能であればそのような仕事を避け、ソフトウェア開発プロセスがそれが何であるかを認識し、尊重して扱うクリーンで構造化された環境で作業することをお勧めします。一方、このような状況での短い作業期間は、このようなプレッシャーのある環境での問題への対処方法について多くのことを教えてくれたことを否定できません。また、優れたソフトウェア開発に必要なすべてのプロトコルと方法論にも感謝しています。
要するに、これに数か月の余裕があれば、それを実行してください（近い将来に明確な方法がある限り）それは興味深い経験になります。そうでない場合は、できるだけ早くそのままにして、それで終了します。
その質問に対する簡単な答えはありません。
あなたが書いたものから、最大の問題はプロジェクト管理の1つであるように見えます。あまりにも多くのタスクが速すぎて実行されました。世界最高のコーディング標準や自動テストなどを実装できますが、この実践が続けば、すべてが無意味になります。最初に機能と期限から、遠方の3分の1の品質から最初に品質に思考を変更し、2番目または3番目の考え方の機能または期限のいずれかを選択する必要があります。
これを改善するには、経営陣と話し合う必要があります。それはあなたの直接の経営者の責任ではないかもしれません。おそらく、ビジネスの状況が変化している、または顧客が困難になっているかもしれませんが、それは対処する必要があるものです。これに対処できない場合は、離れてください。開発者が悪い会社を必要とするよりも、企業は良い開発者を必要とします。
そのためのコミットメントを得ることができると仮定して、変更または拡張してより良いものにする必要があるものなど、製品の小さな部分から始めます。コーディング作業があるときはいつでも、見積もりに少しパディングし、何かを修正または改善するのに少し時間を費やしてください。
同時に、コードレビュー、自動化された単体テストの使用など、より良いプラクティスの実施を開始します。これはすべての開発者、特に上級開発者にとって必須です。
Michael Feathersは、コードをよりテストしやすくするためのリファクタリングに関する素晴らしい本レガシーコードで効果的に動作するを持っています。 PHPツールには慣れていませんが、コーディング標準を適用するための 。NETStyleCop に相当するものは確かにあります。また、システムをサードパーティのライブラリで置き換えることができるため、メンテナンスの負担が軽減され、コードの品質が向上する可能性があります。
また、いくつかのメトリックの収集も検討してください。クリーンアップされたコードベースの量、おそらくコードのパーセンテージまたはコンポーネントの数を追跡することは価値があります。管理に対する作業の利点を示す1つの方法は、古いコードの欠陥検出率と数を、クリーンアップされたコードと比較することです。もう1つは、古いコードと新しいコードの変更を完了するのにかかる時間を確認することです。
いくつかのコンポーネントでこれが成功したら、システム全体の設計について他の開発者と協力してください。システムは実際にどのように機能する必要がありますか？これは、特に製品が急速に変化している場合は難しいかもしれませんが、システムの高レベルの設計は、漸進的な変化に向けて熱望するものです。それがなければ、個々のコンポーネントの品質は向上しますが、システムは混乱します。
その後、あなたは自分がどこにいるかを再評価するような状況になるはずです。
私が対処したい最後のポイントは、他の開発者へのあなたの負債です。あなたが書いたものから、製品の状態はあなたの責任ではありません。ソフトウェア開発者は互いに強い絆を感じる傾向があり、私たちの多くがこの業界を愛する理由の1つです。壊れた製品を修正すると、CVで見栄えが良くなります。否定性と無益さに溺れると、あなたは夢中になり、あなたを燃やします。あなたはどこに線を引くかを知り、自分たちの世話をする人を信頼する必要があります。
これにはいくつかのアプローチがありますが、基本的に多くは管理サポートに依存します。そして、テスト可能で文書化されたコードベースの意味の違いを理解している管理者がいない場合は、CVを磨くことが最良のルートになるでしょう。
並列環境はありますか？私が最初に提案するのは、回帰テストフレームワークを導入することです。本番データの定期的なスナップショットを取り、それを並列開発/ UA環境で使用します。次に、本番環境にリリースする前に、リファクタリング、新規、または編集されたコードのテストを開始します。
ユニット/統合/システムテストを最初から実行できない場合は、少なくとも新しいコードや変更されたコードを適切にテストする必要があります。そのための並列環境が必要になります。そうすれば、少なくとも、自分が加えた変更にある程度の自信をつけることができます。
テストを実施したら、問題の範囲を推測し始めることができるように、カバレッジツールを入手してみてください。
自動化されたドキュメントも調査する-私は現在.netの世界にいて、自動化されたドキュメントを有効にして、不足しているドキュメントを警告としてマークすることができますが、オプションで警告をエラーとして処理することで、ドキュメントがない場合にビルドが失敗します。穴を見つけるのに本当に役立ちます。 goodコメントの作成には役立ちませんが、一般的には何もないよりも良いものがあります。
そして、管理にプッシュバックします-すべての開発者は、物事を成し遂げるのに十分な時間がないと彼らに告げますが、たとえそれが「今日より遅く」になったとしても、テストとドキュメントを含めるために見積もりに間に合うように始めることができれば「明日のランチタイム」などの場合は、すぐに配当を得ることができます。
また、ジュニアにいくつかの優れた実践方法を教えることになります。もし両方が数年経ってもまだいるのであれば、それも大きな勝利となるでしょう。
あなたが辞任して部門が閉鎖された場合、あなたが会社に最近加わったと仮定して、私はあなたに責任を負わせることはありません。しかし一方で、6か月以上滞在していて、anyone（少なくとも、だれか重要）現在の規格についてあなたがどう思うか分からない人は、私があなたに部分的に責任を負うと思います。
仲間の開発者に単に「コードにコメントするべきだ」と言うだけでは十分ではありません。コードが保守不可能な場合、それはあなたの責任です。つまり、あなたの仕事の一部-同僚やチームメイトから管理とサポートに至るまで、誰もがそれを確実に知るようにすることです。彼らが気にしないなら、あなたはそれを受け入れるか、去ります。
あなたは去らなかったので、暗黙のうちにそれを受け入れました。あなたは自分のコードをテストしたりコメントしたりしているとは言わないので、あなたはそうしていないと思います。今、その「技術的負債」はすべてねぐらに帰っている。次の3つのオプションがあります。
- カットアンドラン、新しい仕事を見つけます。おそらく、何かが起きるまで現在の仕事を続けている間、あなたはこれをずる賢く行うでしょう。これは、問題が乗り越えられない、リスクが高すぎる、または大変な作業であると思われる場合に行います。コードがあなたの言うとおりである場合、物事は非常にすぐに醜くなるかもしれないので、すぐに調べ始めます。
- ステップアップし、自分を新しいシニア開発者として位置付け、混乱を修正します。あなたがそれをしているなら、あなたは自分自身を証明する機会があります。ただし、タスクに投資する前に発生する必要がある依存関係をいくつか添付します
- あなたの経営陣は、あなたが問題を解決していること、物事が正しく行われていないこと、プロセスを変える必要があることを理解する必要があります。問題の一部になっている場合は、ここで苦労するかもしれません-しばらくそこにいた場合、間違いなく上司は「だから、これが起こっていることを知らせなかったのはなぜですか」と言うでしょう。
- あなたはシニア開発者への昇進を得る、それはあなたが物事をあなたが望む方法で起こすための権限を得ることを意味するはずです。彼らがあなたが仕事をすることができると信頼しないならば、これは起こりません。
- 何もしない。今までと同じように顔を上げて支払いを受けるだけで、問題の修正を担当する上級開発者を他の人に雇うことができます。ストレスを感じないでください。
コードは常にテスト可能な状態に操作できます...時間があるかどうかにかかっています。
レガシーコードで効果的に動作するを読んで、テストを実施するための戦略を特定することをお勧めします。
誘惑は全体を捨ててゼロからやり直すことです...これはほとんど常に 間違ったこと （だから Joel Spolskyと言います なので、それは本当だ！）。
私はこの会社に参加して以来、より良いコーディング標準、プロジェクトドキュメントなどを求めてプッシュを試みました
あなたがプロジェクトに残る唯一の経験豊富な開発者になるつもりなら、これはより良いコーディング実践を紹介する絶好の機会のようです。
管理チームとオープンになり、現在の状況を説明し、既存のコードベースを操作する前にコードベースに取り組む時間が必要であることを説明します。
コメントなしで1行ずつコードに取り組むのは気が遠くなるように思えるかもしれませんが、その後、ソフトウェアがどのように機能するかを正確に理解できるようになり、将来の追加が簡単に実装できるようになります。
そして最後に...新しい仕事は時々チケットだけの場合もありますが、それから3か月が経つと、まったく同じ立場にいるかもしれませんが、重要な問題（つまり、コーディング標準！）への影響は少なくなります。