『レガシーコードからの脱却』を読んだ
お仕事でレガシー改善っぽいことばかりやっていたら、他部署のエンジニアから「レガシーの人」と呼ばれた。老害の化身みたいな印象を刷り込まれつつある。そんなわけで、レガシーにまつわる本を読んだ。
インターネットをみているかぎり評判が良さそうで、ネクストバイブル的な扱いを受けていた。読んでいて思ったことなどを雑に書き留める。
感想たち
全体的にとても読みやすく、整理されている。訳も自然。キーワードを挙げるなら、アジャイル、TDDあたり。タイトルからは少しずれる印象かもしれないが、レガシー関係なく良いコードを書く方法にかなりページを割いている。その理由は、最終章の以下文で端的に説明されている。
良いものがどんなものか知らなければ、レガシーコードをリファクタリングしてもより良いものにしようがないのだ。(p.241)
「レガシー改善やるぞ」とそれ自体が目的になってしまいがちで、それもふまえてより大局的に「良いコード」を志向している点に、本書の価値を感じる。書かれていること自体も理論と実践のバランスよく、ソフトウェア開発者が日々意識しやすい言葉を使っていて、ジュニアからシニア、マネージャまで、ソフトウェア開発者と呼ばれる人々に広く示唆を与える内容となっている。
失敗のコスト
本書の前半は、広くソフトウェア業界が抱える問題意識を示している。
主にアメリカのソフトウェア業界をターゲットとして、権威ある調査機関が行った調査について、定量的に紹介されている。CHAOSレポートはその中の代表的な一つで、いろんなところで引用されている。
1994年時点でのプロジェクト成功率は16%であり、それが2004年には29%になったこと、及びその理由としてアジャイル開発手法の普及を挙げている。この数字は、ソフトウェア開発者以外からみると、信じられないくらい低いと思う。というか、ソフトウェア開発者からみても低い。「成功」「問題あり」「失敗」の3状態の定義として、例えば「予算がオーバーした」は「問題あり」に分類される。そう聞くと、ソフトウェア開発者としては納得できる。
この感覚の差に内在するのはソフトウェアの複雑性だと思う。NISTの調査から、以下のコメントが紹介されている。
ソフトウェア開発者はすでにほぼ80%の開発コストを障害の特定と修正のために使っている。
そして、ソフトウェア障害がアメリカだけで年間600億ドルもの損失になっていることを紹介している。600億ドルといえば、現時点のレートで6.5兆円程度。「ポケモン」の市場規模が約6兆円らしいので、それを超える勢い。よくわからん。
技術的卓越性
自分はアジャイルを全然知らないのだが、本書はアジャイルの根底にある「余計なものはないほうがいい」という思想のもと、レガシーコードを生み出さないことに繋がることを説明している。たぶん。マネジメントプラクティスが先行しすぎていることを指摘し、技術プラクティスの重要性を強調している。たぶん、より開発生産性の高い状態を目指したらアジャイルチックなスタイルになっているのが理想なのだと思う。アジャイルマニフェストの起案者は、「今後は技術的卓越性やで」といってるらしい。
技術的卓越性とはなにか、という点については、本書では十分には説明されていない。アジャイルの聖典であるPrinciples behind the Agile Manifestoにある以下。
Continuous attention to technical excellence and good design enhances agility.
「技術研鑽を常に意識せよ」ということだと思うが、アジャイルにおいてそれが明文化されていることに意味がありそう。各自の解釈で。
変更しやすく
仮想世界は物理世界とは異なり、物理法則がない。それもあってか、ソフトウェア開発において「第一原理」となるものはまだない。オブジェクト指向や単一責務の原則のようないわゆる設計原則がそれに近しい位置にはいるが、それが不要なソフトウェア開発もまた存在する。そのため、「良いコード」の定義は様々あるとした上で、「変更のしやすさ」を大きな要素として挙げている。変更のしやすさはソフトウェアの内部品質であり、内部品質は結果ではなく原因であり、良いソフトウェアが備えているものである、としている。
高凝集・疎結合にしたり、ポリモーフィズムを駆使したり、オブジェクト指向の原則に従った開発を行うことや、テストでふるまいを書くことが「良い」とされている。その「良い」と感じる根源は、変更のしやすさであり、より根源的には不確実性、わからなさに対する戦略だと思う。コードは読み手のために書くという意識は大切だし、その人の不安をなるべく減らしたい。ホスタビリティ。おもてなし。
品質の定義
品質を高めるには？みたいな文脈で、「まず品質を定義しろ」みたいなことが書いてあった。気がする。当然のことながらケースバイケースであり、本書でも品質を定義するやり方については書かれていないし、従来の品質管理の手法はソフトウェアに適用できない的なことも書いてある。
内部品質に関しては、ひとつはコードの複雑性、例えば循環複雑度のようなものは計測ツールが色々あるので、なにも決めていない場合はそのあたりから初めて、徐々にチューニングしていけばいいかもしれない。ある組織においてソフトウェア開発者を評価するとき、外部品質（機能要件、非機能要件含む）が目立つが、内部品質の評価はあまり議論されていない気がする。外部品質の目的がユーザ体験なら、内部品質の目的は開発者体験、世にいうDXというやつなのかもしれん。であれば、その観点で評価をするべきだし、まさに技術的卓越性が評価観点になること、端的には「技術力」で評価されることは一定納得がいく。
リファクタリングのモチベーション
もちろん機能拡張や改良のコスト削減に寄与することが前提。それに加えて、一開発者の視点でもモチベーションになりうる。
コードのリファクタリングは、コードを書くときにしてはいけないこと、代わりにすべきことを学ぶ上で最速の方法のひとつなのだ。(p.227)
ソフトウェア開発において、大なり小なりリファクタリングのスキルは求められる。自分の体感とも一致する。一発目に書いたコードをそのままプッシュしてプルリクエストを作成することはほぼない。自分の場合、まずテストコードを書いてからテストをとおすコードを書く。その時点ではテストをとおすことを考えていて、コードの品質については考えていないので、ひどいコードになっている。それをある程度リファクタリングする。
そういえば、かの名著『リファクタリング』の第2版が出ているが、まだ読んでいない。と思ったらもうすぐ邦訳が出そうな雰囲気なので、折に触れて読んでみる。
まとめ
原題の『Beyond Legacy Code』のほうが好きで、日本語の「脱却」とは少し違うニュアンスを感じる。「うぅ…抜け出したい…」よりも「我々の戦いはまだ始まったばかり！」みたいな。始まっていきましょう。
