これはフェンリル デザインとテクノロジー Advent Calendar2024 19日目の記事です。
はじめに
新卒2年目でWebエンジニアをしているせーです。
先日アサインされた新規プロジェクトで、開発するにあたって必要なルールやワークフローを考える機会がありました。そこで考えたことや意識したことをまとめようと思います。
正解はない
プロジェクトによって要素や前提が異なるため、絶対的な正解はないことを認識する必要があります。下記のようにプロジェクトによって変動する要素は様々です。
- 規模
- 開発メンバーのバックグラウンド
- 利用する技術
- 予算
- 社内ルール
などなど
プログラミング界隈では「シルバーバレットはない」という言葉があります。開発ルールにもそれが当てはまり、どのプロジェクトにも適用できるルールというものはありません。
そのため、プロジェクトの特性を理解してそれに適するルールやワークフローを選択する必要があります。
どこまで厳格に定めるか
ルールを定めなければプロジェクトが無秩序になり、後から見返した時や新しいメンバーがジョインした時にわかりづらくなります。
とはいえ、ルールをガチガチに定めてしまうと開発がしづらくなる、ストレスが溜まるといったデメリットがあるため、どこまでルールを厳格に定めるかも考える必要があります。
そのため良い塩梅でルールを定めるのが望ましいですが、最初から「こうすれば良い！」と決め切るのは簡単ではありません。開発を進める中でルールの取捨選択をするのも選択肢の一つだと思います。
開発ルールに正解はなく、プロジェクトが成熟するにつれて最適なものが変化していくため柔軟に対応していく必要があります。
課題を起票するためのテンプレートを作成するケースもありますが、何を書けば良いかがわかりやすくなる一方で、テンプレートに書いてあることしか書かなくなり、伝えるべき情報が抜け落ちてしまう懸念もあるため、その点を考慮してテンプレートを利用するかを決めましょう。
開発時のルール
ブランチ
ブランチ戦略については以下のようにいくつか有名なフローが存在します。
ブランチ名に関してどのようにするのが良いか調査したところ、ケバブケースを採用している場合やスネークケースを採用している場合などサイトによって様々だったため、プロジェクトに応じて決めるのが良いでしょう。
また、実装する機能の概要ではなくGitHubなどのissue番号をブランチ名とする手法もありますが、その手法を採用する場合そのツールに依存してしまい、レポジトリを移行した時などに紐付けができなくなるというデメリットがあるため、その点も考慮して選定する必要があります。
git style guideというスタイルガイドがあるため、こちらを参考にしても良いかもしれません。
コミット
コミットメッセージ規約としてConventional Commitsがあり、基本的にはこの規約に従うのが良いと思います。この規約に従うことによってプレフィックスによるサーチが簡単になり、プロジェクトメンバーがコミットを見やすくなるといったメリットがあります。
また、それに加えてプロジェクト独自のワードはなるべく利用しないことをおすすめします。プロジェクト独自のワードを利用すると新しくジョインしたメンバーが読みづらく、将来コードを読む際にどのような意味かわからず、メンテナンスコストが上がってしまうということにもなりかねないため、プロジェクト独自のワードではなく一般的に知られているワードを利用することが望ましいです。
プルリクエスト
プルリクエストに関してはプロジェクトや会社のお作法に従うのが良いですが、少なくともブランチの保護ルールは設けた方が良いでしょう。
（例: 1人以上のapproveがないとマージできない、メインのブランチに直接プッシュできないなど）
間違えてメインのブランチにマージしてしまい、そのままCDが動いて正しくないコードが本番環境にデプロイされるなんてことになったら悲惨ですからね。
コードレビューに関してはGoogleのコードレビュー規則を読んでレビューをすることをおすすめします。
命名規則
命名については各言語によってよしとされるものが違うため、各言語の標準に従うのが良いでしょう。
（例: goのパッケージ名であれば小文字の単語1つなど）
ツールについて
利用するツールに関しては、個人的にそこまで厳しい制約は設けなくても良いと思いますが、レビューの負担軽減やコードの品質保証のために最低限formatterとlinterを利用することを推奨します。
各々好きなツールがあると思うので、「可能な限りそれを使ってほしい！」と個人的に思っています。好きなツールを利用することでモチベーションアップや開発効率向上にも繋がるため、できる限り個人が利用したいツールを利用するのが良いでしょう。
全体を通して
全体を通して以下を意識しました。
- ベストプラクティスがあるものは基本的にベストプラクティスに従う
- ベストプラクティスが相応しくないものは、理由を持って別の方法を選択する
ベストプラクティスには理由があって、ベストプラクティスとして定められているため、公式で定められている場合はそれらを利用するようにします。
ただし、プロジェクトによってはベストプラクティスが適さない場合もあるため、その際はなぜ利用しないか、なぜ別の方法を採用したかの理由を持って別の方法を選択するようにします。
実際やってみないとわからない
結局はこれにつきます。
「これでよし！」と思ってルールを定めたとしても、実際にやってみると「これ不便になるだけじゃない？」や「もっとこういうルールあった方が便利でしょ」と思うことがいくつも出てくると思います。
開発を始めた後にルールを変更しても良いですし、最初は割り切ってこの期間は実際にやってみて、ルールはその後に決めるとしても良いかもしれません。
どのような方法でもプロジェクトで話し合って、理由を持って決定したなら問題はないと思います。
おわりに
開発ルールによって開発やプロジェクト管理のしやすさがかなり変わってきます。整備するのは大変ですが、整備することによって得られる恩恵も大きいため、開発ルールは定めることをお勧めします。
開発ルールを考えるにあたって、様々な情報を調査しましたが、実際にやってみないとわからないことも多々あったため、これから経験を積む中で色々な方法を模索していきたいと思います。