「レガシーコードからの脱却」を読んだのでまとめ①（序文〜レガシーコード危機）

最初のレガシーコード危機（P35まで）については、開発者よりもディレクターやクライアント（予算管理者）に読んで欲しい内容だった。

これで事前知識の共有ができれば、保守性を高めるために時間をかけることに躊躇がなくなるし、クライアントとのコミュニケーションで齟齬が生じても、この本を引用すれば、分かってくれる範囲が大きくなりそう（よっぽどバカじゃなければ）。

以下ソフトウェア業界のプロジェクト分析データで面白かった数字。

80%の開発コストが「障害の特定と修正」にかかっている。価値を作るために使える予算は20%しかない（NIST=国立標準技術研究所のコメントより）

よく使われる機能は全体の20%に過ぎず、45%は一度たりとも使われていない（CHAOSレポートより）

序文： agileとagility

アジャイルソフトウェア開発宣言をまとめた17人のうちの一人であり、XPのパイオニアとして有名なWard Cunninghamが序文を書いている。

括弧付きのアジャイル開発という言葉はもはやエンジニアの共通語だけど、
agile=agility(機敏)という元の意味を持ち出して、アジャイル組織を「脅威や好機に対してその場に応じた方法ですぐに適応する」ものだと言っている。

この本は「アジャイルソフトウェア開発宣言」の2つの弱点を補うことができるようだ。その弱点は「具体的なアドバイスが無いこと」と「本番稼働に適用されない」ことらしい。

そして著者は、これを引き継ぐように、「はじめに」のセクションでこう書いている。

私は本書で9つのプラクティスを提案する。それらのプラクティスは、アジャイル開発手法のXP、スクラム、リーンから来た物だ。プラクティスをただ適用するのではなく理解した上で適用できれば、書いたコードが将来レガシーコードになるのを防げるだろう。

続く目次を見ると、この本はまず「A. レガシーコード危機」について説明し、その後に前書きに記された通り「B. 9つのプラクティス」を用意している。

A. レガシーコード危機

ソフトウェアは生き物

ソフトウェアにもライフサイクルがある。生まれ、パッチを当てられ、使われなくなり、死ぬ。優秀な医師（エンジニア）によって延命治療はできるが、いつかは必ず死ぬ。

面白い表現だったのが、死んだソフトウェアに触れることによって生まれた「ソフトウェア考古学」。昔に生まれ、ドキュメントもなく変数名も適当なソフトウェアを解読することは、まるで考古学であるという話だった。

テストがない＝レガシーコード

コードを実行し、意図した通りに使われていることを検証する優れた自動ユニットテストに高い価値をおいている。これは私も同じである。

ウォーターフォール

ウォーターフォール型マネジメントは元々製造業や建設業から来ており、橋の建設や部品の製造では理にかなっているが、ソフトウェアではうまく行かない。これがソフトウェア開発で機能しないだろうと言うことは、提唱者のウィンストンロイスが最初から言及しているそうだ。

レシピと公式

レシピと公式の違いについて述べているのも面白かった。

例えばパスタを作る時に使うのは「レシピ」だ。トマトやコンソメの分量を変えても問題ないし、いれる順番を変えてもまずくはならない。

一方、パンを作る時のイーストと小麦粉、スキムミルクの分量は「公式」であり、少しでも変えるとパンが膨らまない（経験済み）。

さらに、エンジニアの業務は「レシピ」に沿って料理するような物であり、公式が用意されている物ではない、と言っている。とても納得。

さらにそのあとの部分でも、科学や工学と異なり、ソフトウェア業界には完全な標準や慣行がない、という表現もしている。

CHAOSレポート

CHAOSレポートは、スタンディッシュグループ（アメリカの調査機関らしい）がソフトウェア業界におけるプロジェクトの成功比率などについてまとめたレポートである。

そもそも成功・失敗の客観的な基準を設けるのが難しく、このレポート自体の問題点についても言及しているが、それでもなお、大きな資金があるプロジェクトでさえも、失敗が多い業界であることを最後に断言している。

A. レガシーコード危機での英知

レガシーコード危機のなかでも触れられていた細かい英知をまとめる

・無駄なコメント（何をしているのかをまんま書く等）は不要

・メソッド名に全てを込める

・

今回のまとめ

最初のレガシーコードの危機に関する著述に関しては、エンジニアのみならず、予算管理者に読んで欲しい内容だった。それは、「将来的に80%を障害の調査・修正にかけたくなければ、最初に多少のリソースを割いて目に見えないSREを行うことが必要だ」と言うことが前提知識として共有できるからだ。

次回からは具体的なプラクティスに入りそうなので、さらに楽しみ。