127コミットのリリースとは実際に何なのか

GeekBye v1.7.0に入っているものをただ列挙するだけのバージョンのブログ記事もあり得ます — 再設計されたホーム画面、キャリブレーションフロウ、折りたたみ式サイドバー、新しい設定、そしてまだまだ続く。正確ではあるでしょうが、あなたには何も教えてくれません。なぜなら127コミットのリリースの正直な物語はそのリストではないからです。それはかたちなのです。

これがそのかたちです。百二十七コミットと聞くと、百二十七個の小さなものに思えます。ほとんどの場合そうではありません。v1.7.0は二つの大きな機能であり、およそ11日間にわたって長寿命ブランチ上で並行して作られ、最後に編み合わされました。大きなリリースを理解するとは、その二本の糸を理解することを意味します — そして、私たちが間違った場所に何かを作り、飛行中にそれを引き剥がさねばならなかった一箇所を。

糸その一: キャリブレーション

最初の糸はキャリブレーションでした — あなたのコミュニケーションスキルに対するAIによる音声評価です。AIの「キャリアコーチ」とのライブ通話を始め、構造化された一連のフェーズ(ウォームアップ、行動面接、テクニカルコミュニケーション、プレッシャー対応、目標設定)を進み、最後に六つの次元でスコアが付けられます: 自信、明瞭さ、具体性、エンゲージメント、冷静さ、関連性です。その下では、具体的な発話メトリクスも測定します — あなたの話すペース、フィラー語の頻度、間が戦略的に読めるのか、それとも躊躇に読めるのか。

その出力は評点ではなく、出発点です。キャリブレーションはあなたの強み、あなたの成長領域、そして — 決定的に — 練習を始めるのに推奨される難易度を生み出します。それはプロダクトがあなたのどこで出会うべきかを調整するのです。各スキルは、サマリー、具体的な提案、そして例としてあなた自身の通話から実際に引用された一文を備えた、展開可能なフィードバックカードとして返ってきます。それは、残りの練習体験がその上に築かれる機能なのです。

糸その二: まるごと新しいウィンドウ

二つ目の糸はプレミアム再設計でした — そしてそれを再設計と呼ぶのは過小評価です。それは既存の画面のスキン張り替えではありませんでした; それは実質的に二つ目のアプリケーションウィンドウであり、六つの明示的なフェーズで作り上げられました: 折りたたみ式のNotion風サイドバー、古いセッションリストを置き換えたヘッダードロップダウン、履歴とパンくずを備えたブラウザ風ナビゲーション、そしてHome、Profiles、Meetings、Settingsのプレミアム再構築です。

二つの大きな機能。それが127コミットの実際の中身でした。そしてそれらを出荷することの一番の難所は、どちらかを書くことではありませんでした — それは編み込みでした。二つのブランチは相互依存していました; 一方が他方へマージされ、キャリブレーションブランチは、再設計がその足元で動いている間に同期がずれないようにするためだけに、mainブランチを四回も別々に取り込まなければなりませんでした。コミット数は大きなリリースのコストではありません。長寿命ブランチと統合の順序こそがコストです。

読む価値のある部分: 私たちはキャリブレーションを間違った場所に作った

これがそのミスであり、それはあまりにありふれているからこそ良いミスです。

GeekByeには揺るがぬアーキテクチャ上のルールがあります: すべてのAI操作はbackendに存在する。 クライアントはサーバーと話す薄い殻です。誰もがこれを知っていました。

それなのにキャリブレーションは最初、クライアントのローカルデータベースに作られました。専用のテーブル、データベースマイグレーション、254行のリポジトリ、IPCハンドラ、そして515行の評価質問バンク — そのすべてがユーザーのマシン上に住んでいました。それは動きました。それはまた、アプリ全体がその上に築かれている契約を静かに破っていました。

三日後、一つのコミットが八つのファイルにまたがる680行を削除して、それらすべてをbackendへ移し、そこでキャリブレーションデータは正当なサーバーサイドのモデルとなり、質問ロジックとスコアリングはサーバーの関心事になりました。別のコミットは515行のクライアント質問バンクをまるごと削除しました。その差分はほとんど笑えます: 1行の挿入、六百八十行の削除。

誰も680行の使い捨てコードを書こうと意図して始めたわけではありません。それはいつもこうして起こるのです: クライアントの近道はすぐそこにあり、ローカルでプロトタイプする方が速く、「後でbackendへ移せばいい」は無害に感じられる。しかしアーキテクチャが信頼できる情報源のありかをすでに告げているとき、それをどこか別の場所に作ることは近道ではありません — それは自分で自分のために前もって予定した手戻りです。 心に残った教訓はこれです: ローカル版の方が立ち上げが速いときでも、契約が言う場所に、一度目で置くこと。

統合だけが見つけられたバグ

もう一つ証拠を。それは大きなリリースの特徴的な失敗モードだからです。キャリブレーションと新しいナビゲーションが配線され、実際に走り始めると、アプリは明白な理由もなくレート制限 — HTTP 429 — に引っかかり始めました。

原因は純粋に統合でした。キャリブレーションのステータスがコンポーネントレベルでフェッチされていたため、あらゆるナビゲーションがそれを再フェッチしていました — そしてReactのstrict mode、つまりバグをあぶり出すために開発中は意図的にエフェクトを二重に呼び出すそれが、それをさらに二倍にしました。結果は画面遷移ごとに四から八個の同一のキャリブレーションリクエストが飛ぶことで、サーバーのレートリミッターに引っかかるのに十分でした。修正はフェッチをマウント時のわずか数回の呼び出しに集約しました。

このバグは、キャリブレーション単独をテストしても、ナビゲーション単独をテストしても、見つけることはできなかったでしょう。それは継ぎ目にだけ存在します — 二つのそれぞれ正しい機能が出会う場所に。それが大きなリリースが課す税金です: 最後の一マイルは機能を作ることではなく、それらがついに同じ部屋に入ったときにだけ壊れるすべてを発見することなのです。

大きなリリースが教えた三つのこと

1. 127コミットのリリースは二つか三つの大きなテーマであって、百個の小さなものではない。 糸を見つけよ。仕事 — そしてリスク — は、それらがどう編み合わさるかに宿るのであって、数には宿らない。
2. 信頼できる情報源は、契約が言う場所に、一度目で置け。 私たちはキャリブレーションをクライアントからbackendへ移すために680行を削除した。ローカルの近道は前もって予定した手戻りだ; アーキテクチャはすでに答えを告げていた。
3. 統合は、分離では見つけられない失敗をあぶり出す。 429の嵐は二つの正しい機能の継ぎ目に住んでいて、それらが一緒に走ったときにだけ現れた。機能ごとのテストだけでなく、統合のパスにも予算を割け。

これは、はるかに大きなスケールで再び語ることになる物語のv1時代の従兄弟です — バージョン2に実際に何がかかるか: 206コミットの正直な状態(v2.0.0)をご覧ください。そこでは同じ「大きな数字は本当はいくつかの大きなアイデアだ」という真実が、v2の書き直し全体にわたって展開します。v1の物語の前の章については、ライブレポートをちらつきなしでストリーミングする方法(v1.6.13)を; そして弧の全体については、ソフトウェアを完璧に出荷することの解剖学をご覧ください。