生産性を高めたかったらコードは短い方がいい
コードは短いのがいいのか、それとも誰でもわかるようにあまり新しい記法を使わない方が良い等の議論がある。私は生産性を高めたかったらコードは短い方がいいよねと最近さらに思うようになった。
尚、ここでいう生産性はみんながほわっともっているイメージのお話で、本当の意味では「価値」だと思う。でもタイトルを「価値を高めたかったら」としたら意味がわかりにくいので、タイトルは生産性とした。
遅ればせながらRailsのコードリーディングをやっているが、ActiveSupportのconcern.rbを読んでいてあることに気づいた。
すっごくrdocのドキュメントが長いのに、実際のコードは凄く短い。rdoc用のコメントが99行に対して、実際のコードは、26行だ。そういえば、Railsのコードは他のも短い。今私は某イケメンプログラマと仕事をしていますが、彼のコードも凄く短い。これは凄く価値がでているコードということではないか?
module ActiveSupport # A typical module looks like this: # # module M # def self.included(base) # base.extend ClassMethods # base.class_eval do # scope :disabled, -> { where(disabled: true) } # end # end # # module ClassMethods # ... # end # end # # By using <tt>ActiveSupport::Concern</tt> the above module could instead be # written as: # # require 'active_support/concern' # # module M # extend ActiveSupport::Concern # # included do # scope :disabled, -> { where(disabled: true) } # end # # module ClassMethods # ... # end # end : 長いので中略 # end module Concern def self.extended(base) #:nodoc: base.instance_variable_set("@_dependencies", []) end def append_features(base) if base.instance_variable_defined?("@_dependencies") base.instance_variable_get("@_dependencies") << self return false else return false if base < self @_dependencies.each { |dep| base.send(:include, dep) } super base.extend const_get("ClassMethods") if const_defined?("ClassMethods") base.class_eval(&@_included_block) if instance_variable_defined?("@_included_block") end end def included(base = nil, &block) if base.nil? @_included_block = block else super end end end end
Ruby on Railsのconcern.rbより
最近は幸せシフトをするためには、単位時間で価値をより多く出せるようになるといいと思うので、プログラマの生産性(本当は価値)の研究をしてる。プログラマの生産性は10倍〜25倍程度と言われているが、なぜそんな差が出るのか?
結局コードを書く部分ではない。イケメンプログラマはタイピングが早い訳ではなく、結局のところ「考える」ところが早いのだ。一方初心者を観察していると、中身がわかっていなかったりするので、凄く試行錯誤して時間を沢山つかったり、事前に凄く調査しないとプログラミングできなかったりする。
物理的な部分ではそこまで差はつかない。しかし、「考える」という部分は凄く短縮出来る要素がある。しかも長いコードを書く人はconcern.rbのような抽象的なmoduleを作るという発想自体がないかもしれない。
そう考えると、物理的なリード/ライトは短ければ短いほどいい。そこでは差がつかないから、短ければ短いほど、読む/書く時間が短くなる。そのかわりその部分は事前に「学習する」とか「新しいコーディング方法を知っている」部分が必要になるのだが、そういうものが準備されている事によって、爆速のスピードが得られる事が可能になる。だって、「考える」部分は生産性が10倍にも25倍にも高められる部分だから。
だから、価値の意味での爆速を得たかったら、勉強する事を推奨して、短いコードを書くようにしたらいいと私は思う。