実録！私のプログラミングスタイル

抽象化が手抜き云々の話をしていて思ったのが、実は自転車に例えたり、オーバーアクションにいまどきの若者プログラマの主張を訴えたりする前に、もっとコンクリートに プログラマの――私のプログラミングスタイルを説明して置いた方がよさそう、と言うことでした。

せっかくだから、書きつづってみたモノの、うーん、なんだかなんとも、ねぇ？

* * *

私がコーディングするときを思い浮かべると、まずホワイトボードにざっとアイデアを書きます。これから作るプログラムの構造のスケッチを描いて、自分の考えをまとめます。

で、それを他のプログラマの誰かをひっぱりこんで「ね、ね、これどう？どう？」とレビューして うざがられ(w、で問題がなければ、即コードを書き始めます。（テストから書け！と、たまに 同僚に怒られます^^;）

コードはいきなり完成系を書くわけではなく（あたしはそんなに凄かないよ）、取りあえず先ほどのスケッチを思い浮かべながらババッと形を書きます。それを、あーでもない、こーでもない、あ、これはいけない、とか独り言をブツブツ口走りながら、一度書いたコードをこねくり回して、変形させます。（粘土細工をつくるのと感覚的によく似てます。）

で、だいたい満足がいった時点で「ぃよしっ!(Xtal風)」と言って取りあえず終了。（この時点では、細かいメソッドとか、全体の構造に影響しそうなのはあんまり揃えていない）

で、それに対するテストをバリバリ書いていきます。テストを書くのと同時に、コメントを整え、インターフェイスの乱れを直し、未実装だった細かいメソッドを実装していきます。

で、テスト終わったらコーディング終了。コードレビュワーにコードを渡して、レビュー待ち。その間に設計の要点を開発Wiki にちょこちょこ書いて、で、レビュー完了とともにコミット。これにて作業終了です。

* * *

私にとってはこの手順が一番楽です。（なんか「これはひどい」とか付けられてしまいそうな気もする^^;）

プライベートでプログラミングするときは、ホワイトボードフェーズすっ飛ばしていきなりコード書き始めるし、レビューフェイズもないのでもっと粘土っぽい作り方をしています。

あたしにとってのコーディングは、Just in time なリファクタリングと区別つかない。プログラミング行為そのものが設計行為だと私は思っていて、だからこそコードによって「見える化」される、その見える力を糧に設計そのものを修正していく。

建築のことはわからないのだけれど、設計図を書くってことは、頭の中の完璧な設計をプリントアウトすることじゃなくって、設計を「見える化」しつつ詰めていく作業だと思います。で、プログラムにとってコードは設計図です、と そう言うこと。

私のプログラミングスタイルが粘土コネコネ風味なこんな感じだから、

>「設計しなくっちゃ、抽象化しなくっちゃなんて」意識せずとも、

はそうですが、「どのように抽象化するか（＝設計）」ということは、
ひと手間掛けて、考慮しているのではないでしょうか。
（このひと手間を、先のコメントで設計のコストと表現しました。）
初心者にとっては、抽象化を学習するのに加え、
このひと手間も面倒なんでしょう。

というコメントを頂いたとき、結構違和感を感じました。が、私が初心者だったときはどうだったかなぁ....。

えっと、思い出します。...たぶん、最初は箇条書き設計を教わった気がします。あと師匠の勝手に構造化を考えてしまえるコメントスタイル！ ・・・で、コメントで目論んでいたことと実コードの折り合いがつかなくって、相変わらずコネコネしていたような記憶が。

コネコネは、たしかにコストが掛かっていたけれど、コネコネ愉しいので「コネコネめんどーい！、もう、動けばいいじゃん！」なぁんて、全然おもわなかったなぁ。