保守性の問題があるプロジェクトで新しいチームリーダーとして何をすべきか？

保守性の問題を抱えたコードプロジェクトを担当しました。プロジェクトを安定した足場にするために何ができますか？

私は、単体テスト、IOC、MEF、静的クラス、純粋なデータセットなど、多くの重要なものが欠けている非常に大きな多層.NETシステムで作業している場所にいることに気づきました。わずか24年ですが、私はここに3年近く滞在しました（このアプリは5年間開発中です）。主に時間の制約により、他のがらくたに合うようにたわごとを追加しています。空き時間に多くのプロジェクトを行った後、これらすべての概念がどれほど重要かを理解し始めました。また、従業員の交代により、私はこのプロジェクトのチームリーダーになりました。このアプリを改善するためのスマートな方法を考え出したいと思います。経営陣に価値を説明できる方法。私は何をしたいのかというアイデアを持っていますが、それらはすべて前もって大きな利益を得ることができず、とても圧倒的です。人々がどのようにこれに対処したか、または対処したかについての物語は、非常に興味深い読み物です。ありがとう。

技術的負債を攻撃するための予算時間。ただやらなきゃ。最初に攻撃する部分は、開発者が現在最も多くの時間を費やしている場所によって異なりますが、理想的なことから始めるよりも、始めることが重要です。スクラムを使用している場合は、バックログに特定の技術的負債の部分を置き、それらを処理するまで機能のように扱います。

レガシーコードを効果的に使用することを強くお勧めします。おそらく役立つでしょう。私はそれを読んでいませんが、ユニットテストをレガシーコードに取り込むことに関する多くの情報があるようですので、それを修正して安全に最新のものにすることができます。

クレジットカードを管理と同様に使用します。何かを達成するのは非常に難しいため、あなたは自分が行うすべてのことに「関心を払っています」。技術的な負債を返済すれば、それらのリソースを解放し、将来より迅速に新しい機能を開発できるようになります。そうしないと、「開発期間中に支払われる」「利払い」が蓄積され続け、チームの新機能の生産が遅くなります。

たぶん、技術的な負債に苦しんでいる各サイクルに費やした時間を見積もって、すでにどれだけ蓄積されているのかを考え始めてください。保守可能なシステムでの修正または機能の変更がどのように見えるか、実際のシステムでどのように見えるか、どのような変更を行う必要があるか、またはそこに到達するための最初のステップとして適切かを説明します。

技術的な負債をバグ修正と追加機能に集約します。

改善への反復アプローチが最良の結果をもたらすことがわかりました。私の仕事のマントラは、触れるたびにコードの品質を改善することです。バグ修正であろうと機能であろうと、各作業は、修正/リファクタリング/クリーンアップできるものの分析から始まります。完了しなければならない作業と同等の規模でリファクタリングを試みます。

コードベースで問題の順序付きリストを作成します。全員がリストと優先順位を認識していることを確認してください。彼らが仕事を得るたびに、彼らはあなたが取り組んでいるコードに結びついたリストから問題を探すべきです。

これですべてが修正されるわけではありません。多くの時間とリソースを必要とするリファクタリングまたは修正がいくつかあります。私は通常、それらを他の有益な大きな作品に結び付けようとします。

明らかなことを言っているだけかもしれませんが、ちょっと。

問題のあるコードチャンクを実行する小さなユニットテストを作成し、そのチャンクをリファクタリングして、テストが引き続きパスすることを確認します。コードの別のチャンクに移動します。このコードは、構築したばかりの堅固な地面の小さな部分から最も簡単に到達できます。泡立て、すすぎ、繰り返します。

これは、コードベースにもう少し慣れるのにも役立ちます。

しばらくそれを行った後、さらにリファクタリングを拡張する時が来たことがわかります。重複したコード、DRY原則への違反...を理解する、あなたが知っている、通常のもの。それまでに、ほぼ間違いなく適切なコードカバレッジが得られます。これにより、メソッドをシャッフルしたり、インターフェイスやこれらすべての機能を抽出したりできます。

ハッキングを開始する前よりも常にコードベースを少しだけ残してください。それほど長期的ではないにしても、それが報われる小さな投資であると確信しています。

どこから始めればいいのかというアイデアのために、このプロジェクトが抱える技術的負債を説明してみることができます。また、従業員の交代のためにコードを理解するのに時間がかかることを交渉しようとすることもできます。これは、テストがバグを防ぎ、より簡単にするために、より良い将来の開発を確実にするためにいくつかのテストを入れることを意味しますおそらくプロジェクトに取り組む新しい人々。

そのような場合、私は可能な限りプロジェクトを合理化しようとしています。前進するために絶対に必要な機能を見つけてください。長い間使用されてきたシステムには、おそらく非常に長いバックログがあります。これらのアイテムの多くは重要であり、多くは「ベルとホイッスル」になります。

テストに関しては、単体テストは間違いなく役立ちますが、テストに参加してバグをチームメンバーに提出するように、技術スタッフ以外の人に依頼することもできます。

がんばろう。

1つの選択肢は、履歴書のほこりを払い、就職活動を開始することです。

自問すべき良い質問は、このひどく実行されているプロジェクトが、会社全体の運営方法を示しているかどうかです。答えが「はい」の場合、ひどく経営されている会社にとどまるのに十分な報酬を得ているかどうかを尋ねます。

多くの場合、パフォーマンスのアップグレードであるか既存のバグを修正することを伝えることができれば、経営陣によるリファクタリングをプッシュできます。特に機能する場合は、何かを変更するだけでリファクタリングしないでください。バグ修正時間は、とにかくすでに存在しているので、リファクタリングに適合する良い方法です。積極的になり、あなたの仲間のコーダーよりも若いので、それを見ないでください。単体テストに参加するなどの小さなことから始めて、そこから作業を行うと、管理を取得して他のことのサイクルを提供できるいくつかのバグが明らかになる場合があります。

現在、.NETのBrownfield Application Developmentを読んでいますが、これは基本的に、現在抱えている問題への対処方法に関するものです。これまでのところ、私はそれが言うことの大部分が好きです（まったくすべてではありません-しかし、これはあなたが問題を完全に規定することを意図したものではなく、問題を通してあなた自身の方法を考えるのを助ける一種の本です）。それはいくつかの方法で役立つかもしれません-それはあなたが一人ではないことを示しています。うまくいけば、いくつかの問題に対処する方法についてのヒントが得られるでしょう。

基本的に、ほとんどのアプローチに同意します。一晩ですべてを修正することはできませんが、非常に小さなステップで段階的に改善することができます。そして、はい-技術的負債は、あなたが使用する必要がある比isです。

最終的には、あなたの人々がプロジェクトにどれだけ優れているかによります。混乱を引き起こしたのが同じ乗組員である場合、同じグループでそれを改善する可能性はほとんどありません。スタッフを分析し、最も弱いメンバーを見つけて交換します（そうする能力がある場合）。

「雌豚の耳から絹の財布を作ることはできません」。