プログラマが知るべき97のこと
本記事は、株式会社オライリー・ジャパンより出版された『プログラマが知るべき97のこと』の中からひとつのエッセイを取り上げ、そのエッセイをクリエイティブ・コモンズ表示3.0の条件下で転載したものです。
本書の各々のエッセイは、オープンソースモデルに従い、ほぼ無制限で利用が可能です。クリエイティブ・コモンズ表示3.0の条件下で、自由に使用することができるのです。つまり、どのエッセイも、著者の名前を明記すれば、自由に転載、改変が可能であるということです。
『プログラマが知るべき97のこと』はじめに（p.XII）
なお、原書（英文）のエッセイは、下記のWebサイトで公開されています。
Contributions Appearing in the Book – Programmer 97-things
24 変更を恐れない
マイク・ルイス (Mike Lewis)
コード品質の悪いプロジェクトは「ジェンガ」をやっているようなもの
ソフトウェア業界で働いたことのある人なら、ひどいプロジェクトに関わった経験が一度はあるはずです。たとえば、どう見てもコードベースの品質が低すぎるようなプロジェクトです。
システムの構造自体に問題があり、どこかに変更を加えると必ず、関連のないはずの別の箇所が壊れてしまう。そんなプロジェクトにおいて新たにモジュールを追加する必要が生じた時、担当者が考えるのは、できる限りどこにも変更を加えないことです。
リリースの時は、毎回固唾を飲む思いをします。それはまさにソフトウェアで「ジェンガ」をやっているようなものです。直方体のパーツを積んで作った高い塔が倒れないよう、慎重にそっと手を加えていくのですが、いつかは必ず崩れる運命なのです。
何かを改善するのに痛みはつきもの
変更を加える度になぜそう神経質になるかというと、それはシステムがいわば「病気にかかっている」からです。医者に診てもらう必要があります。そうしなければ、容態は悪くなる一方でしょう。
システムのどこが悪いのか、自分ではよくわかっているのだけれど、怖くて触れないのかもしれません。しかし、何かを改善するのに痛みはつきものです。外科手術をするには、必ずどこかを切る必要がありますが、痛みはあくまで一時的なことであり、その傷は癒えるのです。そして、患者の容態は手術の前より良くなるはずです。
「病気の」システムを治すことはプロジェクトメンバーの経験に
プログラムのコードでも同じことが言えます。改良を加える間、一時的にどこかが壊れていても誰か気にする人がいるでしょうか？そもそも、そういうむやみに変更を怖がるような態度のせいでプロジェクトがひどい状況に陥っている可能性が高いのではないでしょうか。
リファクタリングをすれば時間と労力はかかりますが、プロジェクトが進む中でその投資は十分回収できるでしょうし、何倍もの利益となって返ってくるでしょう。さらに良いことは、「病気の」システムを治すことがプロジェクトのメンバーにとって経験になるということです。
その経験によって、システムは本来どうあるべきかを全員が理解することになり、システムについてのエキスパートになるのです。システムがひどいとただ怒るのではなく、改良できる知識を身に付けるのです。
作っている人間自身がシステムを嫌っているようでは、そんなものを使わされる側はたまらないでしょう。
改良はゆっくり少しずつ加えていき、改良の都度テストをする
システムの改良にあたってすべきこととしては、たとえば、内部インターフェースの再定義、モジュールの再構築、コピー＆ペーストしたコードのリファクタリングなどが挙げられます。また、依存関係を減らして設計をシンプルにすることなども重要です。
コードをシンプルにするため、機能の組み合わせ方が不適切な時に良く生じるコーナーケース（めったに発生しない厄介なケース）を減らすというのも有効でしょう。
改良はゆっくり少しずつ加えていき、改良の都度テストをします。一度に大幅な変更を加えるのは危険です。それが元で大変な問題が起きてしまい、結局、せっかく途中まで進めた改良を全部やめてしまおうということになりやすいからです。
システムの「健康」への留意は常に怠らないように
大切なのは、外科医が身体を切ることを恐れずに病気を治すように、コードに変更を加えることを恐れず、積極的にシステムを改良していく姿勢です。そういう姿勢は人から人へと伝播しやすいものです。
同じような人が増えれば、延び延びになっていた改良プロジェクトが実施に移される、ということもあるかもしれません。チームのメンバーの意識が高まれば、日々、気づいたことをリストアップして皆と共有する、ということもできるでしょう。これもシステムの質向上につながります。
改良プロジェクトを実施するには、会社の上層部を説得することが必要になるかもしれません。「改良してもすぐに目に見える利益が生まれるわけではないが、将来のコスト削減につながり、リリースに要する時間の短縮もできる」ということを説明して納得してもらうのです。
こうして、システムの「健康」への留意は常に怠らないようにしましょう。
コメント