駄目なコードには3種類パターンがある。
— るっか和尚 (@lucca0show) 2017年10月26日
- 技術的負債となるコード
- ピヨピヨした伸びしろのあるコード
- 書いたやつを殴っても許されるウンコード
この3つだ。
一般的に駄目なコード、あるいはレガシーコードやウンコード、スパゲッティーコードなどなど駄目なコードに対する語彙は非常に多い。 ただじゃあこれら全部が同列の駄目さかというと個人的には違うと思っていてその所感を書いて整理したいと思う。
技術的負債はスケジュール的な判断や負債になることよりも重要視すべき事柄がありそちらを優先した結果なのできちんと返済意思さえあれば問題ではない。
— るっか和尚 (@lucca0show) 2017年10月26日
よくいう技術的負債というのは「きちんと書いてる時間がないのでとりあえず動くコードを書くけど将来的に直す!」みたいなコードのことだと認識していて 本来お金をもらって仕事をしている以上全ての駄目なコードはこうなっていないといけないと思ってる。 お仕事である以上納期を守るというのは最低限守らないといけない約束事なのでそちらを優先した結果あまり良くないコードが残ってしまうのは仕方のないことだと思う。 納期を無視してでも綺麗なコードを書けとはさすがにどんな人でも言わないと思ってるが世の中トチ狂った人がいないとも限らないので断定は避けたいと思う。
伸びしろのあるピヨピヨしたコードも問題はあるがレビューや設計などチームでカバー出来るし何よりも誰もが最初は未熟なので仕方のない部分がある。
— るっか和尚 (@lucca0show) 2017年10月26日
同じことを繰り返さなければ大丈夫だ。
ピヨピヨしたコードは新しくジョインした直後のチームメンバーや使用しているフレームワーク、言語、ライブラリなどに馴染みが薄い人が書きがちなコードのことで誰もがかつては通った道だと思う。 このコードはお金をもらっている以上それを言い訳にすることはできないが少なくともきちんとチームでコードレビューすることが浸透していれば問題になることはないと考えている。 技量が急激に上がることが少ない以上、これらの状態は短いか長いかの違いはあるが必ず発生するし発生しないわけがないと考えている。 なおコードレビューやチューターがいないなどのサポートがない場合は伸びしろがあるコードだったとしてもピヨピヨしたコードではなく次に紹介するコードに該当するとぼくは考えている。
問題は殴っても許されるウンコードでこれらのコードは大抵動かない、あるいは動くがバギーな実装になっていることが多く実装時間の何倍もの時間をかけないと修正出来ないしそもそも技術的返済の計画がされていないという問題があってまあ「殺すぞ!」って言われても仕方ないコードになっている。
— るっか和尚 (@lucca0show) 2017年10月26日
タイトルで最後と表現した一番駄目なやつ。 遭遇すると書いた人間やチームを呪わずにはいられず、ソウルジェムが一気に濁ってしまう危険な呪文。 ガンジーが核持って殴り込みに来るレベル。
そして得てしてエンジニアが揶揄して例題にあげる駄目なコードでもある。 なお伸びしろのあるピヨピヨしているコードもそれをサポートする仕組みや体制がなければ時間が経過するほどにこのコード状態になると考えている。 ぼくはこれらのコードをウンコードと呼んでいる、たまに食事の席で発言してしまい「ヤッチマッター」って顔をしている。
まずなにが駄目かというとウンコードの多くは書き捨てのスクリプトであることだ。 その場でしか使わないし、大したシステムでないからとりあえず動けばいい…みたいな考えで書き捨てられているのがこれに値する。
そしてこれらの問題は書いた時間の10倍近い労力を要さないと修正することが困難であるという一事に尽きる。 まず「なにをしているのかわからないコード」を読み解くのに時間がかかり、「不可思議な挙動をするコードを調べる」のに時間がかかり、「そもそもこれバグってんじゃねえか!」という現象に苛まされ、「直した!と思ったら全然関係ないところで使用されたあげくにエラーになってしまい」、「それらを全て問題ないかチェックした上でリファクタリングやバグフィックスを行い」ようやく通常のコードリーディングや修正と同等のタスクに着手出来る状態になる。
とぼくは思っていてウンコードはどう取り繕ってもウンコードで書いた人そのものを攻撃する気はないがその状態で放置したマネージャーに対しては「殺すぞ!」くらい言っても許されると思ってる。 コードレビューがされないのはマネジメントの責任だとぼくは考えている。 テストのないコードがレガシーなコードならば、レビューのないコードはウンコードだ。
くらい言っても許されるのじゃあなかろうか。
何がいいたいかというとコードには賞味期限があってどんなに書いた当時素晴らしいコードも時間が立つに連れ鮮度が落ちていく。 問題なのは定期的に腐った、あるいは腐りそうなコードを適宜選別して捨てるものは捨てる、新しいものと入れ替えるなどのタスクが必要だということだ。
スーパーに置かれている野菜が腐って異臭を放っている状態で放置されていたら誰だって怒るだろうと思う。 それと同じことをプログラムコードで行って何故クレームが来ないと思えるのか?
本当の意味で顧客のことを考えるならサポートを充実させるよりも何よりもこの手のウンコードを撲滅することを目指すべきじゃあなかろうかと考えることが増えた。 特に顧客は自分たちでは実現できない、あるいは時間がかかりすぎることをお金を払ってぼくたちの技術力を買っているのだから、ぼくたちはその金額に見合うだけの技術力を提供する義務があると思う。 金額の結果がウンコードならそれはそれでいいが、それっきりにしてもらうか負債として会社の未来に残さないでいただきたい、書いたやつが墓場まで持って帰ってくれ。
…もう人間がコード書くより機械に書かせたほうが質の高いコードが出来上がるんじゃねえかと最近割りと本気で思ってきた。