■

なぜ美しいコードを書くのか
http://maname.txt-nifty.com/blog/2008/02/for_human.html
を見たら改めて考えてみた。

ボクはソースを作りたいので、
考える時間を出来る限り確保したい欲がある。
一度作ったソースは作り終えていたり、修正中など変更対象であると思っている。
修正や作り変えたりする作業は、プログラミング上避けて通れないコトなのだが、
その作業には「今のカタチ」を理解する必要がある。

理解するための時間は短いほうがいい。
新しい仕組みを生みだし創ることに脳内リソースを割当たい気持ちとしては、
理解を妨げる難解なソースコードは邪魔な存在でしかない。

ゆえに可能な限り理解を助けるための構造を良しとする評価基準がある。

ソースと向かい合う時間は「考える」ことが楽しい。
ソースと向かい合う時間が「理解する」ことだとツラい。

ツラいことをしたくないサボリ屋な性分としては楽しいことに飛びつくのは至極当然だね。

とはいえ、
以上が個人だけのうちで納まっているうちは『他人が見ても美しいソース』たりえない。
自己満足という完結のしかたがあるからなのだが、
欲望はもうちょっと先にも行き着ける。

仕事には命題がある。
命題には解法があり、時間もいる。
サボリ屋が考えることはいつも同じで「楽したい」である。
手数少なく短時間で終わらせるに越したことは無いと考える。
作業に不必要な時間なんて取られたくない。
不要な時間と思えること全てに対してそう思う。
代表的なのが「自分の尻拭い」であり「他人の尻拭い」も含む。
余計なバグをだし、原因を考えることは楽しさの一部だが、
そのために構造を理解し、連鎖的に理解を膨らますことは苦痛を伴う。
そんなのも楽しいと思えるのは初めだけなので、そのうちいやになる。
構造を複雑化してあったり、体系付けられていない仕組みがだいたい苦痛の原因となる。
作りやすいからって膨らましていくと必ずそうなる。
ツギハギだらけのソースコードってのは、
理解する必要がてんこもりな苦痛の塊にしかみえない。
誰が好き好んで苦痛の塊と対峙したいだろう。
理路整然と体系付けられているソースコードは理解の助けになる。
バグトレース時、初見で何がどうなっているかよく分からないコード群だとしても、
想像した所に想像したカタチがあれば大助かりだ。

人は思考速度を超えた理解は難しい。
神降臨時の閃きを持ってすれば時に超えれる。
が、しかし、人体の限界にチャレンジみたいな難しいことは、
ムリに超えようとせずに代替案を模索するほうが楽でいい。
ソースコードの場合は人の思考速度並みに理解できれば最高じゃないか。
閃きをもって全体の仕組みが把握できることもあるだろう。

ゆえに、人の思考速度程度を求めて構築するようになる。
　・何がどうなってこうなる
　・このタイミングで行われるなんたらという処理の中身
とかあいまいな指示からソースを追跡できるようになっていることが望ましいと思う。

ボタンクリック　→　処理全部

という構造より

ボタンクリック　→　処理A　→ 処理B　→ 処理C　→ 処理D

みたいな区切りがあるほうが追跡しやすい仕組みであると思う。

つまり。
理解しやすくて追跡しやすければ実務上楽が出来る。

他人にも波及できればさらに楽が出来る。
みんな今より楽になる。
ハッピーハッピー。

自分の場合。
コードを美しくしたい理由は楽したいから。
一緒に遊びに行く仲間の作業も楽にできれば自分も楽しい。
世のため人のためとか、「こうあるべきだッッ」みたいなクソみたいな理由のためじゃなくて、
我が為オレの為だな〜と書いてて思った。