ITヲタクな AI くんにピッタリな仕事の一つは、モジュールアップデート。
特に、メジャーアップデートが超助かる。
昔だったら 数ヶ月掛かった移行も、数日たらずに対応できるようになったので、
さすが ITヲタクくん。
対応してよかったフローについて、書き留めておきます。
私の場合は、 npm のメジャーアップデートをここ1ヶ月ぐらいやっていました。
複数のWebフレームワークや、静的解析ツール、APIクライアントツール、モノレポツールなど、
メジャーアップデートを放置していたものを掘り起こして対応していました。
メジャーアップデートって、キラキラしてワクワクするんですけど、
移行と思うと 少しヘビーなんですよね...。
一番は、安心安全にメジャーアップデートした内容を受け入れる仕組みを整えることです。
型検査、静的解析(種々様々な強固なもの)、テスト、ビルド、その他 機械的にチェックできるモノ全てです。
この中にあるテストは、主に単体テストや結合テストが一般的にですが、
私の場合は、 Testcontainers + Playwright + Cucumber による受け入れテストを CI 上で動かせる準備を整えています。
これはWebフレームワークやAPIクライアントなど、End to End な確認作業のときに大変重宝しました。
Web UI に関わるCSSフレームワークなどのメジャーアップデートの場合は、
Vitest + Browser Mode による VRT が実現できるため、デザイン崩れを検知できます。
少し古いですが、以下の記事にあるような網羅的にテストをカバーできていると安心です。
※ もう3年前の記事なのでした...
この受け入れる仕組みがあれば、かなり安心してリリースできます。
もちろん手動確認は必須ですが、その前段階での 確認網羅が広いと作業工数が減って作業ミスも減って 、良きです。
AI には、メジャーアップデートによるマイグレーションガイドを必ず読ませます。
トリッキーなことをさせずに、推奨方針で進めさせる方が、もしもの時のトラブルショート がやりやすいからです。
イシューがすでに起票されていたり、誰かが記事を書いていたりするかもだからです。
ただ、私もマイグレーションガイドを最後まで一読します。
AI の成果物の良し悪しのジャッジするためと、
デフォルトの挙動が変わらないかなどはみています。
まあ、結局のところ 成果物を見ても "わからない" となってしまうから 読むだけです。笑
一旦 AI にマイグレーションガイドに沿って、
変更行数・変更ファイル数など無視して、
マイグレーションを完成させるところを目指します。
ゴールは、先ほどの受け入れ仕組みが通ることです。
試作して気づくことは多く、
プロダクト固有の問題や他のライブラリの依存関係で困ることなど、
机上の空論では気付けないことが多くあります。
とにかく受け入れを通せる状態まで来たら、
その修正(PullRequest)を捨てます。
その後、修正内容について分類し、メジャーアップデート前の準備できることを、
細かく分けて PullRequestを建ててリリースすると、ビッグバンリリースではなくなります。
これはレビュワーにとってありがたいことで、
そういう負担軽減にもつながります。
特に大規模な変更の場合、マイグレーションに時間がかかることがあります。
AI のトークンが勿体ないです。
そんなときは、使い捨てのマイグレーションスクリプトを AI に書かせます。
AST 解析させてコードを修正するスクリプトを書かせて、
そのスクリプトを実行することで、冪等に同じ結果になるようにします。
冪等が大事 で、実行するたびに結果が変わるとその内容を微調整しないといけなくなるため、
冪等で結果が変わらないようにすると、確認作業が楽です。
私の場合は、mjsファイルを沢山作らせてとnpm scriptで直列に実行するコマンドを追加します。
あとはそのコマンドを実行するだけで、マイグレーションが完成するようにします。
AI がない場合はこういうのを作らせるのって結構大変だったので、
ありがたい限りです。
マイグレーションガイドを丁寧に公開してくださる OSSメンテナの皆さん、
いつもありがとうございます。
-
s※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
タグ「AI」の記事
この記事をかくときは、100%人の手で書いています。 UIをつくるときも、100%人の手で書いています。 (ロジックは AI に書かせます) 他にはプレゼンテーションやスライドといった書き物も、 コンテンツ準備は AI にさせますが、文章を
以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi
最近のお悩みは、Webのソフトウェア開発におけるテストコードが爆増したことにより、 テスト成功による過度な安心感 によって手動確認するのが減っているのかもと思ったりしています。 例えば、Webのフォーム画面に小さな改修があったとして、その修
タグ「フロントエンド」の記事
以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi
最近のお悩みは、Webのソフトウェア開発におけるテストコードが爆増したことにより、 テスト成功による過度な安心感 によって手動確認するのが減っているのかもと思ったりしています。 例えば、Webのフォーム画面に小さな改修があったとして、その修
以下で書いた個人ブログを読むアプリ(個人ブログライブラリ、略して "こぶりー" )をモバイルアプリで開発していました。 https://silverbirder.github.io/blog/contents/20260419/ 審査関連で
2026年05月11日