チーム開発におけるコードクオリティの確保

仕事でチーム開発におけるソフトウェア品質の保ち方みたいな議論をすることがあり、そのために準備していたメモ。
個人のメモです。

前提

• SIerと呼ばれる組織でのできごと。
• エンジニアは大半が外部リソースとして、テンポラリなリソース。
• 一部にリードエンジニアがいるが、そのリソースだけでは全てをまかなえない。
• ある意味2019年4月時点では日本の SIer の開発スタイル（ベンダーコントロールが主で、デベロッパーは調達するという考え方）としては結構スタンダード

基本方針

どんな言語であれ意識すべき内容。

• 読み物として読めるように記載する（要はイケてるかどうか）。
• 文脈、リズムを大切に。
• 仕様の日本語をそのまま言語としてかかない（アホみたいに日本語をそのままプログラミングする人たちがいる）。
• 半年後（関係がなくなってから）の自分が読めるかどうかを振り返る。
• より一般性（標準性）の高い方を採用する。外れる場合は理由を明確に。
• 処理数が最小になるように（分岐条件の順番、処理の順序など）。
  • 発生確率が高いものから記載するなど
• 同じ内容は同じように記載する。書き方にパターンを持たない。
• コードの内容を単に日本語にした内容はコメントに記載しない。コメントには仕様およびその理由を記載する。
• 障害発生時など緊迫した場面でも読み間違いがないように配慮する（否定での if 条件など）。
• 命名は英語を用いる。ただし、英語での厳密性よりも一般性が高い（理解性、浸透性）方採用する（和製英語、ドイツ語など流通次第）。
• ディスクアクセス、通信処理などは繰り返し処理では行わない。
• EoDを意識する
• テスタビリティを意識する。
  • メソッドを適切に分離するのは当たり前で、テスタビリティのために意識する。
• 役割を最小化する。
• アーキテクチャスタイルを守る
  • レイヤードアーキテクチャなのであれば、依存関係の仕方はまもるなど

Javaにおける考え方

• 世の中のコーディング規約に準拠する。
• Nullsafe を強く意識する。
• Method chaining を使う場合は、NonNULLであることが保証されている場合のみに限定する。
• コードの内容を単に日本語にした内容はコメントに記載しない。コメントには仕様およびその理由を記載する。
• lamdba式は節度を持って使う。処理速度やロギングを考慮するとlamdbaでない方が望ましい場合もある。
  • コードを1行にすることが目的ではない。読みやすくなければ意味がない。
  • 中間処理の経過表示のためなど、適切なログ出力がstreamなどはできない場合もある
• 文脈を持つのはService以上。DAOはアクセッサなので文脈をもたない処理に徹する。ただし集積度は考慮する。