Subscribed unsubscribe Subscribe Subscribe

チーム開発とクソコード


今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。


そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。


仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく、単にそのコードを書いた人が良いコードの書き方を知らなかったと思うしかありません。


ただそういったコードを書くのが下手くそな人たちが単にくそなのかというとそうでもなく、コードを書くのは下手だけどドメイン知識がすごいとか、DBやSQLなら異常に詳しいとか、その人が製品触るとなぜかバグが見つかるとか、あとはもう技術どうこう関係ないけどいちいち面白いとか、いろいろあります。


コードについて語ろうとすると当然コードを書くのが得意な人が強いので、クソコードを書く人はクソ、良いコードを書ける人間だけ雇え、となりがちだけど、コードを書くのが得意、コードにしか興味がない、みたいな人だけ集まるのも多様性に欠けて危険な感じがします。エンジニアとして、チームの一員としての価値の発揮の仕方は別にコードを書くことに限らないと思うので、コード書く力だけ偏重するのはやめたいです。


というわけでクソコードを解決するためには、ビジネス上の都合とか技術的負債がどうとか議論するのも良いですが、良いチーム作ってコードレビューで元気に殴り合いつつ、コード書くのが得意な人がリードしてコードの品質を底上げしていこうと考えるのがテンションあがって良いと思います。


さて git blame するか。