freks blog

レガシーソフトウェア改善ガイドを読みました
自分用のメモ、覚えておきたいところや知らなかったところのみを書き出してます

レガシーコード

• ドキュメントがない
• テストがない
• 開発環境を作るのが大変

変えるのには恐れとフラストレーションがでてしまう

• 調査し理解すれば恐れが減る
• 複数人で対応する
• 外側から仕様のテストを書く

　- 動作をテストで保証すれば変えやすい

どこから対応すべきか

• データを取る

　- エラー回数とかよく触ってるファイルとか 　- 静的解析ツール走らす

false positive バグじゃないのにバグ扱いされる

リファクタかリライトか

• リライトしたくなるが思った以上に大変なことが多い
• リライトするたしかな目安は

　- リファクタに失敗したとき 　- 違う言語やフレームワークに乗り換える

リファクタの仕方

• リファクタ時に機能変更はしない
• IDEに頼る
• 使われてないコードを消す
• コメントアウトされたコードを消す
• 具体的なリファクタリング例がいくつか載っている
  • さらにリファクタリング本を読むのが良さそう

リアーキテクティング

• メソッドやクラスよりも高いレベルで行うリファクタリング
• モノリスなものを分割する

　- Webだとサーバー、クライアントサイドで分けるのがまず第一歩 　- サービス指向アーキテクチャ(SOA) - アプリケーションを多数のサービスに分ける - マイクロサービス - サービスの独立性が強化されたSOA

ビッグリライト

• 他の選択肢をすべて試した後に検討する
• 目標をさだめる
  • 経営陣が納得しない場合は見返りのあるリライトにする
    • 実現不可だった機能が作れるようになる、など
    • やらないほうが開発側的にはおすすめ
• 文書化しておく
  • 追加する新機能
  • 不要な機能はなかったか
  • リリースタイミング
    • 段階的にするか、何を出すか
  • リライト時に迷ったら過去の情報をさぐる
  • データベースをそのままつかうか、新しいものを作ってデータを同期させるか

開発環境を自動化する

• Vagrant + Ansibleの例

test/staging/production環境の自動化

• Ansible, Jenkinsの例

ビルドデプロイは手順を明確化しておく

レガシーコードを書かない

• コードがすべてでなく、コードはソフトウェアの一部
• いいドキュメント
• いいコミュニケーション
  • コードレビュー
    • ペアコードレビューもあり
  • ペアプロ
  • テックトーク
  • プレゼンテーション
  • ハッカソン
• 小さいのが美しい
  • 使い捨て、公開できる小ささ

感想

Javaのコードはだいぶ流し読みしましたが、ためになりました
デザインパターン頭に入ってないので、入れておきたい