感覚か、論理か

大本はきっちり読み込んでないのですが、要は「論理的というよりは、感覚的に取り組んだほうが生産性が高くバグも少ないソフトウエアを書ける人もいる。」といった話と理解しました。確かにそういう人もいるでしょうね。私が知っている天才的プログラマの方もそんな感じでした。

で、以下は大本のエントリとはあまり関係なく、チームでのシステム開発における、感覚と論理の話。

↓chikuraさんに同意します。もっとも重要なのはお客さまと意思を共有するということ。要求や仕様のコンセンサスを得るときに、感覚と雰囲気「だけで」進めると後でヤバイ。(もちろん、感覚や雰囲気もプロジェクトには重要な要素)

顧客が存在し、チームが存在するような開発では、自らの思考を「ソースコードに落とす前に」文章化し、説明し、共有する必要が発生する。「感覚的に」物事を進められるのには限界があるのだ。

↓我が意を得たり。一本のプログラムにせよ一つの機能にせよユースケースにせよ、目的は重要。例えるなら太ーい幹。これを頭の真ん中にどーんと置いて、枝葉に迷ったら立ち戻る。抽象的だけどそんな感じ。

世の中では、プログラミングをする時には「まずロジックを組み立ててからプログラミングに入れ」と言われる事が多い。具体的には、一度フローチャートを書いたり、何でもいいから図に書いて、入力と出力を定義して…というような作業が必要だというのだ。しかし、実際には細部にこだわりすぎると物事の本質を見落とすことが多い。ロジックはあくまで「手段」であり、目的ではないからだ。あまりロジックに気を取られすぎず、目的や機能ベースで全体像をくみ上げてから、細部に入るという手法が、ある程度の大きさの(ほとんどの)プロジェクトにおいて効果を発揮するだろう。但しその場合においてもロジックが全く不要というわけではない。「全体(目的)」と「詳細(手段)」には区切りがあるわけではなく、太極図における陰と陽のように、溶け合いながらもぐるぐると回っているようなものだ。全体を考えたら少し詳細に入り、また全体に…というような感じで、どちらか一方に偏り過ぎないことが肝心だと思う。