2020.08.31
チーム開発する上でのコーディングルールを決めてみる

こんにちは。
プロダクト開発部 大場です。
今年の4月より新しいチームへ異動し、新たなプロダクトの開発を日々行なっております。
チームや携わるプロダクトが変わると、それに伴い変えなければいけないものもあると思います。
このブログを読んでいる方にも、
「インターネットで調べてみると様々な意見はあるものの、今のチームにおいてあのルール・方針ってどうなってんだろう?」
というような疑問を抱いたことありませんか?
その疑問の一つに、コーディングスタイルを含むコーディング規約(コーディングルール)があるのではないかと思います。
きっかけはレビュー時のやりとり
「チーム内でコーディング規約の認識をすりわせよう」という話になったのは、レビュー時のあるやりとりが発端でした。
そのやりとりが、
「if文と三項演算子の使い分けってどうしているか?」
という内容です。
自分がある既存コードをリファクタリングしていたのですが、リファクタリング最中に、
「ここif文でも書けるけど、可読性を考えると三項演算子を用いた方が良さそうだなぁ。」
「…そういえば、みんなどうしているんだろう?」
と思い、質問をしてみたわけです。
この質問の投げかけが、「チーム内でコーディング規約の認識をすりわせてみよう」のきっかけになりました。
ルールが決まっていると嬉しい
チーム内でコーディングルールが決まっていると、
- レビュー基準がチーム内で一定になる
- コード品質が保たれやすい
- コーディング時にコーディングスタイル周りで悩む機会が減る
など、嬉しいプラス要素があると思っています。
一方でルールが決まっていないと、個々の判断で実装やレビューを行うかと思います。
そうすると、「Aさんはこう言っていたのに、Bさんはああ言っている…」のような混乱が生まれることが考えられます。
こういうちょっとしたことって、皆さんはモヤモヤしたりしませんか?
なんかスッキリしないというか…
メンバー間での認識のズレや混乱があると、都度確認作業が発生したり、蓋を開けてみたらコードの品質がバラバラになったり…なんてことも考えられます。
これは嬉しい状態ではありませんね。
ルール化までの準備
ルールを決める前にGoogleスプレッドシートを利用して、まずはチーム全員から議題を集めてみました。
議題をあげる観点としては、
- 過去レビューにて指摘があった書き方のビフォー&アフター
- どう処理させれば良いかはわかるものの、書き方をどうすればいいのか悩むもの
- 「よく見るけど、こっちの書き方ほうがよくない?」的なもの
としました。
現在のチームではPHP・Laravelを利用していますが、PHPに限らずJavaScriptやLaravelのbladeテンプレート関連のものなど、分野は幅広く、各自2つ以上の議題をあげるようにしました。
自分も欲張って9個ほど出してみました(笑)。
チーム全体では結果的に32個(これは想定よりも沢山!)の議題が出てきました。
これで準備は万端です。
細かい粒度でルールを決めてみる
集めた議題は週1で行なっているチーム内での振返りのタイミングでしっかりと時間を確保。
一つずつ議論し決めていきました。
議論の中では、PSRに準じて決めたルールもあれば、
「変数名には基本省略単語を利用しないこと」や「PHPにて値の存在確認にはempty()を優先的に利用する」など、
本来自由にコーディングできる部分や細かい部分も、ある程度チーム内でのルールとしました。
議論自体は、現在在宅中心のリモートワークになっているので、Google Meetを利用し全員で意見交換をしました。
リモートワーク状態であっても、実際言葉を交わしながら意見交換ができたので、チーム全員が納得度の高い状態でルール化できたのではないかと思います。
もちろん、チームルールを決めても実際運用してみると気付くことも出てくると思いますので、その際はSlackなどを利用して都度メンバー間で意見交換をすることとし、柔軟さに対応していくように方針を決めました。
ルール決めをしてみて
正直なところ、細部にわたる話も多く、議題も30を超えていたので時間はそれなりに要しました(笑)
しかし、どの議題も具体的な内容ばかりだったので、直ぐに行動に移せるルールが整ったと思っています。
「どっちの書き方が良いのか…」
と、メンバー個々の悩みの種になっていたことも、チーム全員で意見を交わしながら進めたこともあり、合理的な理解を伴ってルール化できました。
また、モブプロをするよりも幅広くコーディング全体の話をチーム内でできたことも良かったです。
前述の通り、議論の時間は要したもののチームルールを決めたことにより、チーム内のコーディング方針が明確になったので、メンバー同士のコーディングルールの目線が合った状態で今後開発を進められそうです。
これでスムーズなメンバー間コミュニケーションやレビューができるようになるのではないかと期待しております。