ひとりごと - heppokoactの技術メモ

• だめコード集をつくる。
  • 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に入れておいた方がよさげ。