Zenn
👥

1人チーム開発ごっこを完走した感想

2023/05/07に公開
Git
GitHub
個人開発
idea

背景

あるとき、ちょっとした思いつきと、コーディング力のさらなる上達のため、このような Web App を作りました。

JPEG 画像の最適化処理ができる Web アプリです。バックエンドのフレームワークは FastAPI、最適化処理は mozjpeg を使用しています。フロントエンドはフレームワーク無し (プレーンコードのみ) です。

UI はこんな感じ。

Demo

この Web アプリ作りにおいて、1人チーム開発ごっこをやってみた、その感想です。

1人チーム開発ごっこって？

(これは僕オリジナルの用語)

1人での開発だけど、チーム開発っぽくソース管理をする、というものです。今回は以下のようなルールで開発を進めました。

  • Git Flow (+アレンジ) に従ってブランチを切って管理する
    • Git Flow 解説はたくさん出回っているので省略
  • ブランチのマージは Pull Request を通して行う
    • レビュワーは自分だけ、デプロイテストも用意していないけど･･･
  • 各モジュールに対応するテストプログラムを作る
    • JavaScript、Python のモジュールをテスト
  • ある程度まとまった機能を実装できたらバージョンを付けて release 作成
    • develop から main へマージし、main からタグをつける

ブランチの形態はこの記事にまとめました。

開発の目的

目的の 1つはコーディング力の上達 (上述) ですが、そこに加えてブランチ管理の体験も目的としていました。

Git Flow とかブランチモデルについて調べたことは何度かあったのですが、実際にそれを運用したことはありませんでした (1人開発で運用と言えるか微妙だけど･･･)。やらないと分からない感触もありますから、その体験をしてみたかったのです。

そんな「1人チーム開発ごっこ」を実際にやってみて、感じたことを綴ります。

うまくいった点

テスト済みの安心感

機能ごとにコードを分割できる箇所はモジュール化し、各モジュールに対するテストプログラムを作成し、単体テスト (ユニットテストとも) を行いました。これにより、全コードのうちここは確実に動く、ということを保証できます。

単体テストはいいぞ！という記事を別に書いてありますので、あわせて是非。

メインへの実装時に問題が生じても、モジュールに分割したおかげで解析もしやすかったです。(モジュールがなんともなければ、あとはメインに集中するだけだったから！)

ブランチで作業を整理

上にも示した記事で、(内容が分散してしまっていますが) ブランチ管理についての所感はこちらの記事に書きました。

一言にまとめると、やっている/やった作業をキレイに整理しながら開発できたように感じています。

反省したい点

PR の粒度をもっと細かくできた

(PR: Pull Request)

複数の更新を 1つの PR にまとめてしまう、というのを何度かやってしまいました。例えば、機能の修正と、(それとは全く関係無い箇所の) タイポ修正を一緒にやってしまうとか。

原因は至ってシンプル。ブランチ分けと PR 作成サボりです。どうせ 1人だしって、ちょっとサボってしまいました。

PR 1つで 1つだけのことをやっていれば、PR のタイトルから作業内容を把握しやすいです (もちろん、適切なタイトルをつけているという前提で)。しかし、PR 1つが複数の作業内容を含んでいると、作業が把握し辛くなってしまいます。

複数人それぞれが作業を進めるチーム開発で、各人の作業を把握できないのは致命的ですから、これは避けるべきですね。

main へのマージ粒度をもっと細かくできた

フロントエンドとバックエンド、両方ともある程度できてからはじめてバージョン 0.0 のリリースをしました。ただ後になってみると、バックエンドだけできた時点で、フロントエンドは簡単な実装にしてリリースを入れてもよかったかも、というふうに思っています。

ちなみに、この原因もシンプル。リリース作成サボりです。

アジャイル開発手法では、確実に動く成果物を短い期間でこまめに提供していきます (この開発アジャイルにいくぜ！ってやったわけじゃないけど･･･)。今回の場合では、バックエンドができただだけでも成果として成立したので、より細かくリリースを出しても良かったかなと感じています。

これから挑戦したいこと

今回は、テストプログラムは全て手動チェックで、全テストが通るのを確認してから push しました。GitHub Actions を使った自動チェックもやってみようかなと思っています。

あとがき

作ったのは単純なものですが、細かく作り込んでみるとそこそこの作業量になりました (コミット数: 350超, PR数: 80超)。 結果、1人開発でもブランチ管理は作業管理として価値のあるものとなりました。

1人開発だからと言わず、ブランチ運用体験は多くの人にぜひともやってみてほしいなと思っています。

さいごに自慢 (がんばったこと)

今回のこの開発、どんなに小さい編集でも 1日 1コミット以上を毎日するようにがんばりました。おかげで芝生がちゃんと芝生していて、ちょっと感動できます。

Contributing

(途切れた日もちょくちょくあるけど･･･。)

GitHubで編集を提案

Discussion