レガシーソフトウェア改善ガイドの読書メモ。
レガシーの定義
保守または拡張が困難な既存のプロジェクトなら、なんでも「レガシー」と呼ぶ
レガシープロジェクトに対する変更と、それらのメリットとリスク
| 変更点 | メリット | リスク | 必要な行動 |
|---|---|---|---|
| 古い機能の除去 | ・開発が容易になる ・性能が向上する |
・まだその機能を使っているユーザーがいるかも | ・アクセスログをチェックする ・ユーザーに問い合わせる |
| リファクタリング | ・開発が容易になる | ・過失によるリグレッション | ・コードレビュー ・テスト |
| ライブラリのアップデート | ・バグフィックス ・性能が向上する |
・ライブラリの振る舞いが変化することによるリグレッション | ・変更履歴を読む ・ライブラリのコードをレビューする ・主な機能を手作業でテストする |
どのファイルが最も頻繁に編集されるかと知っておく
$ 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が想定される ・プラットフォームチームが必要 ・考え方に大幅なシフトが要求される |
Comments