貯まった問題との付き合い方――割れた窓の法則、エントロピーの法則に見る技術的負債が起こる理由：問題解決力を高めるコツはプログラミングの原則・思考にあり（終）（4/4 ページ）

[上田勲，著]

エントロピーの法則

　英語　　Law of entropy increase

　What　〜コードは自然と腐っていく

　エントロピーとは物理学の用語で、「無秩序な度合い」を表すものです。熱力学の法則によれば、全宇宙のエントロピーは増加していくことが証明されています。

　ソフトウェア開発は、ほとんどすべての物理法則を超越できますが、エントロピー増大の法則には強く縛られます。コードは、自然に任せると、限界を超えるまで無秩序さが増大します。いわば「腐ったコード」になっていくのです。

　Why　〜コードは無秩序へ向かう

　コードが無秩序へ向かうというのは、ソフトウェア開発においても、自然な傾向です。

　最初はよいスタートを切ったとしても、しばらくすると、コードが腐敗し始めます。生肉が古くなると腐るように、時間が経つにつれ、腐敗はひどくなっていきます。腫れ物がコード内にたまってしまい、どんどん保守しづらくなります。そのうち、ちょっとした変更にも、多大な労力が必要になり、再設計を余儀なくされます。

　しかも、こういった場合の再設計はうまく行きません。今のソフトウェアは常に変化し続けているので、新しい設計もそれに追従しなければならないからです。

　つまり、明確な目的意識を持って取り組んだとしても、実は「動く標的」を打ち落とそうとしているため、無理が生じるのです。

　How　〜コード腐敗の兆候をつかむ

　コードが腐敗し始める「兆候」がいくつかあります。これらを見過ごさないようにして、迅速に対処しましょう。

• 硬さ

　「硬さ」とは、変更の難しさのことです。
　たった1つの変更で、それと依存関係のあるモジュールを、連鎖的に変更しなければならないような場合、「硬い」設計のコードだと言えます。

　設計が「硬い」と、例えば、簡単そうな変更を頼まれ、変更箇所を軽く調べてから仕事量の見積もりを出したとしても、実際に作業を進めるに従い、予測していなかった連鎖的変更箇所に直面します。その結果、最初の見積もりよりもずっと多くの変更をすることになり、膨大なコードの中で次々と変更を追いかけることになります。

• 脆さ

　「脆さ」とは、たった1つの変更によって、他の多くの部分が壊れてしまう度合いのことです。脆いコードは、変更した部分とはまったく関連のない箇所まで、壊れてしまうことがあります。そこで新たに発生した問題を修正しようとすると、さらに問題を生み出してしまい、プログラマは自分で自分のシッポを追いかけるような状態に陥ってしまいます。

　大げさではなく、そういったモジュールは珍しくありません。脆いモジュールは、すぐに見つかります。例えば、いつも修復されているモジュール、いつまでも障害リストから消えないモジュール、プログラマが再設計の必要を感じているモジュール、修復すればするほどひどくなるモジュールなどです。

• 移植性のなさ

　「移植性のなさ」とは、ほかの環境への移植のしにくさのことです。

　どんな環境でも動作する部分を含んでいながら、環境依存の部分から、その部分を切り離すのが困難で、リスクを伴うような場合、移植性がないと言えます。

• 扱いにくさ

　「扱いにくさ」には、コードの扱いにくさと、開発環境の扱いにくさがあります。

　コードの扱いにくさとは、設計構造の柔軟性のなさのことです。扱いにくいコードは、設計構造を保持したまま、容易に変更できません。設計構造を保持するやり方よりも、裏技を使った方が簡単に変更ができます。間違ったことをするのは容易で、正しいことをするのが難しい状態です。

　一方、環境の扱いにくさは、開発環境が遅くて非効率な時に生じます。例えばコンパイルに非常に時間がかかる場合、設計構造を保持できなくなることがわかっていても、大きなコンパイルをしなくて済むような変更を採用したくなります。あるいは、たかだか2つ3つのファイルをコミットして確認するのに、数時間もかかるような場合、設計構造を保持できるかどうかなど考えず、できるだけ時間がかからないような方法で変更しようとしたくなります。

• 複雑さ

　「複雑さ」とは、「不必要な」要素の多さのことです。

　これは、プログラマが仕様の変更を先取りし、後で仕様が変更になった時に対処しやすい仕組みを、あらかじめコードに仕込んでおくことで発生します。こういった対処は、よいことのように思えます。将来の変更を見越して準備しておけば、コードの柔軟性を保ち、後になって悪夢のような変更に苦しまなくて済むはずです。

　しかし、残念ながら、まったくの逆効果に終わることがほとんどです。あまりにも多くの不測の事態に対処しようとして、一度も使わない構造がコード中に散乱してしまいます。これが、コードを複雑にし、わかりにくくします。

• 繰り返し

　「繰り返し」とは、同じようなコードが何度も繰り返し現れることです。

　コピー＆ペーストは、文書作成には便利な方法ですが、コード編集に使うと悲惨な結果を招きます。重複するコードがあると、ソフトウェアの変更はとても骨の折れる作業になります。そのような重複した部分から障害が見つかった場合、コード中にある同じような部分をすべて修正しなければなりません。

　しかも、同じようだとはいっても、それぞれがほんの少しずつ違っていることもあり、必ずしも同じ修正をすればいいわけではありません。

　このように、同じようなコードが、ほんの少しだけ違う形で、繰り返し現れるような場合、プログラマは抽象化を見逃しています。繰り返しの箇所をすべて見つけ、そういった部分を適切に抽象化することで、繰り返しを削除すれば、システムは理解しやすく、かつ、保守しやすいものになります。

• 不透明さ

　「不透明さ」とは、コードのわかりにくさのことです。

　コードは、わかりにくい表現で記述されてしまうことがあります。また、頻繁に改修を重ねられるようなコードは、歳月とともに、どんどんわかりにくいものになってしまいます。

　最初にコードを書いた時は、本人にとってはそのコードがとても明瞭に見えるものです。それまでずっとその開発に没頭し、その隅々まで熟知しているからです。しかし、しばらくして、忘れた頃に再び見てみると、いったいどうしたらこんなにひどいコードを書けたのだろう、と不思議に感じることもあります。

　こういった事態を避けるには、読み手の立場に立って考え、読み手が理解できるようにコードを書く必要があります。自分の書いたコードを、他の人に見てもらうことも有効です。

　発展1　〜アジャイルで腐敗を許さない

　アジャイル型のソフトウェア開発では、変化を喜んで受け入れます。

　初期設計には、ほとんど時間を割きません。歳月とともに劣化するような初期の設計に時間をかけるのは、合理的でないからです。

　その代わりに、設計を可能な限りクリーンかつシンプルに保つようにし、できるだけ頻繁にユニットテストや受け入れテストを行います。

　こうすることで、設計を柔軟かつ変更しやすく保てます。その柔軟性を利用して継続的に設計を改善するので、各イテレーションの最後には、そのイテレーションでの要求にもっともふさわしい設計が得られます。

　発展2　〜チーム文化で腐敗を許さない

　ソフトウェアを限界まで無秩序へと向かわせる最大の原因は、プロジェクト活動における心理学、あるいは文化です。

　腐ったコードを作らないためには、シンプルを常に意識しないといけません。さもないと、過剰な設計をしてしまったり、問題そのものより厄介な解決策を考えてしまったり、本質的な問題ではなくレアな問題ばかりに注力したりなど、コードが複雑になってしまいます。

　腐ったコードを見過ごすかどうかは、そのチームの文化次第です。場当たり的な修正を繰り返し、それを許容していけば、あっという間に無秩序は増大します。それを防止するには、チームの行動方針として、コードの腐敗に気付いたら、率先してリファクタリングすることを推奨します。コードの品質を優先する方針です。そうしなければならない雰囲気を作り、全員でよってたかって悪いコードを直し、コードを腐らせる暇を与えません。確かに、コストや時間を支払わなければなりませんが、コードが腐るリスクを回避できれば、十分な見返りのある投資となります。

出典書籍

『達人プログラマーーシステム開発の職人から名匠への道』アンドリューハント他, ピアソンエデュケーション（2000）

関連書籍

『アジャイルソフトウェア開発の奥義第2版オブジェクト指向開発の神髄と匠の技』ロバート・C・マーチン, ソフトバンククリエイティブ（2008）

『エントロピーをめぐる冒険初心者のための統計熱力学』鈴木炎, 講談社（2014）

書籍紹介

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

上田勲著
秀和システム　2,200円

一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか？ 本書は、よいコードを書く上で指針となる前提・原則・思想、つまり「プリンシプル」を解説するプログラミングスキル改善書です。初心者向けの書籍では絶対に説明しない、古今東西のプログラマーの知恵をこの一冊に凝縮しました！