クソコード問題には、いくつかの「不安」が隠れていると見た。そこを解決しないと感情的な問題点は解決しない。
1.現状、クソコードを量産する人がいる場合
2.現状、クソコードを改善できない組織である場合
3.クソコードをリファクタリングする時に壊す恐怖
この３つに対して、どうにかしたい / どうにかなれよ、と思っているのがクソコードに対する不満につながっているのではないだろうか？と思った。
人の批判は堂々としにくいから、如何にクソコードは駄目なのか？という不満だけで「誰か」を変えたい、という代理戦争的言説がネットにはびこることになるのではないだろうか。
そういう状況に対して、
4.引き継いだクソコードを書いた人が社内にいない場合
は、終わった話なので意気揚々と片付けよう、という結論でしかない。知恵を絞って、がんばろう。
例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。
この話を見たときに、部屋の片付けコンサルをやってる知り合いのWebに書いてあったのを思い出しました。
結局、コードを改善してやりたいのはこういうことですよね？
部屋の中にある無駄なモノと無駄な動きを省き、お気に入りのモノだけに囲まれたストレスフリーの部屋を作る
「ヒバリ舎」より
さらに面白いことが書いてある。
片づけ方って特に教えてもらわないまま大人になる人が殆どだと思います。
誰もが親や先生から「片づけなさい！」って言われて育つけれど
じゃあ片づけ方は教えてもらった？って考えたら教えてもらってないはず。
お料理やお裁縫、お掃除の仕方は学校で習うのに。
片づけなんてわざわざ教えてもらわなくてもできて当たり前ってこと？
「ヒバリ舎について」より
その通り。「動かすため」のコードの書き方は教わってるけど、整理の仕方は技術者のリテラシーに依存してるのが現状。
だいたいみんななんとなく適当にモノの置き場所を決めています。
ここで「置き場所」と「いつも使う場所」が離れていたら残念、それは
使ったら使ったまま出しっぱなしになる確率大です。
使う時は必要だから遠い場所でも取りに行くけど
使ったものを元に戻す時に遠かったらそのへんにポイって置いちゃう。
だって面倒だもの。
こういうことが無くなるようにするには
モノの置き場所を最初にじっくりちゃんと考えることが大切なのです。
「ヒバリ舎について」より
考えろ！
でも、どういう前提条件を持ってクソコードであるか、という部分は無視できない。
主にベンチャー的な新事業に限ると、
「0-1」フェーズにおいては、クソコードの存在は許容せざるを得ない。「誰が書くか」という部分において、必ずしも技術力が優先されるとは限らない。
「1-10」フェーズにおいては、チーム開発になるので、淡々と改善する。
クソコードが「1-10」フェーズというチャンスをくれたと考え、その状態を解決することそこそ、「1-10」フェーズのエンジニアの職能だと思って、ワクワクできるのが一番良いと思うけどね。
SIerさん的な、そもそも10年メンテするよって言ってるようなところは、言語そのものがメンテ性を前提としていたり、コーディング基準とかでカバーしてるハズなのだけど、仕様書も含めて、そこにコストをかけるソースコード自体が、「技術を売る」ビジネスモデルにおける成果物としての商品なのである、ということを意識できたら、そういう価値を商品として必要としてないベンチャー系に転職する時に、ストレスフリーに近づけるのではないかと考えたりします。
（と言いつつも、品質の判断材料がコードレビューで行われるのではなく、テストシートと画面キャプチャによるエビデンスベースで行われているという品質管理の問題が、彼らの一番辛いところと思われ。）
おもに「サービス」を商品として提供している場合は、クソコードの技術論そのものが問題なのではなく、自分たちがやりやすい状態を維持することが一番大切なのだと思っています。技術的負債の返済計画を立てて行くであったり、守りのための開発を行う、なども含めて。
クソコード問題で一番いやなのは、そのコードの集合体を全部否定してしまうこと。それって作り直したい症候群につながるんだけど、それだけでは新しいソースコードが新たなクソコードにならない保証はどこにもない。
少なくとも、現存するコードを改善する、という選択肢と、新規にコードを書くという二つの選択肢において、「この人なら信じられる」という属人的な判断を除き、新しいコードの方がよくなるという論理的な理由はない。クソコードがクソコードたる本質はフレームワークだとか開発言語やライブラリを使うことで解決する問題ではないからだ。技術的な問題であればリファクタリングはそんなに難しくなくて、思わず逃げ出したくなる部分というのは、大体が、冗長性に基づくものか、無駄に構造化されすぎてワケわかんねーよ、という部分に表れる、元の開発者の性格に基づくものではないかとは思う。
つまり性格が合うか合わないかをソースコード上で戦っているだけ、だったりするのではないか。いい加減な奴が書いたコードは許せない、みたいになってしまうと、すべてのソースコードが悪に見えてくる。
既存コードが改善不可能だと判断する理由が「クソコードの量と質」に依存する問題だったとしても、クソコードは、部分的なコードを秘伝のタレのスコープに押し込む方法論も含めて、論理的には絶対に解決可能な話なので、そこをやりきれるマインドと技術力を持ってして、合理的に新しいコードに立ち向かう判断ができてるなら良いんだけど、恐怖心やストレスから逃げるための、なんとなく「嫌だから」みたいな話になると、何も価値を生まないか、新しいレガシーを作るかのどちらかになりがちだと思う。
いずれにせよ「クソコードは悪だ」で思考停止せず、クソコードを解決するスキルもまた、技術者の重要なスキルだと思って、楽しんでほしいです。特に「1-10」フェーズはそれこそが発展の道なのだと思いますし。
【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください