レガシーソフトウェア改善ガイドの読書メモ。

レガシーの定義

保守または拡張が困難な既存のプロジェクトなら、なんでも「レガシー」と呼ぶ

レガシープロジェクトに対する変更と、それらのメリットとリスク

変更点	メリット	リスク	必要な行動
古い機能の除去	・開発が容易になる ・性能が向上する	・まだその機能を使っているユーザーがいるかも	・アクセスログをチェックする ・ユーザーに問い合わせる
リファクタリング	・開発が容易になる	・過失によるリグレッション	・コードレビュー ・テスト
ライブラリのアップデート	・バグフィックス ・性能が向上する	・ライブラリの振る舞いが変化することによるリグレッション	・変更履歴を読む ・ライブラリのコードをレビューする ・主な機能を手作業でテストする

どのファイルが最も頻繁に編集されるかと知っておく

$ git log --since="90 days ago" --pretty=format:"" --name-only | \
 grep "[^\+s]" | \
 sort | uniq -c | \
 sort -nr | head -10

リファクタリングの選択肢

経験則として、選択肢は次の順に考慮すべきだ

①置き換え(サードパーティー制ソリューションの購入)
②リファクタリング
③リライト

Webアプリケーションのアーキテクチャを比較

アーキテクチャ	技術的な利点	技術的な難関	組織面の利点	組織面の難関
モノリス的	・応答が早い ・開発が単純 ・コードの重複が少ない	・スケーリングに難あり ・コードベースが大きくて複雑 ・予期せぬ相互作用の危険	・単一機能に関する情報伝達のオーバーヘッドが低い	・失敗の恐れ ・複数機能に関する情報伝達のオーバーヘッド
フロントエンド+バックエンド	・FEとBEを個別にスケーリングできる ・プレゼンテーションとビジネスロジックの切り分け ・BEを再利用し、より多くのFEを構築できる	・ネットワーク呼び出しの煩雑さ	・分業化 ・FEのリリースをBEより頻繁に行える ・SOAに進む第一歩	・情報伝達のオーバーヘッド ・情報のサイロ化 ・FEとBEの開発が互いにブロックする
SOA	・粒度の細かいスケーリング ・アイソレーション(隔離) ・カプセル化	・運用のオーバーヘッド ・レイテシン ・サービス発見 ・トレース/デバッグ ・ホットスポット ・APIのドキュメントとクライアント ・統合テスト ・データの断片化	・自律性	・自律性の範囲に関するジレンマ ・仕事が重複するリスク
マイクロサービス	・SOAと同様だが、さらに進化	・SOAと同様だが、さらに進化 ・暗黙的な連結のリスク	・コンテクスト境界による、さらなる自律性	・DevOpsが想定される ・プラットフォームチームが必要 ・考え方に大幅なシフトが要求される