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

「レガシーソフトウェア改善ガイド」の第1部で気になったところの抜粋。

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

1. レガシープロジェクトの難題を理解する

• 開発者はコードに注意を向けることが多いけれど、プロジェクトにはほかにも多くの側面がある。
  たとえば
  • ビルドツールやスクリプト
  • 他のシステムへの依存性
  • ソフトウェアの実行基盤となるインフラストラクチャ
  • プロジェクトのドキュメンテーション
  • コミュニケーションの手段
• コードそのものは重要だが、上記のすべての要素はどれもプロジェクトの品質や保守のしやすさに影響を与える。
• レガシープロジェクトの性質
  • 古い
  • 大きい
  • 引き継がれている
  • ドキュメンテーションが不十分
    • 開発者がドキュメントを書くことより嫌がるのが、ドキュメントを更新し続けることだ
• Linuxカーネルは、1991年から開発されており古い、しかも大きい。ところが非常に高い品質で保守管理されている。
  • 以下のAndrew Mortonの言葉は、Linux開発コミュニティがコードレビューをどれほど重視しているかを示す
    • コードレビューはバグを見つけ出す。コードの品質を高める。とんでもなく悪いものが製品に入り込むのを防ぐこともある。つまりコアカーネルのroot holeみたいなものだが、そういうのをレビュー時に突き止めことは、ずいぶんある。
      また、それは新しいコードを理解している人を増やす。レビュアーも、レビューを詳しく読む人もそのコードをサポートしやすくなる。
      それに、厳しくレビューされているという見込みがあるおかげで、貢献する人が注意を怠らないのだと思う。
      そのせいで、なおさら慎重に作業しているのだ。
• 開発環境のセットアップを実行しなければならない人は、あなただけではない。
  あなたのチームの開発者は、いまも、そして将来もそれを実行しなければならず、それに浪費されるコストが加算される。
• ソフトウェアの品質は、コードを見る人の数が多いほどよくなる。
  そのためには、組織の開発者なら誰でもそのプロジェクトに可能な限り容易に貢献できるような環境を作る努力をすべきだ。
• レガシーカルチャー
  • 変化が怖い
    • リスクを嫌悪するあまりソフトウェアの進化を許さないと競合他社に遅れを取る非常に大きなリスクにさらされることが多い。
  • 知識の孤立
    • 残念ながら多くのチームで知識の受け渡しが発生しない。
      あなたが積極的に働いて、コミュニケーションと情報共有の環境を促進しない限り、それぞれの開発者は情報をサイロのように貯蔵して孤立する。

2. スタート地点を見つける

• レガシーコードの場合、普通は既存の振る舞いを保存することが最も重要なゴールである。
  仕様化テストを書くことによってコードの振る舞いに関する理解がしっかりと固まる。
  将来そのコードに変更を加えるときには、意図しないリグレッションから自分自身を守るための知識があるので、安心して自由に行うことができる。
• 以下２つの理由によりソフトウェアに関するデータを集める必要がある
  • ソフトウェアの品質を数値化し、その数値が時間の経過にしたがってどのように変化したかを示すため
  • リファクタリングの次のターゲットを選択する基準とするため。
• 「開発プロセスを含むソフトウェア全体」を改善する計画を立てる上で以下のようなタスクの計測も有益である
  • 開発環境をセットアップするのにかかった時間
  • プロジェクトのリリースまたはデプロイにかかった時間
  • バグ修正の平均時間
• もし特定のクラスが開発者によって、とても頻繁に編集されているのなら、それはリファクタリングの理想的なターゲットの一つだ。
• 一般に役立つかどうか疑わしいときは、とにかく計測してみるのがよい。どの計測値が、その特定のニーズに最適なのか、だんだんと判明するだろう。使い物にならないと分かった計測値は捨ててしまってかまわない。

---

関連エントリ