「ひとりごと」の編集履歴（バックアップ）一覧はこちら

「ひとりごと」(2009/12/03 (木) 20:28:46) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

-だめコード集をつくる。
--JSPで案外DRY原則が守られないかも
-プロジェクトの終了条件を明確にする。
-一括は成果物責任。過程に口を出されるなら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で始めるとよいかも。
--クラス名やファイル名で各画面固有のものは「画面ID + 機能名」にした方が管理しやすい。
-HTML
--1行当たりの高さを決めておく。
---ラベルと入力項目の高さが異なるとめんどう。
--右寄せ、左寄せを決めておく。
---おもに数値と日付が問題になる。
---中央寄せにする項目があるかどうかも問題。
--上寄せ、中寄せ、下寄せを決めておく。
---DIVだと中寄せは辛い。

-だめコード集をつくる。
--JSPで案外DRY原則が守られないかも
-プロジェクトの終了条件を明確にする。
-一括は成果物責任。過程に口を出されるなら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で始めるとよいかも。
--クラス名やファイル名で各画面固有のものは「画面ID + 機能名」にした方が管理しやすい。
-HTML
--1行当たりの高さを決めておく。
---ラベルと入力項目の高さが異なるとめんどう。
--右寄せ、左寄せを決めておく。
---おもに数値と日付が問題になる。
---中央寄せにする項目があるかどうかも問題。
--上寄せ、中寄せ、下寄せを決めておく。
---DIVだと中寄せは辛い。
-更新日付をDBからAPに持ってきてDBにINSERT、UPDATEする場合はThreadLocalに入れておいた方がよさげ。