対象のユーザ
- チーム開発をしている人
- チーム開発に悩んでる人
- レガシーコードをなんとかしたい人
- コード全体を一気にリプレイスできない人
はじめに
今プラハという会社でPRANETというエンジニアのSNSを開発しているrevenue-hackです。
PRANETはフロントにVue.js, Nuxt, バックエンドにTypeScript, Express, DBにNeo4j, Cloud Firestoreを採用しています。
課題について
- コードを書く場所が人によってバラバラ
- 変数名やカプセル化の加減が人によって違う
- PRで一度議論が起きたことが他のPRでも起きていて、チーム全体の認識が合わない
このようなことが起きていて、チームの開発スピードが一向に上がらないという問題が起きていました。
どのように解決したか？
弊社ではPR道場というものを取り入れました。
PR道場とは
- 誰かのPRで起きた議論は他のPRでも起きていく可能性が高い
- どこに書くべきか、どう書くべきか人によって意見が分かれる
そういったものを解決するために弊社で週1で行っている提案会議です。
ではPR道場での実例を2つほど紹介します。
コミットメッセージに関する提案
(課題) resolve conflictした時、どこを修正したのかわからない
(提案)
・’resolve conflict’ってコミット名は禁止
・fix:の記法に沿って、どこを修正したのか記載する
背景として最近conflict修正を失敗してバグを生んでいたため、コミットメッセージでどの部分のconflictがおかしくなっていたのか追えなくなっていました。
そこでコミットメッセージを正すことで、conflictの変更もコミットメッセージからわかるようにしました。
こういったライトなものでも共通認識を持つことで、問題解決につながっていきます。
エラーハンドリングの方法について
また実装レベルの提案だとエラーハンドリングの仕方についての提案です。
Repository層でfindしてDBからリソースが取得できなかったときはundefinedを返す（エラーを返すのではなく）
・配列は空配列を返す
・SettingRepoImplでユーザの設定が取得できないときにエラーを吐いていた
・Repoではundefinedを返して、ルーター辺りでhttp response errorを作るように変えた
・理由
・404なのか500なのか区別つかない
・異なるハンドリングされる可能性のあるエラーには気をつける（404と500）
エラーハンドリングは1つ必ず決まった正解があるわけではなく、チーム単位やプロジェクト単位また個人単位でも異なってきて、処理の方法に差が出る部分です。
その部分をチームで提案という周知することで、コードの品質を担保することができます。
また今回のケースでは議論が発展し、404や500だけでなく400のケースもチェックするべきではないか？その場合はどのように処理するのが良いか？
など更に深ぼった話に発展し、結果的にRepository層では400, 500, 404のエラーを区別できるようにエラーclassを作り、それをthrowするようにしました。
この提案でチーム全体のコード規約を決めることができ、また提案の背景を知ることで個々の設計力や、コーディング力が上がってきました。
PR道場(改)
ただPR道場をやっていて一点課題が出てきました。
それはPR道場をやっていると設計に詳しい人やTypeScriptやVueに詳しい人など、喋る人が偏っていて、
これだと結局話さない人がどの程度理解しているかわかりません。
そこで、PR道場で出されたお題を、出した人以外の人が話すことにしました。
メリットとしては
- 発言者が偏らないことで、全体の周知度が見えやすくなる
- 理解していない人がなにが理解できていないのかはっきりわかるようになる
- 誰が読んでも説明できるぐらい後世に伝えやすい形で残るドキュメントが残る
があります。
こうすることでコード規約の決め事の場から、全員が理解してコードを書けるよう成長する場にすることができました。
まとめ
今回チーム開発を改良したことで良かったこととして、
- 全体としてのコードを書く上での共通認識がある程度固まった
- (どうしてこの提案をしたのか背景を知ることで)チーム全体の設計力が上がった
- 共通認識を作ったことでPRレビュー時の意見割れが減りPRレビューが開発スピードのボトルネックになりにくくなった
です。
是非チームで取り入れて、チーム全体の開発力向上につながれば良いなと思います。