新規開発の間隔が長いプロジェクトにどのように対処しますか？
私は複数のプロジェクトに携わっていますが、そのうちの1つは、2年間働いて、顧客のサイトで本番環境で使用されているソフトウェアを提供しました。
すべてが本当にうまくいき、顧客は最初のリリースから数か月後に戻ってきて、いくつかの変更を加えたいと言いました。これは多くの場合、彼らが望んでいるいくつかの新機能ですが、UIを変更したり、データ管理と視覚化に使用されるビジネスロジックを変更したりすることもあります。
このリリースの後、彼らはソフトウェアを使用して満足しています。私は他のプロジェクトで仕事を続けており、月に数時間だけ、サポートを提供したり、ベストプラクティスを指導したりしています。
リリースから1年後、彼らは新機能のリクエストで戻ってきました。私はコードベースを扱っていなかったので、実装の詳細を理解し、コードを埋め、内部ドキュメントなどを調べて、私たちが何をしたか、どのようにしたか、そしてその理由を把握するのに数週間かかりました。やった。いくつかの専門用語が使用されているので、使用されている用語を思い出すためだけにドキュメントを読む必要があります。
そして、最新のリリースから1年後、彼らは新機能のリクエストで戻ってきました。サイクルが繰り返されます。基本的に、これは次のタイムラインで説明できます。
- 1月-新機能のリクエストが来る。
- 1月-2月-新機能の開発、リリース、バグの修正。
- 3月-12月-コードベースにはまったく触れないでください。
- 来年1月-新機能のリクエストが来る。
明らかに、この最初の「準備」時間はできるだけ短くしたいものです。この情報を顧客にどのようにアプローチするかについても懸念があります。総作業時間は、新しい機能の構築ではなく、行われたことの把握などに費やされます。
継続的に開発されていないソフトウェアの新機能要求があり、リリース後に8〜12か月間隔で新機能要求が来る場合のベストプラクティスとこの状況に対処する方法は何ですか？
プロジェクトに継続的に取り組んでいる場合でも、プロジェクトが小さい場合を除いて、機能を切り替える必要があります。機能の中には、数か月または数年変更していないものもあります。
また、チームで作業している場合は、常に最初に記述していないコードベースの部分を発見する可能性があります。
では、プロジェクトの無駄な時間rediscoveringを減らすことができるのはなぜですか？
リファクタリング。これは、2年間コードを書いたときに何を考えていたのかを自問する時間を減らすことができる、最も重要な手法です。前。
新しい機能を開発するとき、アイデアを試し、アーキテクチャや設計をあまり気にしないのは珍しいことではありません。要件が不安定で、要件をどのように実装すべきかわからない場合があるからです。ただし、機能が実装されると、作業は完了しません。回帰テストの助けを借りて、戻ってコードをリファクタリングします。定期的に。
DocBrownで説明されているように 定期的にリファクタリングすることで、コードは自明になります。これは、数年後にプロジェクトに戻るときに大きなメリットがあります。コードとドキュメントを絶えず切り替える代わりに、理想的には、コードに従うだけで済みます。 SOLIDの5つの原則にも従うと、後で変更を加えることがはるかに簡単になります。場合によっては、既存のコードに触れることなく、新しい機能の新しいクラスを作成できることもあります。その他の場合、既存のコードを変更する必要がありますが、変更は1つまたは少数のクラスに制限され、他の場所でリグレッションが発生するリスクはほとんどありません。
アーキテクチャとデザイン。お持ちですか？ （あなたの質問からそう思われます）そうでない場合、コードから全体像を把握するのは困難です。したがって、理解が損なわれます。
スタイル。コーディング標準は、コードを読みやすくするため重要です。 DocBrownの優れたコメントで説明されているように ：
クラス命名標準は、変更しやすい正しいクラスを見つけるのに役立ちます。ローカル変数と非ローカル変数を区別するための命名規則により、計画された変更の影響を理解しやすくなります。さらに、既存のプロジェクトを探索するには多くのコードを読み取る必要があるため、コードを読みやすくするすべてのものがプロセスをスピードアップします。
通常、既存の標準を使用し、それをpre-commitフックで自動的に適用することで、共通のコーディング標準を適用するのは非常に簡単であるため、使用しない言い訳はありません。
ドキュメント。すべてを詳細に説明する100ページのドキュメントを書く必要はありません：itwill 退屈で、読むのが楽しくありません。ただし、いくつかの図は後で非常に役立ちます。さまざまな選択肢を文書化することも良い考えです。たとえば、既存のものを使用する代わりに独自のものを作成することにした場合は、その理由を説明してください。サードパーティのソリューションがシステムと互換性がないか、遅すぎるか、いくつかの厳しい制限がありました。
用語のリスト。質問からの引用：
いくつかの専門用語が使用されているので、使用されている用語を思い出すためだけにドキュメントを読む必要があります。
技術（またはドメイン）用語がたくさんあるプロジェクトでは、実際に用語のリストを作成していました。その場合の目標は、このリストを定期的に更新し、それらの用語を一貫して使用することです。
リストは可能な限り手頃な価格にする必要があります。読みにくい場合、あなた（とあなたのペア）はそれを使用しません。変更が難しい場合は、すぐに古くなります。自分に合ったフォーマットを作るには時間と練習が必要です。
何をするにしても、willは、自分で作成したコードであっても、2年後にコードを理解するのに時間を費やすことに注意してください。オープンソースプロジェクトを見てください。素晴らしい仕事をしている才能のある開発者によって書かれたものもありますが、それでも、プロジェクトに貢献する前に、プロジェクトを探索するのに数時間から数日を費やします。コードに違いはありません。何年もの間、すべての詳細を覚えることはできません。つまり、数年後にプロジェクトに戻ると、プロジェクトが他の誰かによって行われたのと同じ状況に陥ることになります。さらに、あなたのスタイルが変わったかもしれません。あなたは新しいツール、言語機能、APIを学びましたが、それは今日と2年前のあなたの間のギャップを広げることしかできませんでした。
実装の詳細に入るのに数週間かかりました
プロジェクトのサイズと実装の詳細の意味によっては、数週間を費やすことも例外ではない場合があります。顧客向けの機能を開発するのに4時間かかり、数週間と4時間の支払いを要求した場合、問題が発生する可能性があります。 機能を実装するために知っておく必要があることだけをプロジェクトについて学ぶようにしてください。
たとえば、製品がeコマースWebサイトであり、ユーザーが何かを購入した後のPDF請求書の生成方法が変更された場合、プロジェクトのごく一部しか必要ありません理解する。たとえば、商品がWebサイトにどのように表示されるか、カートがどのように機能するかを知る必要はありません。従来のスパゲッティコードベースでない限り、変更は請求書のPDF生成を処理するコードにのみ影響し、製品の他の部分には反映されません。
アレックス、顧客にリクエストが来る理由を話してみてください1月。
おそらく彼らは毎年予算を改善するためにいくらかのお金を持っていて、彼らは最初にそれらすべてをすぐに使います。しかし、今年の残りの期間、彼らは座って待たなければならないことは明らかです（お金を失っても改善されません）。
それは彼らが持っている予算が小さすぎることを意味し、あなたはそれを増やすためにビジネスケースを手伝うことを試みることができます。昨年の機能を取得し、会社が1か月に機能を持たない場合にかかる費用、再学習費用を含めて損失した金額を実際の金額で計算します。来年を待つよりも、予算を超えて注文する方が有益であることを説明します。あなたはより多くの仕事をし、いくらかの利益をもたらすので、それはあなたの問題を解決することができます。