コードレビューのポイント

• 例外の握りつぶしがないか
  • catchブロックで発生した例外によってもとの例外が消えないか。
  • 例外を別の例外でラップする際、もとの例外を含めているか
  • e.printStacktrace がないか（コーディング規約などによって認められる場合を除く
  • ログに出力する、 e.addSuppressed など、発生した例外の情報が追えるようにしておく。
  • 握りつぶしても良い場合は握りつぶしても良いとする理由をコメントで明記する
• （特定の状況を除いて）変数の上書きがないか
  • 上書きしなければならない変数は通常カウンタぐらい。
• 早期リターンを適用可能な状況でブロックのネストをしていないか
  • if(isXXX) {} など if ブロックで処理している場合、 if(!isXXX){ return; } が適用できないか検討する。
• リソースのクローズ漏れがないか
  • InputStream/OutputStream等の Closeable/AutoCloseable は try-with-resources を積極的に利用する
  • 明示的にクローズしない場合はクローズするタイミングやクローズしない理由をコメントで明記する
• 過剰なチェック処理がはいっていないか
  • public メソッドの nullを許容する/しないなどは Javadoc に明記しておく。
  • return null; しているコードは極力 Empty を表す定数を返す（Optional#empty() や Collections#emptyList() とか)
  • return null が異常な状態なのであれば例外を投げる、またはステータスを表すクラスを戻り値とするなど。
• ライブラリなどで定義されている定数を活用しているか
  • HTTPステータスコードなど。
• IN/OUT系処理はバッファリングしているか
  • 生のInputStreamではなくBufferedInputStreamを利用する等
• 高頻度で出現する特定コードの適切なクラス化、ユーティリティ化がなされているか
  • 継承より委譲に基づいて原則的には委譲する。
• is - a にならない継承をしていないか
  • instance of のようなインスタンスによって分岐する処理が多いようならば適切な継承関係が保てていない可能性が高い
• コンストラクタでリソースのオープンしていないか。
  • コンストラクタでリソースオープンさせるのであればstaticファクトリメソッドなどを検討する。
• 定数は enum を適用できないか