非効率な仕事の進め方とルール化について(オートフォーマット編)

背景

最近ちょっとだけバックエンド開発の仕事をやらせてもらっている。 当然その分野の先輩がいるわけで、その人たちの書いたコードを修正したり追加したりするのが多い。

IntelliJを使ってPHPを書いているのだけども、オートフォーマットをしてPRを出すと細々とコメントがつくことが何度かあった。 私はREADMEに書いてあるルールに従ってIntelliJのオートフォーマッタを設定して修正しているだけなんだが、ここはこうした方が良いとか、最近の運用ではこうなっている、とか細々としたコメントが大量につく。 「クラス定義の後ろの "{" の前は改行しよう」とか「いや、ここは今はもうそのルールは古い」とか。そんなくらいの話。

問題点

おかしいな?と思ってヒアリングすると幾つかの問題がチームにあることがわかった。

  • READMEの記述が古い
    • 古いコードに引きずられてルールが作られていて、すでに誰も見ていない。新しく入った人だけがそれを見て振り回される。
  • 昔のコードをフォーマットするかしないかで意見が統一されていない
    • 自動フォーマッタを入れている人は修正を出すが、そうでない人も多い。ボーイスカウトルールとは(来た時より出る時には綺麗にしましょう)
  • 温かみのあるコミット分割
    • ある人は新規で追加した部分はフォーマッタかけるが、ファイル全体に修正がPRに出るといやなので、git add -pなどを用いて自分の変更箇所だけコミットするなどしていた。温かみ運用。毎回手動でやっているのか・・・

修正

私の提案

  • 形がい化したルールを削除(READMEに書いてあることは正しいものとする)
  • PRで議論をして満足するな。議論して決まったことは同じことを繰り返さずREADMEに明記すること。書いていないルールはそのPRを通す通さないには関係してはならない。直したければ別PRとして修正すること。
  • オートフォーマッタ設定の方法もかく。会社でライセンス買っていて大体みんなIntelliJ使っているのでその設定方法の明記。vim使っている人は従ってもらい同等のものを入れてもらう
  • 古いファイルもまずオートフォーマットしてそのコミットを分ける。必要に応じてPRも分ける。実作業と分けた方が良い(緩やかなルール)

できなかったこと

  • editorconfig などでルールの自動読み込み
    • すでにあるエディタ設定が優先だったし、PSRなど包括的なルールで設定できなさそうだった。これは知見が足りないだけかもしれない。

終わりに

上の提案はあくまで提案で、そのような内容をREADMEにかくPRを出してマージされた段階。 そのあとの運用はまた回してみて問題が出れば修正。

とにかく「繰り返しの無駄な議論」「細かすぎる指摘によるマージブロック」「温かみのある手作業」 こういうのをなくしていかなければならない。