Cursorで書いたコードを、事業を任せる前にレビューする

よくある問題

何で作ったかにかかわらず、レビューが追いつかない速さで育ったアプリによく見られる問題です。ほとんどは、今の環境のまま直せます。

1. 読まれないままマージされた大きな変更

   アシスタントは、ひとつのバグを直すために多くのファイルを変えることがあります。その規模の変更には、同僚のプルリクエストと同じレビューが必要です。小さく、目的を絞ったコミットにすれば、それができるようになります。

2. ほとんど何も確かめていないテスト

   同じアシスタントがコードの後に書いたテストは、コードが本来すべきことではなく、コードがしていることを確かめるだけになりがちです。売上に関わる流れには、要件から書いたテストが必要です。

3. 繰り返されたロジック

   2回頼めば、アシスタントは同じロジックを2回書くかもしれません。価格のルールや権限のチェックが2か所にあると、やがて食い違い、どちらかが間違った状態になります。

4. 誰も選んでいない依存関係

   アシスタントが追加するパッケージは、どれもお客様が依存するコードになります。それぞれが本当に必要か、保守されているか、意図したパッケージかを確認します。

5. コンテキストのそばにあるシークレット

   環境変数のファイルやキーは、リポジトリの外、ツールと共有する範囲の外に置きます。プロンプトに貼り付けたり、コミットしたりしたキーは、ローテーションが必要です。

6. 積み重ねでできたアーキテクチャ

   機能ごとに別のやり方で解決していくと、誰も全体を把握できないコードベースになります。早い段階でいくつかのパターンを決めておけば、変更しやすさを保てます。

Cursorで書いたアプリで監査が確認すること

コード・プロダクト監査では、外から見える部分だけでなくコードそのものを読み、すべての指摘を事業への影響で順位づけします。Cursorで書いたアプリの場合は、次の点を確認します。

• アーキテクチャと構造。この先1年のプロダクトを支えられるか。
• すべてのルートでの認証、認可、データアクセス。
• テスト。何をカバーしていて、実際の不具合を捕まえられるか。
• 依存関係。バージョン、ライセンス、既知の脆弱性。
• リポジトリとその履歴、デプロイされたバンドルに含まれるシークレット。
• CI、環境、デプロイ。
• プロダクトと事業の目標。お話をうかがい、すべての指摘を事業にとっての意味で順位づけします。

公開中のアプリを1日で確認する、固定価格のローンチチェックもご用意しています。認証、RLS（行レベルセキュリティ）とデータアクセス、シークレットを確認し、リスクの大きいものから5件を30分のお打ち合わせでご説明します。 ローンチチェックについて

今の環境のまま、本番で通用する状態へ

基本のご提案は、今あるコードベースを強くすることです。作り直しは、監査でその費用に見合うとわかった場合にだけご提案します。

Cursorで書いたアプリを、まず無料チェックで

無料チェックは、配信されているJavaScriptに含まれるキー、ヘッダー、HTTPS、バージョンなど、アプリがすでに外に見せているものをスキャンし、2営業日以内にAaronが結果を確認します。メールでのご確認と、アプリの所有者であることの確認が済んでから実行します。