「リーダブルコード」について思うこと#1

個人ブログなので結構偏ったことを言っておく。自分の見える世界からは今はこれが真実に見える

意見がアップデートされたら#2が生まれるだろうし、おそらく生まれるから#1とする

リーダブルコードの定義

リーダブルコードって、なにもオブジェクトの形やら制約がハッキリしていることに限らず、それが泥臭く書いてあったとしてもスマートに書いてあったとしても、そのプログラムの一連の流れを見たときにやりたいことや想定される入出力がロジックやデバッグログ・コメント（これ結構重要）としてちゃんと見える形になっているコードのことだと私は思う。一般的な定義は置いておいて。

制約とロジック

さて、多くの場合“制約”ってのはそのロジックにおけるエッジケースをどう受け入れて排除するかっていう意思表示でしかなくて、それを本筋の正常系ロジック内に組み込みすぎるとノイジーであまりにも読みにくいコードがいとも簡単にできあがってしまうだろう。

モダンアーキテクチャと開発者の成長機会と生産性と

どれだけDIしててクリーンアーキテクチャやっててDDDになっていようが、結局は書く人の力量で大きく結果が変わるし、そのギャップをどれだけフレームワークで吸収しようにも有意な格差が消えることは一切ないどころか、そういった能力のない人が成長する機会を奪ったままプロジェクト自体の生産性を押し下げる存在になってしまうんでないかという気持ちがある

ただし、これは小規模なチームに限ったことで、もっと各ドメインにエキスパートがちゃんといる場合どうなんだろう、という気もする

結論

中小規模チームのアジャイルとDDDなどのプログラマーのレベル差吸収アーキテクチャとの相性はお世辞にもいいものとは言えない

おまけ

説明力とエラーを読む力

自分が観測できる範囲において、デバッグログやコメントが書けない、どう表現したらいいか分からないというエンジニアはそう珍しくなく、そしてリーダブルコードを書く能力があるとは言えない人がそのほとんどであった。

デバッグログにおいて「自分で書いたコードがどのタイミングでどんな状態であるべきか」という意図をもとに、「どの時点で差し込むべきか」「どんなメッセージにするか」という選択ができているものはコードリーディングの大きな一助になる。結局のところ自分が何をしたいつもりであるかを明示するにおいてログはコードの次に素直に表現され、コード以上にリーディング負荷が低い。

そして彼らは、エラーメッセージが読めない。はじめに読もうとしないし、どうしても取っ掛かりがないときにメッセージをググってStackOverflowにたどり着くも英語が読めない。対処療法が書かれていて実際にそのエラーメッセージと同じ事象に遭遇していることがあるが、自分のプログラムにそれを落とし込めない。どの部分がサンプルコードで、どの部分でどのような対処をすべきなのか判断できない。

おまけに、同様のエラーメッセージであっても事象が違うことがある。その場合に自分のもとで発生したエラーとは関係がないことがすぐに分からない。なぜこんな相関があるのかはわからない。たまたまかもしれないし疑似相関かもしれない。しかし眼前の事実は揺るがないのである。

後半は愚痴っぽく見えるかもしれないが思ったので一応発信しておく。