■

どうにもこうにもソースが汚い。
新しいプロジェクトに入ると大抵こーゆーのを目の当たりにする。
ここでは「クサレソース」の文言で通そう。

どこかのプログラマ入門生が構築したソースは
十中八九ではなく十中十汚い。*1
意味の無いループ。
意味の無いべた書き。
意味の無い判定文。

こーゆーのをそのままにしておく理由がどこにあるだろうか？
見た個所だけでもいい。
見たやつが直せ。( ・ω・)oビシッ

ボリュームにも依るが、大抵のクサレソースは手直しすることによる時間のコストってのはそんなにかからない。
なにしろクサレソースは解読に時間がかかる。
時には仕様書との突合せも必要になる。
その上で、これから手を入れたらよい場所、だめな個所が判別できるようになる。
つまり、肝心要の「変更作業」に入るまでにそれ相応の時間がかかるということだ。
その上、これまたほぼ例外なくコメント文はない。
解読にかけた時間はまたすぐに必要になる。
作業者が変わったりするのはもちろん、作業した本人でも２〜３週間経ったりした後にはほぼ。
クサレソースの仕組みを脳内に保存しておくことを人は本能的に拒絶するからだ。

それならば「あるべき姿」に変更していくほうが効率的だ。
どうせ分からないソース。
どうせ今知らない仕様。
確認しながら作業しなきゃいけないのは同じなら、
改変していきながらでも、かかる時間に大差はない。
コメント文を足し、仕様の確認できた部分もコメント文に残し、
妙な変数名、無駄な引数、アホっぽい代入文、複雑すぎる代入式など、
片っ端から直すのである。
シンプルデザインに替えるのである。

そしてテストをする。
変更が発生したあと、どの道やらなきゃいけない作業なのだ。
それなら必ずでるバグも、確実につぶせる形のほうがいい。
クサレソースを追っかけて、あっちをつぶせばこっちが復活とかいうような
いたちごっこなんざ頼まれてもやりたくない。
単純明快なソースにしておけば「でるもんはでる。けどすぐつぶせる。」
ってな体制がとれる。
変更改修までの時間も早いし、第一いたちごっこになることはほぼ無い。

ここにいたって、「改修に要する時間」の過多は逆転する。
クサレソースは改変したほうが時間が短くなるのだ。
多少長くなっても、後に続く者たちへの道しるべとなる。
同じ調査を行わせなくて済む。地味だがとても意味ある行動だ。
3週間後の自分のティータイムを確保することにも繋がる。

クサレソースは百害あって一理なしだ。
まかり間違っても「今、動いている」っていう幻想に惑わされてはいけない。
いつ爆発するかもしれない不発弾がそこにあるだけなのだ。
適切に処理しなければその内誰かが被弾する。
また、クサレソースの生みの親に対しても
「こーこーこうするのがよりよいソースになるんやでぇ」
っと実例をもって教育することにより、
その内クサレソースを生まなくなることが期待できる。

っという意思を持って今。
目の前のクサレソースに立ち向かう原動力にしよう。そうしよう。

*1:もちろん昔のおいらも例外ではない。ヽ(´ー`)ノ