心がけるべきこと
たいていは、これらを実践することでパフォーマンスを向上／高レベルに維持し、みんなが楽になるでしょう。たぶん。
- Required
-
- DRY
(Don't repeatyourself)同じコードを2箇所以上に書くなよっ！ - テストファースト！
テストが失敗することを確認することなく実装に入るべからず - インタフェイスをよく考えろ
実装をしっかり隠蔽することで、リファクタリングが可能になる - 必ずtoString()を実装すべし！
正確にオブジェクト(クラスでなく)の内容、あるいはオブジェクトの要点を表現する文字列を返すこと。 - MapやSetのキーとして使用する可能性(ないと言い切れる？)があるなら、equals()とhashCode()を実装すること
- リファクタリングするタイミングはいつ？
今！割れ窓の法則を忘れるな - 1日1ビルド。
統合テストを含むビルドを実行して、明日もすっきり仕事しよう
- DRY
- Recommend
-
- デザインパターンを覚えよう。
つっても隅から隅まで覚える必要はなくて、何ていう名前のパターンがあって、だいたいどんなカンジのことやってるかくらいでいいよ。 - Listにセットする可能性があるなら(普通あるだろ)compareTo()を実装することを検討する
- assertで契約を実装することも検討してみよう
-
コード中にコメントを書くべきだと思ったら、たぶんコードが間違ってる。
コード自身が処理内容を物語るように実装しよう。
そういう風に実装していて、それでもコメントを書く必要を感じたら、How(どうやっているか)でなくWhat(何をやっているか)、Why(どうしてそうやっているのか)を書こう。 - 最適化は最後に考えよう。
Eclipseでの"遅延ロードルール"の実現のために採用されているProxyのことを思い出そう。
Eclipseでは、このシカケが有効に作用しているが、仮にEclipseの起動時に全プラグインをロードするのにたいしたコストはかからなかったとしたらどうだろう。
このシカケは単にムダなばかりでなく、プラグイン開発者に複雑な実装を強いる、ものすごく邪魔なものになるに違いない。
8:2の法則のことを思い出してみてもいい。
アプリケーションの実行コストの80%以上は、20%のコードが消費している。
ということは、計測もせずに行き当たりばったりで最適化しても、80%の確率で的を外すことになり、無駄に終わるだけ。
アプリケーションの実装が終わってから、きちんと計測して最適化を行えば、たった20%のコードの修正でコトは済む。
- デザインパターンを覚えよう。
