きれいなよりも変化に強いソースコードが良い

f:id:hrmch-ioii:20181030232759j:plain

ほとんどのエンジニアはソースコードを綺麗に書けと言う。確かに汚いよりも綺麗な方がいい。綺麗だと不具合も少ないし、整理整頓されていれば捜し物だって見つけやすい。でも、エンジニアに「きれいなソースコードってなに？」って聞くと答えられない人が多い気がする。

可読性が悪いから綺麗ではない

と答えるエンジニアは多い。

そもそも可読性って何よ？

ってことになる。調べてみると

コンピュータ・プログラミングにおける可読性（readability）とは、プログラムのソースコードを人間が読んだときの、その目的や処理の流れの理解しやすさを指している。

引用：Wikipedia

人間が読んだときの理解しやすさとのことだが、

これって人によって理解のしやすさなんて変わるだろうに。読んでるソースコードのバックグランドをよく知っている人もいればどうでない人もいる。読んでいる人によって前提条件が違うのである。

さらに、処理の複雑さによっても理解のしやすさが違う。足し算をプログラミングするのと、積分を実装するのでは複雑さが違う。

可読性は読む人と処理によって大きく変わってくる。

つまり、このソースコード可読性いいよね？

と聞いて、いいね！と答える人の確率はクソ低いのである。

と、言う人もいる。

確かに小さい字で書いてある小説の本よりも、俳句などの少ない文字で表している方が綺麗に見える。なによりも少ない方が読む気が起きる。というよりは、読むのに飽きる前に終わってくれる。

少ない実装量になる可能性は、処理が簡単かフレームワークを最大限に利用しているかが考えられる。

前者の場合は簡単な処理なのできれいもくそもない。書くことがないから少ないのだ。

後者の場合、フレームワークをあまり知らない人にとっては、何をしているのか全く理解できない。きれいだなんて思わないはずだ。だって疑問ばかりが浮かんでくるからきれいなんて考えない。

つまり、このソースコード可読性いいよね？

と聞いて、いいね！と答える人の確率はこれまた低い。

ソースコードは機能追加や不具合修正などを繰り返す。これを繰り返してくうちに、汚くなる。いろいろな人が手を加え、締切の都合により一時的な修正が永遠に残る。

こんなのはどのアプリでも出くわす。

どんなに万人にとって可読性が良いソースコードを書いても、締切や緊急性などの都合上いろんな人の手が入る。実装量が少なかった部分も機能追加で実装量は増えていく。

こんな時でも、少ない修正量で影響範囲を最小限にできて、機能追加がしやすいソースコード。きれいなソースコードを目指すよりも変化に強いソースコードを書くことが価値がある。

のである。変化に強いということは、取替可能が部品がたくさんあることになる。

どこか一箇所が壊れてもすぐ交換できて、どこかを拡張しようとする場合もすぐにドッキングできる。

これを実現するには、意味のある単位で部品であるソースコードを完結させ、ジョイントするためのソースコードを用意し、簡単に結合できるようにする。

それを実現するために、適切なインターフェースが必要になり、メソットの一つ一つのinとoutを規格化していく。こんなことをすると、あっという間に実装量が増える。細かいパーツが増えていくので可読性なんてよくわからない。わかるのはパーツが組み上がって出来上がったときだ。

アプリが出来上がって、アプリが進化し続けれるかが重要なんだ。きれいなソースコードであることは重要ではないよ。