読むべきコード量

読むべきコード量が増えるか

読むべきコードが増えるかどうかというのは、大きな判断材料だと思う。例えば、ActiveRecordよりDataMapperの方が抽象度が高いので、クラスは増えるし当然普通のファイル構成ならファイルが増える。それだけで読むべきコードが増えるかどうかというと、その判断は難しい。抽象度を上げたときにコードが増えるかどうかというのは実装と再利用性次第な気がする。書かれているコードから読むべきかどうかが判断できるかどうかも重要そう。ただ、人の判断能力を前提にコードを書くことは信頼性に欠ける。個人的には、少ないコードは読みやすい、というのだけ信頼してる。文字数か行数くらいでしか定量化できなさそう。行数は改行次第で不安定だから厳密に知りたいときは文字数を見てるけど、行数で大体推し量ってる。開発コストどう判断するのか、という話でも結局概念で測るのは無理で行数で数えるのが安定してる。
読むべきコードが多いっていうのはそういうことじゃない、って言われそう。でも「3クラス先くらいまで読むのは良いけどそれ以上になると厳しくなってくる」みたいな曖昧な指標では捉えたくない。「実装はきっとそこにある」って分かっているかどうかとかもある。コードを読んでて新しいことを学んでいるかどうかというのもある。そういうのが色々ありすぎて結局感覚でしか推し量れないのは信頼性に欠ける。

読むべきコード量をどう考えるか

読むべきコードと読んだ後の生産性については天秤に掛けられるべきだと思う。EmacsやVimなんかは学習コストが最高にハイだけど、1度使い方を覚えた後の生産性は著しく高い。皆がRailsにどういう考え方を持ってるかどうかは分からないけど、自分にとってのRailsはそうだった。やり方を覚えたあとの開発や理解の速さがある。そういう速さから得られる開発の気持ち良さがある。昨日、社内サービスの特定の部分の挙動を変えたいという要求があって、3年前に弊社で書かれていたRailsのコードをgit-cloneする機会があったけど、読んだことないにも関わらずルートディレクトリ開いて3秒ぐらいで目的の処理部分に到達できた。この学習コストの不要さをどう考えるか、大切そうな気がした。
世はまさに大公開時代、この世の全てがGitHubに置いてある。良くも悪くも、こういう考え方が積み重なって人生の設計指針に関わってしまっている。初代ゆとり世代として平成に生まれて以来、ずっと高速道路に乗って育ってきており、速さへの憧憬が人より多く募っている気がする。隔世感ある。