「綺麗なコード」にはそれほど価値がない

認めたくなかったが、どうやらそうみたいだ。

結局のところ、客は「綺麗なコード」ではなく、「要望どおりに動いているシステム」が欲しいのであって、それがコピペ駆動開発だろうがインデントがなかろうが、クラス名にキャメルケースとスネークケースが混じっていようが、一向に構わないのである。

ソースが綺麗で、パッケージ構成やクラス分割の単位が明確だと、作る側としてはメリットが多い。いちいち迷うこともないし、直感的に次の改修を行えるからだ。

ソースを壊すのは簡単だ。時間がない時に無能なプログラマが一人いてくれれば、彼がリファクタリング困難なスパゲッティを絡めておいてくれる。あとからほぐす時間も費用もなく、また次もそれに依存したものを作らざるを得なくなっているのだ。

だがそんなものは開発者側の都合。分かりにくかろうがなんだろうが、サビ残してテメェらで上手くやっとけ。これが客の意向で、これは本当に正しい。

客が「開発者が気持ちよく仕事できるようにするため」のリファクタリング費用を、下手したら開発費用よりも多く積まれて、納得するはずもないよな。

振る舞いを変えずにコードを綺麗にしたとして、そのメリットを享受できるのは開発者だけだし、その費用って最初からきちんとやっとけば掛からなかったワケだし、なんでウチが払うの？と。

全くもってそのとおりだ。極端に納期を短く設定したり乱暴な発注をしていない限り、客側に「ソースが汚いことによる問題の補填」をしてもらえることはないだろう。

開発者としては、やっぱり綺麗なコードにしたいし、「古いフレームワーク使ってて制約が多い」とかなら「新しくて便利なコレ使いましょうよ」とかやりたい。

でもそれで気持ちよくなるのは自分だけで、現実は汚いコードでも動いてるし、汚いコードが実現しているシステムをみんな有難がっている。

自分は経験年数はまだまだだし、場数も決して多くはないが、それなりに色んなシステムを見てきて、意図の分からないコードの塊ばかりだと感じてきた。でも、それでも別によくて、コードが綺麗であることなんて、価値も低けりゃ優先度も最低なんだなと。

システムは自分を含めて誰かが保守していくし、分かりにくいけど変えられないコードはコメントやドキュメントで補われるし。だいたい、どれだけ分かりにくかろうが今は正しく動いているので、時間がかかっても読み解けないはずはない。開発者もそこまで困ってなんにもできなくなるかというと、実はそこまででもなかったりする。

こんなことをモヤモヤ思ってて、もうなんか、綺麗に書こうとか、クラスを意識してとか、そういうことを仕事で書くコードに対して考えないようにしようと思ってきた。