読者です 読者をやめる 読者になる 読者になる

レガシーコード生産ガイド

私に教えられることなら

「良い設計」の判断基準

プログラミングについて、最近考えていることです。

コードが良い設計かどうかが問題になるのは、人間が手を入れる時のはずです。例えばコンパイラが出力したバイトコードが人間にとって容易に拡張可能かどうかを気にする場面は殆ど無いでしょう。

良い設計を求める目的は、人間の弱点を補い、人間にとってわかりやすくするためです。プログラマという括りでも多種多様な人が居て、それぞれ得意・不得意も違うので、補い方やわかりやすさの方向性もそれぞれに合わせて大きく変える必要があります。

「視覚優位な人におすすめ」「注意力が弱い人に最適」などの前提が無く、それどころか人間を対象にしているという前提すら抜けて、○○指向はビジネスのモデル化に向いている・○○設計で複雑さに対処する等の議論をしても、全ての人に合う靴を作ろうとするようなもので、何の意味も無いと思います。

人間にとってわかりやすくするという目的のため様々な原則や設計手法が生まれています。しかし設計手法を考えたり原則を適用することが目的となった結果わかりにくくなってしまい、目的を見失ったまま原則に従うための新しい設計を考えた、という悪い冗談のような繰り返しをよく目にします。

何をどう解決するか

話を簡単にするため、ここではDRY原則、その中でも単純に「コードのコピペをしない」ということについて考えます。

同じコードを複数の場所にコピペしてしまうと、それを修正したくなったときに、忘れずに全ての場所を修正する必要があります。

大多数の人は忘れずに何かを行う事が苦手なので、それをコンピューターが解決してくれたら便利です。そのために設計を工夫して変更箇所を一つにまとめることは多くの場合において有益だと思います。

しかし、最初の目的は「忘れずに何かを行うこと」を排除することです。そのために「最初にこのメソッドを必ず呼び出すこと」などの忘れずに行う事が増えていくと意味がありません。また、似たようなコードをまとめるために大量の引数が必要になったりなど、別の種類の人間にとってのわかりにくさが増えるということもあります。

目的を別の方法で達成することもできます。同じ事を何箇所に書いても、コンパイラが変更時に教えてくれたり、IDEで一気に変更したりなどです。そういう対処が可能な場合、設計をこねくり回すよりも案外わかりやすいと感じる人は多いかもしれません。一番の目的は開発している「ある人」にとってのわかりやすさなので、それが達成できればコピペしても構わないはずです。

また、目的を必要としない人たちも中にはいるかもしれません。変更すべき箇所を全て頭の中に入れておけたり、チェックリストを整備してそれに従うことを完璧にこなせたりする人がいるかもしれません。そういった人たちにとってはコピペするのが最も良い書き方です。そうでは無い人がその中に入って苦しんでいる場合、自分に「も」合うように更に四苦八苦するよりは、そこから出て行って同じタイプの人間の輪に入った方がマシだと思います。

今できること

有益なタイプ分けや、わかりやすさを定量的に評価することもかなり難しいと思います。指標にこだわりすぎて目的を見失うこともありそうです。それらを前提とした原則・設計についての議論を期待することはこの先もできないでしょう。

現時点で個人が取れる対策としては、自分がコーディング時に何を苦手としているか・どういうミスをするのかを把握し、新しい原則・設計・技術を採用するかどうかの判断基準にするしか無さそうです。

そして、どういった人向けの話なのか、という前提が欠如している議論を真面目に追うのは避けた方が心身の健康に良いでしょう。

広告を非表示にする