登大遊@筑波大学情報学類のSoftEther VPN日記の「論理的思考の放棄」を読んだ。
俺って１日でどらくらいの量のコードが書けるんだろうか。仕事でも、計測したことってないなぁ。
WindowsLiveWriterのアマゾンのプラグインのC#のコードを数えてみたらだいたい800行くらい。あれは仕事から帰ってきた夜中に書いたものだから、まぁ６時間くらいかなぁ。
VoiceChatはDirectPlayとDirectSoundを使ったC++のコードでだいたい5000行くらい。んでも、あれは何日もかけてじっくり書いたコードだし。
1日10,000行以上書けるかと聞かれたらちょっと無理かなぁ。思いっきり集中して1日2～3000行くらいが限度かなぁ。
普通の開発者の作業能力は、1ヶ月で数百行程度、多い人でも1ヶ月で3,000行程度らしい。
まぁそうだろうなぁ。俺も普段の仕事ではそんなもんだと思う。まぁ最近は、ごりごりプログラムを書く仕事というよりも、デザインとか、フレームワークの濃いところだけとか、デバッグで誰もがさじを投げたところとか、コードレビューとか、そんなんばっかりで、あんまり書いてないけどね。
まず最も重要な前提知識として、以下の 3 つのことを遵守することが必須である。
- 努力しないこと
- 論理的に考えないこと
- 頭を使わないこと
これは非常に賛成。
500行くらいの他人のコードをデバッグするために、読みづらいからと、テンポラリにさくさく書き直してたら、100行くらいになっちゃった。てなことはよくある。んで、問題個所を見つけて、ピンポイントで元の500行のコードを修正する。せっかくなので100行のコードもコメントとして添付してあげる。ここで、100行のコードに置き換えることは、やっていいときと悪いときがあるので注意。テストなどを考えると、なんでも置き換えていいってもんじゃない。
基本的に僕の書くコードは短い。単純に言えば、僕が覚えられないから。
大学生のときなどは、若くて体力もあって、記憶力も集中力もあったので、長いコードを一気に書いても全体を記憶していられた。最近は、覚えられないので、覚えられる範囲のコードしか書かない。でも、できあがりは、あんまり変わらなかったりする。
新卒の人のコードをレビューしたりすることもあるけども、わざわざこんなに難しく書かなくてもいいのに。って思うのと同じ。
まず、だいたいこういうソフトウェアがあればいいなあとか、このような機能を付ける必要があるなとかいった、とても抽象的なことを思い浮かべる。この際、「絶対に論理的に考えないこと」が必要である。論理的に少しでも考えてしまうと、途中までうまくいっても、それが壊れてしまい、最初からやり直しになるので注意する。感覚的な思考でもってこれを行うのである。
次に、だいたいイメージができたところで、心の中に、ソフトウェアの設計図やデータ構造といったものを思い起こす。ここで注意するのは、「絶対に論理的に考えて設計をしないこと」である。徹底して、感覚的な思考でもって設計する。
あぁ、こんな感じ、こんな感じ。ここでは「感覚的な思考」って言葉を使っているけど、僕がよくいうのは、「匂いがする」って言葉。
この、匂いがするポイントってのが重要で、なんとなくややこしくなりそうな部分だったり、バグが出やすいだろうなぁって部分だったりになる。
このやり方には僕にとって欠点がある。
ひとつは、この設計図がある程度の規模を持ってしまうと、僕の記憶力では足りなくなる点である。
ある一点のイメージが出来上がると、そのイメージが元となって、そこから先の設計は必然的に決まってくる。まさに、デザインがデザインを作り上げていく状態。でも、このような状態になっても、いくつかの地点ではやっぱり、なんとなくつじつまが合ってないような匂いのするポイントがあって、そこにふっと意識を集中すると、元イメージがどっかに行ってしまう。また、つじつまが合ってないポイントが複数個所あると、１箇所考えているうちに、もう１箇所のことを忘れてしまう。
ということで、でっかいホワイトボードなりに、ごりごり書いていくことになるのだが、それでも、やっぱりわけがわからなくなってしまう。
論理的に少しでも考えてしまうと、途中までうまくいっても、それが壊れてしまい、最初からやり直しになるので注意する。
たぶん、ここがポイント。匂いがする部分ってのは、やっぱり論理的に考えたくなっちゃうところで、それをやっちゃうと記憶が飛んでしまうので、やり直しになってしまうんだと思う。
本音を言えば、どこかに書いてしまうのではなく、力いっぱい集中して、全部を記憶の中に入れて、うんうん考えた方が、最終的にはいいスタイルになることが多いんだけど、そこまで体力が続かない。
設計のあとに、あとはなんも考えないで、記憶の内容をそのままコードに落としていくだけの作業となる。ただ、どこかのメモを見ながらコードを書くことは難しい。結局覚えきれなかったことは、メモを見て、もう一度頭の中でイメージを作りなおして、コードに落とす。
集中しているときは忘れないので、一気にコードに落ちていくが、記憶力が足りないので、手を止めて、メモを読んで、あぁそんなこと考えてたわ、って頭の中で再構築せにゃならん。
全部覚えているときは、頭の中でステップ実行ができたりして、便利だぞ。
次の問題は、このやり方で集中して一気にコードを書くと、集中が途切れたときに、みーんな忘れてしまうこと。
あれ？俺こんなコードなんで書いたんだろう？いや確かにつじつまあってるけど、なんで？って頭の中がはてなマークでいっぱいになる。
これを避けるために、設計の内容を自分自身があとから思い出せるようにしておく必要がある。
このことは次の問題にもつながっていて、この設計の内容を未来の自分を含め、他人に伝えるのが非常に難しいこと。
最近は、一人でコードを書くというよりも、複数人でコードを書くことが多いので、頭の中で描いたイメージを他人に伝えなくてはならない。
他人に伝えているくらいなら自分で書いた方が早いんじゃないかと思うくらい、これを他人に伝えるのは面倒である。とくに、その匂いのするポイントなんてのは、もう、びっくりするくらい人には伝わらない。
人に伝えるときには、全体を一気に説明するわけにはいかないので、順番に説明することになるのだが、この順番ってのが曲者で、大雑把に説明しても伝わら] ]>