私のチームは、リファクタリング後の頻繁なエラーをどのように回避できますか？

少し背景を説明すると、私は約12人のRuby on Rails開発者（+/-インターン）を抱える会社で働いています。リモートワークが一般的です。当社の製品は2つの部分で構成されています。かなり太いコア部分と、それに基づいて構築された大規模な顧客プロジェクトまであります。通常、顧客プロジェクトはコアを拡張します。重要な機能の上書きは発生しません。コアには、リファクタリングを急ぐ必要のあるかなり悪い部分があると付け加えます。仕様はありますが、主に顧客プロジェクト向けです。コアの最悪の部分はテストされていません（そうではありません...）。

開発者は2つのチームに分かれており、スプリントごとに1つまたは2つのPOを使用しています。通常、1つの顧客プロジェクトは、チームとPOのいずれかに厳密に関連付けられます。

ここで私たちの問題：むしろ頻繁に、お互いのことを壊します。チームAの誰かがコア機能Yを拡張またはリファクタリングすると、チームBの顧客プロジェクトの1つに予期しないエラーが発生します。ほとんどの場合、変更はチーム間で発表されないため、ほとんどの場合、予期しないバグが発生します。POを含むチームBは、機能Yが安定していると考え、リリース前に変更を認識せずにテストしませんでした。

これらの問題を取り除く方法は？どのような「発表テクニック」を勧められますか？

Michael C. FeathersによるLegacy Codeの効果的な使用を読むことをお勧めします。自動化されたテストが本当に必要である、それを簡単に追加する方法、まだ持っていない場合、そしてどのような方法でリファクタリングするための「コードの匂い」を説明しています。

それに加えて、あなたの状況におけるもう一つの中心的な問題は、2つのチーム間のコミュニケーションの欠如のようです。これらのチームの大きさは？彼らは異なるバックログに取り組んでいますか？

アーキテクチャに応じてチームを分割することは、ほとんど常に悪い習慣です。たとえば、コアチームと非コアチーム。代わりに、機能ドメインでクロスコンポーネントのチームを作成します。

コアの最悪の部分はテストされていません（...）。

これが問題です。効率的なリファクタリングは、一連の自動テストに大きく依存しています。あなたがそれらを持っていない場合、あなたが説明している問題が表示され始めます。これは、Rubyのような動的言語を使用する場合に特に重要です。Rubyには、メソッドにパラメーターを渡すことに関連する基本的なエラーをキャッチするコンパイラーがありません。

ユニットテストを改善するための以前の回答は良いのですが、アドレス指定にはもっと根本的な問題があるかもしれません。顧客プロジェクトのコードからコアコードにアクセスするには、明確なインターフェイスが必要です。この方法により、インターフェイスを介して観察される動作を変更せずにコアコードをリファクタリングしても、他のチームのコードは壊れません。これにより、「安全に」リファクタリングできるものと、必要に応じて（おそらくインターフェースを壊す）再設計が必要なものを簡単に知ることができます。

他の回答では重要なポイント（より多くの単体テスト、機能チーム、コアコンポーネントへのクリーンなインターフェイス）が強調されていますが、欠落していると思うポイントが1つあります。それはバージョン管理です。

リリース¹を実行してコアの動作をフリーズし、そのリリースをプライベートアーティファクト管理システム²に入れると、顧客プロジェクトはコアバージョンXへの依存関係を宣言でき、次のリリースXで壊れることはありません+ 1。

「アナウンスメントポリシー」は、各リリースとともにCHANGESファイルを使用するか、新しいコアリリースごとにすべての機能をアナウンスするチーム会議を開催することになります。

また、「コア」とは何か、そしてその「キー」となるサブセットをより適切に定義する必要があると思います。「正しく」「重要なコンポーネント」に多くの変更を加えることは避けているように見えますが、「コア」には頻繁に変更を加えることができます。何かに依存するためには、それを安定させる必要があります。何かが安定していない場合、コアと呼ばないでください。「ヘルパー」コンポーネントと呼ぶことを提案できますか？

編集：セマンティックバージョニングシステムの規則に従う場合、コアのAPIの互換性のない変更は、メジャーバージョンの変更でマークする必要があります。つまり、新しいものを追加するだけでなく、以前に存在していたコアの動作を変更したり、何かを削除したりします。この規則により、開発者はバージョン「1.1」から「1.2」への更新は安全であるが、「1.X」から「2.0」への更新は危険であり、慎重に検討する必要があることを知っています。

^{1：Rubyの世界では、これはgemと呼ばれると思う
2：JavaのNexusまたはPythonのPyPIと同等}

他の人が言ったように、優れた単体テストは問題を解決しません。各チームのテストスイートに合格しても、変更のマージ中に問題が発生します。

TDDについても同じです。これをどのように解決できるかわかりません。

ソリューションは技術的ではありません。「コア」境界を明確に定義し、「dev」または「アーキテクト」の誰かに「ウォッチドッグ」ロールを割り当てる必要があります。コアへの変更はすべて、このウォッチドッグを通過する必要があります。彼は、すべてのチームからのすべての出力が、過度の付随的損害なしにマージされることを確認する責任があります。

より長期的な修正として、チーム間でより適切でタイムリーなコミュニケーションも必要です。たとえば、コア機能Yを利用する各チームは、機能の計画テストケースの構築に関与する必要があります。この計画自体は、2つのチーム間の機能Yに固有のさまざまなユースケースを強調しています。機能がどのように機能するかが明らかになり、テストケースが実装され、合意されると、実装スキームに追加の変更が必要になります。機能をリリースしようとしているチームではなく、機能をリリースするチームがテストケースを実行するために必要です。衝突が発生するはずのタスクがある場合は、どちらかのチームから新しいテストケースを追加します。チームメンバーが、テストされていない機能の新しい側面について考えた場合、独自のサンドボックスに合格したことを確認したテストケースを自由に追加する必要があります。この方法では、発生する唯一の衝突はインテントレベルになり、リファクタリングされた機能が野生にリリースされる前に特定する必要があります。

すべてのシステムには効果的なテストスイート（特に自動化を意味します）が必要ですが、これらのテストが効果的に使用されると、これらの競合は現在よりも早くキャッ​​チされますが、根本的な問題には対処しません。

この質問は、少なくとも2つの根本的な問題を明らかにします。個々の顧客の要件を満たすために「コア」を変更する方法と、チームが変更を行う意思を伝えて調整することの失敗です。これらはどちらも根本原因ではないため、修正する前にこれがなぜ行われているのかを理解する必要があります。

最初に決定すべきことの1つは、開発者とマネージャーの両方がここに問題があることを認識しているかどうかです。少なくとも一部の人がそうするなら、あなたは彼らがそれについて何もできないと思うか、そうしないことを選ぶ理由を見つける必要があります。そうでない人のために、あなたは彼らの現在の行動が将来の問題をどのように作り出すかを予測する能力を高めようとするかもしれません。物事がどのようにうまくいかないかを認識している従業員がいるまで、問題を解決することはできません（少なくとも短期的にはおそらくそうではありません）。

少なくとも最初は問題を抽象的な用語で分析するのは難しいかもしれないので、問題を引き起こした特定のインシデントに焦点を合わせ、それがどのように起こったかを判断しようとします。関係者は防御的である可能性が高いため、実際に何が起こっているのかを知るためには、利己的で事後的な正当化に注意する必要があります。

可能性が低いため、言及することをためらう可能性が1つあります。顧客の要件が非常に異なるため、共有コアコードを正当化するための共通性が不十分です。その場合、実際には複数の個別の製品があり、それらを管理し、それらの間に人為的な結合を作成する必要はありません。

私たちは皆、ユニットテストが進むべき道であることを知っています。しかし、これらをコアに現実的にレトロフィットすることは難しいことも知っています。

機能を拡張するときに役立つと思われる特定の手法は、既存の機能が変更されていないことを一時的かつローカルに検証することです。これは次のように実行できます。

元の擬似コード：

def someFunction
   do original stuff
   return result
end

一時的なインプレーステストコード：

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

存在するシステムレベルのテストを介してこのバージョンを実行します。すべてが正常であれば、破損していないことがわかっているので、古いコードを削除することができます。古い結果と新しい結果の一致を確認するとき、違いを分析するコードを追加して、バグ修正などの意図した変更により異なるはずのケースをキャプチャすることもできます。

「ほとんどの場合、変更はチーム間で発表されないため、ほとんどの場合、バグは予想外の影響を受け

ます」適切なコミュニケーションがあることを確認することについて（他の全員がすでに指摘していることに加えて、厳密なテストを行う必要があるということについて）人々は、彼らが書いているインターフェースが次のリリースで変更されることを知っており、それらの変更はどうなるのか？
また、開発中にできるだけ早くダミーのインターフェース（空の実装）にアクセスできるようにして、独自のコードの作成を開始できるようにします。

これらすべてがなければ、最終段階でシステムの各部の間に強打から何かが出ていることを指摘する以外は、単体テストはあまり効果がありません。あなたはそれを知りたいが、それを早く、非常に早く知り、チームがお互いに話し合い、努力を調整し、実際に他のチームが行っている仕事に頻繁にアクセスできるようにする必要がある数週間または数か月後、配達の1〜2日前にコミットします）。
あなたのバグはコードにはなく、間違いなくあなたが書いているインターフェースをいじっていることを知らなかった他のチームのコードにはありません。バグは開発プロセスにあり、人々間のコミュニケーションとコラボレーションの欠如です。別の部屋に座っているからといって、他の人から自分を隔離する必要はありません。

主に、コミュニケーションの問題（おそらくチーム構築の問題ともリンクしている）があるため、あなたのケースの解決策は、開発技術ではなくコミュニケーションに焦点を当てるべきだと思います。

顧客プロジェクトの開始時にコアモジュールをフリーズまたはフォークすることはできないことは当然です（そうでない場合は、コアモジュールの更新を目的とする非顧客関連プロジェクトを会社のスケジュールに統合する必要があります）。

したがって、チーム間のコミュニケーションを改善しようとする問題が残っています。これには2つの方法で対処できます。

• 人間と。つまり、あなたの会社は、コードの品質と可用性に責任を持つコアモジュールアーキテクト（またはトップマネジメントに適した専門用語）として誰かを指定します。この人は核を転生します。したがって、彼女はすべてのチームで共有され、チーム間の適切な同期を確保します。さらに、彼女はコアモジュールにコミットされたコードのレビュー担当者としても機能し、その一貫性を維持する必要があります。
• ツールとワークフローで。コアに継続的インテグレーションを課すことにより、コアコード自体を通信媒体にします。これには、最初に（自動テストスイートを追加することにより）ある程度の労力が必要になりますが、その後、夜間のCIレポートはコアモジュールの全体的なステータス更新になります。

コミュニケーションプロセスとしてのCIの詳細については、こちらをご覧ください。

最後に、企業レベルでのチームワークの不足という問題があります。私はチームビルディングイベントの大ファンではありませんが、これはそれらが役立つケースのようです。開発者全体の会議を定期的に開催していますか？他のチームの人々をプロジェクトの回顧展に招待できますか？それとも、金曜日の夕方のビールが時々あるでしょうか？