improve-architecture

improve-architecture

後で書き直すことになる前に、少しずつシステムの構造に手を入れます。このスキルは診断と提案を行いますが、それ自体で書き直すことはありません。

方法

1. まず全体像を把握します。 評価する前に、現状の構造を把握します。エントリーポイント、モジュール、データフロー、呼び出し関係を確認します。1画面で全体を把握できる module-map を再利用し、意見を述べるのはその後にします。
2. 負荷のかかっている箇所を見つけます。 スタイル上の細かな問題ではなく、根幹に関わる問題を探します。
   • 何も安全に変更できず、あらゆるものがインポートする巨大なモジュール。
   • 境界の漏れ。モジュールが公開インターフェースではなく、他のモジュールの内部に手を伸ばしている状態。
   • ずれが生じる重複ロジック。同じルールが3通りに実装されている状態。
   • 不適切な境界。コードが変化しない箇所で分割され、変化する箇所で一体化している状態。
   • 循環依存。
   • ドメインに合わない構造（domain-modeling を参照してください。コード上の境界は、言語上の境界に対応させる必要があります）。
3. 最小の変更を提案します。 各問題について、負荷を軽減する最小限の変更を提案します。境界の抽出、重複の解消、依存関係の逆転、境界の移動などです。大きな変更を一度に行うより、安全な手順を重ねることを優先します。
4. 効果の大きさで順位付けします。 軽減できる負荷と作業量を比較して、変更を順番に並べます。今すぐ安全に行えるものと、先にテストの備えが必要なもの（tdd と組み合わせます）を明示します。
5. 重要な判断を記録します。 将来の読者が疑問に思うような構造変更については、docs/decisions/NNNN-slug.md に意思決定記録を作成します。背景、選択した内容、却下した代替案、その理由を記載します。

ガードレール

• 診断は行いますが、書き直しはしません。成果物は、コードを変更する前にユーザーの承認を得る計画です。
• 好みを理由にコードを変えません。変更には、明確な負荷を軽減する目的が必要です。「よりすっきりする」は理由になりません。
• 時期尚早な抽象化より、似た3行のコードを優先します。重複によって実際にずれが生じていない限り、重複を間接化に置き換えません。
• 動作は変えません。構造上の変更はリファクタリングです。テストがすべて成功した状態で反映します。

出力

優先順位を付けたリストを作成します。各項目には、問題、最小の変更、リスク、先にテストの備えが必要かどうかを記載します。大きな変更については、意思決定記録も作成します。ユーザーが実施内容を選ぶまでは、コードを変更しません。