いつもの

Java

いつもどうやってんの？と急に聞かれたので。自分で書いててどうかなと思ったりも。

全体

人間が考えやすい言語で脳に定着させて、それが揮発する前にコードに起こすのが一番速そう。

  1. 登場人物と、その役割を決める
  2. とりあえずインターフェースを書く
    • UMLでクラス図を描くよりなぜか速い *1
  3. 振る舞いを決めて、メソッドにする
    • 登場人物が役割をこなすために必要なものの最低限
  4. クラス図で印刷して、関係に矛盾がないか確認
    • 依存性を線でつないで、相互依存等がないか調べておく
  5. 勢いでJavadocを書く
    • 正常系は1行
    • 副作用は全部列挙
    • 異常系は全部列挙
  6. 勢いで全部の実装を書く
    • Javadocに書かれていないことは絶対にしない
    • バグっぽくても無視。あとでどうせテストする
    • 複雑なロジックはパッケージプライベートのstaticにおいだしておく
      • テスト性のため
      • Javadoc必須
  7. 勢いで全部の単体テストを書く
    • Javadocに書いた機能を全部テスト (多いときはJavadocを印刷してテストしてる)
    • 実装は全部忘れて、インターフェースに書いたJavadocの検算
  8. とりあえずコミット
    • 恥ずかしいコードなので、さっさと直したくなる
    • 別にコミットしなくてもいいけど、リファクタリング中にEclipseが飛んで残念なことになったので
  9. コードをきれいに
    • 人に見せて恥ずかしくない程度に

あんまりアジャイルな感じじゃないですね。さらに、「調べながら書く」時に上のやり方だとほぼ破綻します。

個々の

個別にやってるプラクティス

  • あとで書く
    • 複雑な処理がメソッドに含まれていたら、存在しないメソッド呼び出しに置き換えてあとで書く
    • あとで時間をかけて丁寧に実装すればいい
  • Javadoc以外のコメントをできるだけ書かない
    • コメントを書かなきゃいけない複雑さなら、privateメソッドに切り出しておけばいい
    • Eclipseのリファクタリング(メソッド抽出)は意外と秀逸
  • Javadocに書いていない前提を期待しない
  • コンパイラの警告オプションは強めに
    • 警告されたもののうち1%はバグ
    • 人間が確認するよりは安い
  • フェイルファスト
    • 引数が不正なら、メソッドの入り口で殺す
    • オブジェクトの状態が不正なら、不正になる直前に殺す
      • どちらもdebuggabiltyのため
  • toStringを書く
    • デバッガを使ったときに便利
    • デバッグ用途以外に絶対に使わない

Javadoc

ここまで来ると自分メモ。

  • 未チェック例外を@throwsで書く
    • ぬるぽとか。
    • テストしやすくなる
  • nullが絡む場合はすべて明記する
    • @param hoge 対象のHoge, 利用しない場合は{@code null}
    • @return 発見したFoo, そのようなFooが存在しない場合は{@code null}
  • Listを返す場合、その順序を明記
    • Collectionにしたほうがいい場合も

*1:たぶんツールの使い方がわかってない