こんにちは
エンジニアの Ikemi です。

homie では、ソースコードの管理にGitHubを使用し、Gitlab-flowに沿って開発しています。

PRレビューから学べることは多いと思います。
そこで今回は、私がPRレビューから学んだことをご紹介したいと思います。

homieのPRがどんなものか気になっている方も、ぜひ読んでみてください。

1. コード設計

まずはこちら。
csv ファイルアップロード機能の、バックエンドAPIのPRです。

これは、入力されたCSVに関する処理をバックエンドのServiceに記述していたため、コメントをもらったものです。
バックエンドの設計に関するドキュメントは読んでいましたが、分かっていたようで実装はできていませんでした。

コード設計は、具体的な例がないと理解しにくい場合もあるかと思いますが、PR レビューだと実際のコードがあるので理解しやすいです。
結果的に、入力されたCSVの処理をControllerに移動することで、適切に責務を分けることができました。

このPR以外にも設計に関するコメントはもらっています。
homieに入社して、自社プロダクト設計の理解だけでなく、エンジニアとして普遍的な設計力も少し増したと思います。

ちなみに、homieのバックエンドは DDD を意識した設計になっています。
私は、homie に参加して初めて DDD を触り、少し理解できるようになりました。

2. 機能要件だけでなく、使い勝手も考える

ここでは、2つ紹介したいと思います。

1つ目は、フロントエンドで表示項目切替フィルターを実装した時のPRです。

機能要件は満たしていました。
ただ、このままだと使う側が画面遷移するたびに毎回切り替える必要があり手間になりそう、というコメントをもらいました。
確かに、機能要件だけに目が行きがちで、使い勝手の良さには目が行きませんでした。
改善策として、切り替え機能を全画面共通で1つにしました。
結果的に、利便性も向上し、実装工数も少なくなりました。

2つ目は、最初に紹介したcsv ファイルアップロード機能のPRです。

ヘッダー記載済みのフォーマット DL 機能があると便利かも、というコメントです。
csvのヘッダー項目はドキュメントに残して共有しようと思っていましたが、フォーマットDLがあると、フォーマットをそのまま使えるので確かに便利だと思いました。
また、フォーマットDL機能があることで、デバッグがしやすくなりました。

使いやすい仕様にすることで、利便性の向上だけでなく、工数の削減も可能な場合があることを学びました。

3. あえてやらなかったことをコメントに残す

メール本文から正規表現で情報を取得する際のコメント。

いろいろ悩んで試行錯誤した末に、結局実装しなかったコードはあると思います。
そういうのをコメントして残しておくことで、他の人も同じように悩まなくて済みます。
今までは複雑な処理の補足としてコメントを書いていましたが、こんな視点もあるんだと知りました。

この場合は暫定的な仕様のため、多くの工数を割くことができないので、実装せずコメントで捕捉しました。

まとめ

PR レビューでは、各個人の考え方や思考体系が見えるので面白いですね。 
ここで紹介したのは一部で、他にも参考になった PR はたくさんあります。

homie では コード(DDD)設計、単体テスト、より良いコード(変数名、関数名、処理の関数化、アーリーリターン、etc..)をレビューで確認しており、上記が満たされないものは approve されません。

今回は PR だけの紹介になりましたが、slack や esa、対面での会話でも技術的なやりとりはしますし、そこでも様々なアドバイスをもらうことができます。

homieのエンジニアリングに興味をお持ちの方は、ぜひ一度、お問い合わせください。