4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【学習記録ツール追加実装】SPAアプリをSupabaseでデータ永続化+CICD組み込み+自動テスト対応

4
Last updated at Posted at 2026-09-16

何をやったのか

  • 学習記録ツールに以下の対応を実施
    • Supabaseでデータ永続化
    • GithubActionsによるCICD
    • Vitestによる自動テスト

気づきなど

  • ズラズラと書いていきます
  • 魅せるための記事というよりも、体験に基づく生きたメモとしたいため、AIで校正等はしていないです

一つ一つ作る原点に返った

  • なまじそこそこ歴は長いが技術力が高める活動が不足していた + AIの登場で軸足をぶらして開発の方法に迷いがあったがやはり基本はプリントデバッグと修正
  • それを土台に検索した方が早いとか、この設計おかしそうという感覚は自然と出てくる
  • その感覚をもとに設計を覚えることが、スピードと正確性、最小の変更で最大の効果につながるのだなと
  • CICDでローカルと違うOSでつどプリントデバッグ、Vitestのテストコードを久々に丁寧に0から手書きしていて気づいた
  • あと手書きしたコードは大したことないものでもやっぱり見返すの嬉しい。全部理解できるし自分で作ったんだとニヤニヤできる。スキル上がったとしても楽しむ用には手でコード書きたい

AIとの向き合い方

  • やっぱりAIはコンテキストを正しく与えたり、ハーネスを設計して改善続けないと間違ったアウトプットが出ることはある
    • node_modulesにあるコマンドを使わずグローバルインストールしようとするとか
    • Vitest標準で使えるメソッドがあるのにjestのメソッドをインストールさせようとするとか
  • 結局AIに任せても自身で検証したり、公式ドキュメントに当たらないとアウトプットとしてあまりに不正確すぎる。多数のモジュールが絡む大きなシステムとしては場当たり的なHowでは崩壊して戻りで何も進まなくなるだろう
  • その辺りを練習するために、学習に関してはgemini(賢すぎない)や、無料版perplexity(それっぽいものを検索することは自分で確実にできるので作業をAIに任せても問題ない)のチャットあたりが良さそう
  • コーディングエージェントは設計の知見がかなり高ければ10倍以上の速度をもたらすが、設計ができないと大変難しい結果になると感じた
  • 学習を通して「労力は外注できるが、能力は外注できない」を強く実感した

テストを書いていて実装をかなり変更した

  • これはプロダクションコードでは許される場面は限定的だと思われる
    • 具体的には大きなコンポーネント内でSupabaseからのfetchも行い、データ更新時はUI側はstateを楽観的に更新して、そのあとAPIにpostしていた
    • それをカスタムフックにデータ取得処理を分離して、それを初回マウント時もしくは、refetch用のメソッドをreturnして更新後にrefetchするようにした。永続化しているDBをSSOTとする設計
  • 先にテストを書く必要性、ドメインをモデリングして責務を分離しないとやはり手戻りが増えるもしくは、HTTPレイヤーからモックをするテストを実装してテストが重く負債化していただろうと見込まれる
  • やはり周りでいわゆるデキる人は、設計力がある。
    • 頭に正解の地図があるから、それから逸れたものも覚えられる
    • 小さな変更で大きな成果を生み出せる

以前と比べてどのように成長したのか

設計の大切さを痛感

  • 設計よりも実装速度だとか、コードを読み書きする速さだとか考えていたが、設計力に起因するものだなと体験を通して実感できた
  • そしてこれは開発に限る話ではない、業務において大切なこと

自分の中で開発プロセスの標準が固まりつつあるし、解像度低いところが明確になってきている

教科書的なものからは逸れると思うが、自分の中で以下のように、開発プロセスが体感を通して理解が進んできている。これを軸に経験を伴い修正を重ねることで開発が正確かつ速くなるだろうという実感を得た

  1. ユーザーストーリーマッピング(単純なユースケースだったため今回の活動で解像度は上げられていない)
  2. ドメインモデリング(今回ここの不足が課題として見えた)
  3. E2Eテスト設計、自動化はオプショナル(今回ここの不足が課題として見えた)
  4. 自動テストで screen.debug() でdomを確認
  5. 自動テストで redなテストを記述する。RTLであればこの時にdomの取得方法も確認できる(今回ここの不足が課題として見えた)
  6. 実装。RTLであればこの時にdomの取得方法も確認できる

大変だったところや工夫したところ

  • テストを書いてから設計をしなおしたこと

読んだ人に伝えられること

  • 今は正解をダイレクトにAIで出力できる時代です
  • しかし学習は正解をダイレクトに出力することとは違い、それを吸収するための血の通った体験を積み上げられる貴重な場だと思います
    • ex.) 間違った設計で実装することでめちゃくちゃ面倒な作業をしてしまうとか
  • なので作業したらすぐスキルになると期待しすぎず、作業したらスキルという種に水をやれたくらいで気長に手を動かした具体的な体験を積み上げるのがコツだと思います(カリキュラムで方向性は担保されている)
  • ご参考になれば嬉しいです

JISOUのメンバー募集中!

プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか?
興味のある方は、ぜひホームページをのぞいてみてください!
▼▼▼

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?