Skip to content

開発規約

Jump to bottom
suzukitakashi edited this page Sep 12, 2021 · 14 revisions

Overview

チームでシステムを開発する上で、みんなの共通認識としたい規約や基準など。
開発標準を定めておくことで、システム全体での統一感を生み出し、開発しやすさ、保守のしやすさを実現してくれます。

目次

・アプリケーションのレイヤーについて

・例外について

・ログについて

・アプリケーション内定数について

・データベースについて

・コミットについて

・テストについて

・JAVADOCについて

アプリケーションのレイヤーについて

  • view　⇒　controller　⇒　service　⇒（logic）⇒　repository　⇒　DB
    • この矢印の流れを守ってください。例えば、logicからservice、controllerからrepositoryを呼ばないなど。
    • commonから個別機能を呼ばない。zから他のアプリを呼ばない。

例外について

  • 例外はGlobalControllAdviceにて全体で例外を拾うようにしています。(com\portal\z\common\controller)
    なので、原則として個々のクラス内で例外を拾う処理は記述しなくても大丈夫です。
    業務的に必要がある場合のみ、記述してください。

ログについて

  • ログはAspectにて、メソッドの開始と終了時に統一して出力するようにしています。(com\portal\z\common\aspect)
  • 必要に応じてSlf4jを使ってログを出力してください。

アプリケーション内定数について

  • ログイン失敗回数の最大値など、アプリケーションで使う定数については、
    「環境マスタ」でデータとして持つようにしています。
    定数を使いたいときは、できるだけコード内に直書きせず、環境マスタの使用を検討してください。
  • 指定した環境ＩＤに対する環境値が数字の時は、selectIntOneを使うようにしてください。
例）環境ＩＤ「PASS_UPDATE_NXT」が数字しかとらない時
  Env env = envService.selectIntOne("PASS_UPDATE_NXT");
  if (env != null ) {
    PASS_UPDATE_NXT = Integer.parseInt(env.getEnv_txt());
  }
  ⇒仮にselectOneを使うとしたら、環境値の値が数字かどうか確認する必要があるので、その部分を共通化した形となります。

データベースについて

コミットについて

テストについて

JAVADOCについて

実装をしたらJAVADOCを書きましょう 勉強会では以下のルールでお願いします。

  1. クラスとパプリックなメソッドには必ずつける。
  2. @paramと@returnは必ず設定する
  3. 最初にそのクラス（メソッド）の概要をかく
  4. 注意事項があれば2行目以降に書く（nullの扱い、間違えそうなtrue/falseの判定など）

⇒（出力方法）　https://techacademy.jp/magazine/24269
⇒（参考）https://www.aiosl-tec.co.jp/java/247/
⇒文字化けするとき：https://pecoegg.com/website-134.html

Clone this wiki locally