テスト先に書きたい若者よ

弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた．
個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく．
僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う．
紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数を受け取って，こういうときにはこういうものを返す，こういうとき例外を投げます，みたいなのをひと通り書いていく．それで書いてると辻褄が合わなくなったりする．こういう変なときは誰がどこで止めてくれるのか，例外が出るのか，メッセージが出るのか，その間にこうなったときは，とか，考えることはいろいろある．
そこまで考えたら文章にまとめてチームメンバーに見てもらってもいい．そこで他人が見たら変なことが分かったり，いいじゃんってなるとか，一人で見るのと，二人で見るのは全然違う．
図とか，文章の上でじっくり考えて，うまくいきそうになってから，ようやくテストを書いたり，実装を始めたりするのがよいと思う．
一方で，オブジェクト指向入門という本を読むと，UMLとか，モデリングツールなどは要らなくて，地続きにコンパイラの支援を受けながらクラスの契約の設計から実装までなめらかに記述していくことができると述べられていてかっこいい．Perlにはそういうパラダイムはないので，早くそういう時代になってほしい．

おすすめノートです

ロディアのA5のノートずっと使ってて，なんか妙に高いんだけど，紙の感じとか，書いた雰囲気は最高で，方眼がついてて，クラス図とか書きやすい．使うだけで喜びを得られる．素敵なアイデアなのにしょぼい紙に書くのはさみしいのでいいツールを使うほうがたのしくてよいと思う．

ロディア ダブルリングノート A5 クラシック 方眼罫 ブラック cf193429

おすすめ本です

コード書く人はオブジェクト指向入門まず読むべきだと思う．この本から始めてもいいくらいで，今でも役立ってる．

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング)

追記

はてブ見たら，こんなことは何十年も前からやってると言ってる人がいた．

id:takhasegawa
？？ 紙に仕様を書きましょう、他の人にチェックしてもらいましょう、それから実装しましょう。いわゆるSIerが何十年も前からやってることに今更？？

http://b.hatena.ne.jp/entry/217818105/comment/takhasegawa

冒頭の若者っていうのはインターンに来ている学生で，この記事は学生向けの記事でした．
うまくTDDできないっていう悩みは分かるけど，まずは基礎的なことを着実にできるようになってもらうのが重要と思って，こういう記事を書きました．
大学の演習などではクラスがたくさん出てくるソフトウェアを設計してテストも書こうということはあまりない気がするので，実際に企業でコード書いてる人が伝えられる，役立つ方法論などがあれば学んで帰ってもらえればうれしいと思う．
何十年も前からある古いアドバイスじゃない最新の優れたアドバイスあったらください．