「ひとりごと」の編集履歴（バックアップ）一覧に戻る

ひとりごと - (2009/12/01 (火) 13:53:06) のソース

-だめコード集をつくる。
-プロジェクトの終了条件を明確にする。
-一括は成果物責任。過程に口を出されるならSES。
-例外処理基準が必要。
--日付のパース例外やnewInstanceしたときの例外などはPGが処理に困るだろう。
--e.printStackTrace()禁止。チェッカーを作れ！
-ログ出力基準が必要。
--例外処理時とデバッグ用のログ。
--ToStringBuilder#reflectionToString()を活用。
-assertしまくって規約違反をすべて例外に！
-ActionとServiceの分け方
--Action
---データベースに依存しないチェック
--Service
---データベースに依存するチェック
-一括更新で1件1件ロールバックおよびコミットをする場合、件数が多くなりすぎないかどうかに気をつける。
-セッション中のデータのライフサイクルを図にする。
--できればフレームワーク側で対応する。
-「機能」とは何かを定義する必要がある。
--でないと…
---機能の粒度がまちまちになる。
---機能IDを振る時に一貫性のない機能IDになる。
---など。
--帳票なら出力された帳票が機能なのか、帳票を作成する過程を含めて機能なのか。
--各機能のサブ機能はどのように表現すればよいのか。
-命名規約
--booleanはtrue/falseの意味が明確にならないような命名を避ける。
---だめな例…check（trueがチェックOKなのかfalseがチェックOKなのかわからない）
---良い例…isValid
---isやhasで始めるとよいかも。