メンテナビリティの高いソースコードを目指して : 小野和俊のブログ

ソフトウェアを中長期にわたってメンテナンスしていく場合、メンテナンスしやすいコードと、メンテナンスしにくいコードとの間には、同じ機能を実現していたとしても、その価値には雲泥の差があります。

メンテナンスの容易さを示す言葉として、メンテナビリティ(Maintainability)という言葉がありますが、私自身、アプレッソでDataSpiderを11年間開発・メンテナンスしていく中で、「この人の書いたコードは本当にわかりやすいし無駄がない」とメンテナビリティの高いソースコードに感心させられることもあれば、「急いでいたとはいえ、このソースコードはリファクタリングしないと・・・」と、メンテナビリティの低いコードがソフトウェアに混入してしまったことを嘆くこともありました。

とりわけ、現在早稲田大学で研究助手をしている中野鐵兵さんのソースコードはメンテナビリティが極めて高く、10年経った今でも「とても良くできていて、自分もがんばろうと思った」と社内で高く評価されています。アプレッソを立ち上げた2000年当時、共に24歳だった私たちは、私がクライアント、中野さんがサーバーを担当し、ピッチャーとキャッチャーでバッテリーを組むように阿吽の呼吸で日々の開発を進めていたものでした。彼の書いたサーバーのコードは今でも輝きを失うことなく、1400社を超える企業のデータ連携基盤として今でも活用され続けていいます。

このエントリでは、一本のソフトウェアを11年間開発・メンテナンスしてきた経験から、ソフトウェアのメンテナビリティについて考察してみたいと思います。

5年後に自分が読んでわからないコードは捨てたほうが良い
ソースコードのメンテナビリティの最低限の基準として、「5年後に自分が読んですぐにメンテナンスできるかどうか」というのが一つの基準になると思います。

自分が今書いているコードを5年後に自分自身が見直した時、

・何でここでこんな処理してるんだろう？
・同じような処理をしている箇所が何箇所かあるけど、どういう意図で別々にしてるんだろう？

などとソースコードの理解に時間を要したり、最悪の場合、なぜそういうコードになっているのか最後までわからず、「触ると危ないコード」になってしまうようなら、例え機能的に要件を満たせていても、中長期のメンテナンスの観点から言えば、そのソースコードはコミットしない方がプロジェクトのためになります。

こうしたソースコードがひとたび本番環境で使われてしまうと、修正の際の互換動作保証や影響範囲の洗い出しに、下手をすると該当箇所をゼロから作り直すよりもずっと大きな手間がかかるからです。

望ましくないソースコードは転移する
「望ましくないソースコード」はがん細胞のように転移します。

というのも、読みやすいコードを書こうという意識の高いプログラマーほど、既存のコードとの一貫性を損なわないよう、人の書いたコードを参考にするからです。

例えば、何通りかの実装方法を検討し、このソフトウェアではこの設計方針で行きます、と方針が決まったとします。しかし、検討の課程で却下された方法で実装されているコードが一部残っていたとします。すると、一貫性を崩さないように、と、他のプログラマーがその部分を参照し、望ましくない実装方法をお手本として「設計方針に合致しないコード」を広げてしまうことがあります。当然、「残っている一部分」の大きさに比例してこの危険性は高まります。

加えて、ひとつのソフトウェアの中に類似した処理の実装方法が複数混在していることは、ソースコードを読む人に、その理由を考える時間を取らせます。

こうした「望ましくないコードの転移」を防ぐには、「方針が決まったり、規定の方針に問題が見つかった場合には、時間をかけてでも方針に沿わないコードはすべて修正する」ことが重要です。もし、新しい方式でソフトウェア全体を一貫させるコストがあまりにも大きい場合、それを理由にその方式の採用を見送る方が良い場合もあるでしょう。一貫していないソフトウェアには、割れ窓理論的に、「どうせ他の箇所も一貫してないし、まあいいや」という風潮が広がっていきやすいからです。

納期等の関係でどうしても時間がない場合や、一貫性を担保するためだけに時間を割くことに上司の理解が得られない場合もあるかもしれませんが、作り捨てではなく、中長期にそのソフトウェアをメンテナンスしていくなら、「望ましくないコード」を取り除き、ソフトウェアの一貫性を保ち続けることはメンテナビリティの観点から極めて重要です。

常に「自分の作品です」と胸を張れるソースコードを
「今書いてるコード、自分のコードだって胸を張って人に見せられる？」とプロジェクトメンバーに問いかけた時、「いや、それはちょっと」、「恥ずかしくて出せないです」等の答えが返ってきた場合、そのプロジェクトには2つのリスクがあります。

a. ソフトウェアに大きな問題が潜んでいるリスク
b. プロジェクトメンバーの成長機会が失われているリスク

ソフトウェアの世界では、「たった一行のミス」がシステムに致命的な問題をもたらすことがあります。

もちろん、バグを完全に防ぐことはできないのですが、プロジェクトメンバーが「人に見せられないコード」という意識で仕事をしている場合、そのメンバーの書いたコードには、クリティカルなバグが含まれている確率や、問題が起きた時の調査に他の箇所の何十倍も手間がかかる可能性が高いことは、多くのプログラマーが経験的に知っていることです。

また、「人に見せられないコード」を書き続けるということは、自らの成長の機会を逃すことでもあります。

私は高校時代に陸上競技をやっていたのですが、今でも覚えている先輩の言葉で、「例え部活動以外の遊んでいる時だったとしても、ふざけた走り方はするな。悪い走り方の癖がつく」という言葉があります。これは様々なことに同じことが言えると思います。

まあ適当でいいや、とりあえず動いてテストが通ればそれでいいだろう、という気持ちでソースコードを書いていると、緊張感を持って取り組まなければならない重要な場面でも、きれいなコードを書けずに思わぬ所でバグを仕込んでしまうことがあります。

何より、より美しいソースコードを書くための絶好の場である仕事の時間を、ダラダラと過ごすのはその行為自体が貴重な成長機会をドブに捨てるような行為です。

というわけで、人に胸を張って見せられるソースコードを書いて、プログラミングを楽しみましょう :)

■ 関連エントリ
・プログラマーにとっての読み書きそろばん
・プログラマー風林火山