今後記述したいと思う「sinProject流システム開発のススメ」項目

どうも、スィンです。 今後記述したいと思う「sinProject流システム開発のススメ」項目です。 今回は項目のみ列挙しておきます。 項目が増減したり「やっぱルール変える」という可能性もありますのであしからず。

全般

  • リファクタリングしなくて良いようにコードを記述する。
  • 管理しやすく保守しやすく不具合が発生しにくいコードにする。
  • コードクローンを作らない。コピーしたくなった時は「絶対にコピーせず」にメソッド化する。
  • 汎用ロジックはライブラリ化し、チーム、プロジェクトのみならず、団体など可能な限り広い範囲で利用する。
  • テスト駆動開発(TDD、テストファースト、テストドリブン)を行う。
  • メソッドはテストコード(Java:JUnit4)を原則準備する。
  • TDDで一般的な「動くものを作る>リファクタリングをする」というサイクルではなくはじめからリファクタリングする。
  • 2行以上のコードクローンを作成しない。
  • 1行でも単純でない条件式はメソッド化する。
  • コードブロックにコメントを書かない。書きたくなったらメソッド化するなどコメントを書かなくてわかるように変更する。
  • 想定しない条件式を先に記述する。(case defaultも)
  • 内部処理が違うものをオーバーロードで定義しない。
  • 一般的なロジックとシステム特有のロジックを分離する。
  • DBアクセス関連処理を分離する。
  • 2行以上のSQLは見やすく整形する。(A5SQL)
  • Overrideにドキュメンテーションコメントは書かない。
  • リクエストデータ、レスポンスデータなど、データカテゴリごとにデータ格納クラスを作成して用いる。
  • 開発環境:警告は全てなくす。(警告への意識が低下する。大切な警告を見失う。)

コーディングスタイル

  • コーディングスタイルはチーム、プロジェクト、団体で厳格化する。
  • 常に最新のコーディングサンプルを作って配布する。
  • 初期にコードレビューを必ず行う。
  • インデントはスペース4つ分のタブ。
  • 条件式は期待する値を左辺に書く。
  • メンバ変数名はアンダースコアで始める。
  • private でなくてはならないもの以外は原則public。
  • getter/setter を使わない。
  • カンマは行末ではなく前に書く。
  • 1行を複数行で記述する場合は、2行目以降は2つのインデント。
  • Java:変数名はCamel形式にする。
  • Java:定数は大文字とアンダースコアで形成する。
  • 変数や定数宣言の、変数名、及びイコールのインデントを揃える。
  • 数値リテラル、文字列リテラルは原則全て定数化するかenumにする。(定数にグループ性があるものはenumにする。
  • 変数名は原則省略表記しない。(初見の人、知らない人が変数の意味がわからないことで対応に時間が掛かる)
  • 判定用数値(コード)や判定用文字列で比較するのを避け、enumを活用する。(数値や文字列では引数や判定を厳格化できない)
  • if, for, while は1行でも中括弧(ブロックマーク)で囲う
  • ガード節を利用する。(インデントを深くしない)
  • if や三項演算子の結果を true や false と定義しないこと
  • class定義の下に空行を開けることを共通化する。
  • リターンするだけの条件式は1行で書く。
  • 条件ブロックの上下に空行を入れる。(条件の範囲が目視しやすくなる)
  • 終了ブロック「}」の後に else や catch などを書かずに改行する。(見やすさ改善)
  • ブロック末尾 return の上に空行を開ける。
  • return の中身が条件式などの場合いは、丸括弧で囲む。
  • 配列やListを返すメソッド名は「get~s」にする。
  • Java:Exception型をスローするメソッドを作成しない。(逆にテストケースは必ずExceptionを返すようにする)

その他

  • Eclipse:CheckStyle,FindBugs,PMDを活用。
  • クラスやメソッド、クラス変数にドキュメンテーションコメントを書く。
  • SQLのテーブルの別名を利用する場合は原則省略しないわかりやす名前にする。
  • 原則SQLで可能なことをプログラムで行わない。
  • DBアクセスにはEntityを利用する。(DBとの値の受け渡し、SQLの実行など)
  • Eclipse Java:Ctrl+Shift+Oで無駄なImportを削除する。
  • Java:serialVersionUIDを生成する。
  • 開発工数に余裕をもたせる(余裕がない場合は直近で時間のかから無いコピペコードが増えます。長いスパンで見ると工数が増えます)
  • リファクタリングは必要以上に行わなくていい。必要なときに必要な分だけ。
  • 未実装部分には「// TODO: コメント」を書く。
  • リファクタリングを進めていくのであればコーディング規約も平行して作っていく。(サンプルコードやCheckStyle定義を規約としてもよい)
  • 演算の優先順序を覚えるよりカッコを使う。
  • ワークスペースのパスをEclipseタイトルバーに表示する。
  • 暗黙知は悪。すべてルール化、ドキュメント化する。

Leave a comment

Your email address will not be published.

*

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)