読者です 読者をやめる 読者になる 読者になる

覚えたら書く

IT関係のデベロッパとして日々覚えたことを書き残したいです。 twitter: @yyoshikaw

「レガシーソフトウェア改善ガイド」 第3部

技術書・その他書籍

「レガシーソフトウェア改善ガイド」の第3部 リファクタリングの先へ - プロジェクトのワークフローと基盤を改善する で気になったところの抜粋。

レガシーソフトウェア改善ガイド (Object Oriented Selection)

レガシーソフトウェア改善ガイド (Object Oriented Selection)


7. 開発環境を自動化する

  • レガシーコードベースの仕事をするために開発環境をセットアップする際には、謎解きを強制される。
    どうしてこのような不愉快な経験をしなければならないのかは以下の理由による
    • 粗末なドキュメンテーション
      • 人が探し出せないなら、ドキュメントを書く意味がない。
      • ドキュメントの置き場がソースコードに近ければ近いほど、開発者は見つけやすい。
      • ドキュメントを書きやすく、読みやすく、更新しやすくする秘訣は、何らかの構造を与えて長くならないようにすること。
    • 自動化の欠如
    • 外部リソースへの依存
      • 理想的には、開発者自身が自分のローカルマシンにすべての依存関係をインストールして実行できるようにすべきである
  • READMEファイルをソースコード用リポジトリのルートにフォルダに置くのが、最も効果的なドキュメンテーションだ


8. テスト、ステージング、製品環境の自動化

  • インフラストラクチャ自動化のメリット
    • 環境のばらつきがなくなる
      • 手動での更新や編集を行っていると、さまざまな環境が絶望的なまでに同期を失っていく
    • ソフトウェアの更新が容易になる
    • 新しい環境を素早く作成できる
    • 構成の変更を追跡できる
  • 不変の基盤(immutable infrasutrcture)
    • もしマシンの構成に変更を行いたければ、そのマシンは捨てて新しいものを作る。
    • アプリケーションをデプロイしたいときは、まったく新しいマシンを作ってプロビジョニングし、それからアプリケーションをデプロイする。
      次のデプロイの際も同じプロセスを繰り返す。
    • インフラストラクチャについてのこの考え方には一種の「管理された故障」(controlled failure)としてデプロイを扱うことができる、というメリットがある。
      言い換えると、あなたが行うデプロイのプロセスは、マシンが突然故障した時のプロセスとまったく同じになる。
      もちろん、どちらの状況でも完全に自動化される。


9. レガシーソフトウェアの開発/ビルド/デプロイを刷新する

  • ドキュメンテーションの問題点は、必ず更新されるという保証がないことだ。
  • レガシーソフトウェアのビルドツールを刷新して、もっと新しいソフトウェアのそれと一致させる。これによって、プロジェクトに貢献したい開発者が参入するときの障壁が低くなる。
  • ローカルな開発からリリース/製品デプロイにいたるワークフローのあらゆるステップで自動化を進める。
    そうすれば、そのソフトウェアで開発した経験が少ない人でも、これらのタスクを実行できるようになり、ヒューマンエラーのリスクも軽減される。
  • 製品として実行されるWebアプリケーションは、どれもヘルスチェックエンドポイントを1つ持つべきである。単純にOKを返すだけのエンドポイントでよい。
    このエンドポイントを使って、監視ツールはその物理マシンが動作していること、正しいポートが開いていること、Webサーバが正常に実行されていることなどをチェックできる。


10. レガシーコードを書くのはやめよう!

  • ソフトウェアプロジェクトの成功に貢献するファクターは数多く存在し、品質の高いソースコードはその一つにすぎない
  • 開発者がどれほど情報を共有しているかといえば、ほとんどの開発者が大の苦手としている。
    ドキュメントを書いたり保守したりするのは、彼らにとって楽しい仕事ではなく、催促されない限り情報をシェアすることは少ない。
  • ドキュメンテーション
    • 価値あるドキュメントにするには以下が必須
      • 有益である
      • 書きやすい
      • 見つけやすい
      • 読みやすい
      • 信頼できる
    • ドキュメントは定期的にレビューして、古くなったものは削除すべき。もし開発者によってメンテナンスされていなければ、おそらく有益なドキュメントではない。
      そういう重荷は、努力して引き上げるよりも削除したほうがましである。適者が生き残るのである。
  • コミュニケーションを促すためのアイデア
    • コードレビュー
    • ペアプログラミング
    • テックトーク
    • 他のチームへのプレゼンテーション
    • ハッカソン
  • 定期的なコードレビュー
    • コードベース全体を定期的にレビューするようスケジュールを組むのが有益だ。
  • すべてを自動化せよ
    • あなたの仕事が楽になる
    • 仕事を引き継ぐ人が楽になる
  • 小さいのが美しい
    • ソフトウェアを設計するときは、モジュール化(小さくて結合の少ないコンポーネントを集めて大きなソフトウェアを構築すること)を最優先すべきだ。
      コンポーネントレベルのコードが使い捨てできるおかげで、ソフトウェア全体が堅牢となり、したがって長寿となる。



関連エントリ