僕は事前に設計をしない、javadocを書かない

プログラミングをはじめる前に、ある程度設計してからはじめるかって言うと、私はそんなことはほとんどしない。最初に必要なのはイメージ。ユーザが何に困っていて、どうすればそれが解決するのか。それが、イメージできたらプログラミングをはじめる。
最初に考えるのは､最も高水準なインターフェース。Seasar2で最初に考えたのは､

public interface S2Container {

  Object getComponent(String name);

  Object getComponent(Class componentClass);

}

だったと思う。この2つのメソッドは､後で一個のメソッドになっちゃったけど。このメソッドを試してみるには､何が必要か。それを次に考える。考えついたら実装してみる。例えば､S2ContainerImpl.getComponent(String name)を実装してみる。nameで取ってくるのは､コンポーネントの定義だよね。だったらコンポーネント定義用のクラスと、コンポーネント定義を格納するMapが必要そうだと思いつく。こんな感じで､ゴールから出発して、「一歩次を考える」を考えるを繰り返していって完成させるのが私の開発スタイルだ。一歩次を考えたときのひらめきをできる限り早く実現したい、なぜなら直ぐに忘れてしまうかもしれないから。スピード感とリズムをいつも大事にしている。だから、少なくても開発中はjavadocは書かない。リズムが崩れてしまうから。
クラス名とメソッド名をみれば、何をやっているか直ぐに分かるようにすべきだ。ドキュメントを見ないと何をやっているか分からないクラスやメソッドは名前を見直すべきだ。名前を見れば何をやっているか分かるようになっているならjavadocは必要ないだろう。ソースコードにjavadoc以外のコメントを書くなんてもってのほかだ。コメントを見なければ分からないようなコードは書くべきではない。これが私の基本的な考え。
ただし、私は未熟者だ。クラス名やメソッド名を見ただけでは何をしているか分からないものもある。そういうものには、javadocをつけるべきだろうと思う。また、自分のポリシーとは無関係に、javadocが必要だという声が強いなら､それを提供すべきだと思う。だから、今日からjavadocを書き始めた。
javadocチームのおかげで､わかりやすいjavadocがframework.containerに対して提供されている。S2Containerの詳細な実装以外は、ここのjavadocを見れば分かると思う。javadocチームに感謝したい。