技術的負債に対処するヒントを書こうとした筈だったのに精神的に老いたプログラマによる鬱陶しい苦言になってしまった文章
技術的負債なんて結構前からある単語なのに急にTwitterあたりで流れ初めて面白いなーと思う。まぁこれに関して何を今更とか原典出さないのとか野暮なことは言わない。コードは動けば良いものじゃないという意識が広まるのはよいことだ。
しかし、可能ならば、乗っかって愚痴ったり逆に単に反省したりするだけでなく、議論をもう一歩進めてほしい。
まずは、負債とならない「きれいな」コードは常に正義なのかと言うこと。きれいなコードを書くには少なからず余分な工数がかかるし、誰もが出来ることではない。熟練者であってもうまく書けないこともあるだろう。書き捨てのモックアップに見えない部分まで手間をかけることに価値はあるだろうか。納期直前の切羽詰まった状況でベタ書きしててもちょっと責めづらい。この辺りを加味せず「常にきれいなコードを書こう」というのは、ちょっと非現実的ではないか。エンジニアたるもの、常に現実を見据えていたいものである。
ついでに、美しく粗結合を実現したコードは往々にして理解が難しく本人以外に修正困難になる、という点にも注意が必要である。 Cプログラマからコンバートされたての人々を集めた現場にOO言語の機構を存分に生かしたコードを渡したとして、それか想定通り拡張されることは期待できるだろうか。将来の変更に備えるためのコーディングをするなら、その将来の変更は誰が行うのか？ということも考えておかなければならない。
そもそも、負債の少ないコード、きれいなコードってなんだろうか。ある定義に*1よると変更に強いコードなのだが、極端な話、変更に強いかどうかなんて変更が来てみなければ分からない。ではなぜそんなコードがかけるかというと、バグ修正を含め、発生しそうな変更を予想しているからに他ならない。多くの現場を経験している熟練エンジニアでない限り、概ねそんな芸当は不可能である。デザインパターンも万能ではなく、どのパターンをどのように使うかは人間の判断である。それが容易に出来ているとすれば、それは単なる思い上がりであるか、ソフトウェアの形をしたソフトウェアでないものを作らされている場合である。
「きれいなコードを書こうよ！」って言うのは簡単だが、いざ実践しようと思うとさまざまな障害がたちはだかる。無理に押し通そうと思うと独り善がりだと糾弾され逆効果になるおそれもある。正直一般解は無い。無いんだが、まぁ一応、他人事っぽく僕が思うのは、無理に最初からきれいに書こうとせず、コードが汚くて困ると思ったら、そのタイミングで直せば良いじゃないか、と言うことである。言い換えると、汚いコードが存在することそのものは許容する代わりに、汚いコードに遭遇したらどうするかと言うことを常に考えておく。世の中キャッシュフロー経営というものが有るように、負債を前提に適切に管理してけば良いのである。プロトタイピングでは多少荒くてもガンガン書き進めて動くことを目指し方向が定まってからまた書き直せば良いし、固まっている部分は丁寧に進めれば良い。コアとなる部分は少数精鋭で徹底して作り込む一方で、誰が触るか分からない多くの部分は理解性重視でコードそのものは手加減し文書でカバーするのも有効である。
でもこれを単純にやると、またスキルの高い人がダメなコードを直し続ける羽目になってしまうので、みんなでコードレビューしてリファクタリングするフェイズを用意するといった手立てが必要になると思う。この辺りはソフトウェアプロセスとの絡みもあり難しいところだが、この問題を個人のスキルや意識/意志の問題に閉じさせるんじゃなくて、チームの戦略の問題にすることは必要になってくると思う。みんなでコードの良し悪しに関する嗅覚を鍛えて感性を共有してかないといけない。
という感じで竜頭蛇尾甚だしく「常に現実を」と言いながら全然現実味のあることが書けず単なる鬱陶しい茶々入れになってしまったが、まぁ、これ以上は"It depends."としか言えない気がするのでこの辺で。
