分かりやすいコード

アジアのソフトウエア開発現場にて
「分かりやすいコード」
https://el.jibun.atmarkit.co.jp/yamayattyann/2010/11/post-0cec.html

　共通ロジックのリファクタリングは、コードの可読性に立ちはだかる大きな問題の１つですね。（そのアプリケーション内において）低階層に位置する共通関数群やスーパークラス等は、ソフトウェアの大部分に影響をおよぼす可能性があるため、多くの場合で修正を加えることが困難です。これらの低階層部分はリファクタリングの頻度を大きく下げる必要があり、その実現のためにも初期設計が非常に重要になってくると私は考えます。そして、あまりにも手を加える頻度が高まった場合には、思い切ってこれらを捨てる（再利用をあきらめて新たに作る）べきではないかとさえ私は思っています。

　コードの量は増え、冗長化してしまうため、一見すると保守性が下がるように見えますが、新規部分のリファクタリングは低リスクで行えるでしょうし、既存コードの可読性・保守性は保たれたままになります。見極めが難しいところですが、設計者はこうした「再利用あきらめ分岐点」なるものを意識し、来るべき時にはそれを実施する勇気を持つべきではないでしょうか。

　例えばオブジェクト指向言語の特徴である継承による再利用性というのは、継承元クラスの修正コストが高くなる要因により、保守性と一部相反している面があると言えると思います。限られた工数で動いている実際の現場においては、可読性の著しく低下したスーパークラスに手を加えたり、スーパークラスの修正によって莫大なテスト工数がかかったりというケースが往々にしてあるため、オブジェクト指向のメリットを最大限に享受できていないのが実状ではないでしょうか。

　また、これらの低階層部分は漏れのないようなるべく汎用的に設計すると思いますが、あまりにも汎化が進んでしまうと恐ろしくアクセシビリティが低下してしまいます。設計者は可能な限り汎化を押さえ、かつ柔軟に対応できる設計を心がけなければならないのですが、これは対象となる実際の業務をある程度把握していないとできないことであり、そういう意味ではこれらの設計は（プログラムに精通している前提で）上流がやるべきものだと私は思います。