ソースコードの汚さは「諦めた回数」に比例する

良いコード・悪いコードに対する知見がない初心者は必ずしも当てはまらないが、ソースコードの汚さは「何かを諦めた回数」に比例すると思う。

やることが少なく、シンプルで小規模なコードなら、一人で綺麗に保てるし、複数人で面倒を見ていてもスタイルや設計方針が揃えやすい。

しかし、やることが増えてロジックが複雑になっていくと、各メンバの手に負える規模を超えてきて、「諦め」なくてはならないことが増えてくる。

例えば、ある機能を追加することになった時、改修範囲とは関係が薄い既存機能も含めてリファクタリングしたら、とてもシンプルな構成にできるなぁ、などと思ったとする。しかし現実的には工数が潤沢にもらえず、仕方なく必要なところに似たようなコードを継ぎ接ぎして改修することになる。

もしくは、社内ルールやお客様都合などのしがらみによって、「こういう命名にしたら分かりやすいのに」とか「構成をこういう風に変えたら良くなるのに」とか思ってもそれを実現することは許されず、「もういっかコレで」と投げやりに物事を決めてしまうことも少なくないだろう。

こうした、その場その場での小さな諦め・妥協を積み重ねていくと、見通しの悪いコードが生まれ、そこに手を加えることになった別の担当もウンザリしながら何となく修正を入れる。「本当はこうしたい」という希望を捨てれば捨てる程、やはり「あるべきコード」からは遠ざかっていくようだ。

これは「割れ窓理論」に近いモノもあるかもしれない。当初の一人ひとりの野望は大きくとも、「既に諦められた」コードを目の前にして、「俺だけちゃんとやっても仕方ないしなぁ…」と、質を落とした対応を付け加えていくことで、システム全体が負債の山になっていく。最初は小さな諦めの形跡であっても、それがどんどん肥大化していくのだ。

こうならないためにできる対策は、物凄く面倒臭く、近道がないので、みんな「こうなることがしょうがない」ものであるかのように扱う。でもそれじゃいつまでもくだらない苦労をし続けることになる。

とれる対策は、「どんなに小さな決断でも諦めないこと」しかない。

社内ルールがズレているなら社内ルールを変える。お客様の要望をそのまま飲んだらヒドいことになるのであれば、双方のためになる代替案を提案する。極端な話、リリースが遅延しようとも、一つも諦めない方が、品質のためにはなると思う。

また、諦めムードが蔓延した開発チームは作業がずさんになっていくので、バグが増えたり、その後の運用・保守に余計な工数がかかったりする。後でズルズルと時間を奪われるよりは、開発中に注力して問題を未然に回避した方が良いだろう。

みんなそうできる時間がないことは百も承知だが、諦めるストレスと、諦めたことによる負債を避けることに、もう少し力を注いでいけたら、平和になるんじゃないかなと思っている。