heppokoactの技術メモ ひとりごと

※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

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