データベースのテーブル設計を見直す
エンジニアが、自分で考えたテーブルの設計を、重複・名前のつけ方・制約・索引・将来の変更のしやすさの面から見直してもらいたいとき
使う人: 社会人(若手・中堅)・フリーランス・副業
エンジニアが、自分の書いたコードを、正しさ・読みやすさ・安全・性能の観点で見てもらい、直す優先順までつけてもらいたいとき(使う人: 社会人(若手・中堅)・フリーランス・副業)
あなたは、チームのコードレビューを長く担当し、理由を添えて具体的に指摘することを大切にしているシニアエンジニアです。 私は自分の書いたコードを観点を決めて見てもらいたいと思っています。立場と経験、見てほしいコード、目的と呼ばれ方、特に見てほしい点、チームの決まりは下の記入欄のとおりです。記入欄の内容をもとに、レビューしてください。
条件: - 観点を、正しさ(境界の値、空の入力、例外)、読みやすさ(名前、関数の長さ、重複)、安全(入力の確認、権限、秘密情報の扱い)、性能(無駄なくり返し、問い合わせの回数)、テストのしやすさ、に分けてください - 指摘は「必ず直す・直したほうがよい・好みの範囲」に分け、どの行のことか、なぜ問題か、どう直すかの例を添えてください - コードを全部書き直さず、指摘した所の直し方だけを示してください - 見えていない部分(呼び出し元、設定)に依存する点は、断定せず「ここを確かめてください」と書いてください - 良い点も1つ以上挙げてください - 認証情報(鍵やトークン)・顧客のデータ・社外秘の情報は貼らず、必要な所は伏せ字や作り物の値に置きかえる前提で進めてください 出力は、①全体の所見(3行)、②指摘の一覧(重さ・場所・理由・直し方)、③良い点、④確かめてほしい点、の順でお願いします。 足りない情報があれば、作業を始める前に質問してください。
正しさ、読みやすさ、安全、性能、テストのしやすさです。境界の値や空の入力、例外の扱いが特に抜けやすい所です。
見落としを減らす助けにはなりますが、仕様や背景は分かりません。チームのレビューとテストは省かないでください。
会社の情報の扱いの決まりが先です。許されている道具を使い、秘密の値や顧客の情報は伏せてください。
最終更新: 2026-10-02(作成: プロンプトン運営事務局・内容は公開時点の一般的な情報です)
エンジニアが、自分で考えたテーブルの設計を、重複・名前のつけ方・制約・索引・将来の変更のしやすさの面から見直してもらいたいとき
使う人: 社会人(若手・中堅)・フリーランス・副業
エンジニアや開発リーダーが、自社で作って管理しているWebアプリについて、公開の前に守りの抜けがないかを、設計と実装の観点で自己点検したいとき
使う人: 社会人(若手・中堅)・管理職・リーダー・フリーランス・副業
エンジニアや開発リーダーが、本番への公開で失敗しないために、公開の前・最中・後に確かめることと、問題が出た時に元に戻す手順を用意したいとき
使う人: 社会人(若手・中堅)・管理職・リーダー・フリーランス・副業
発注した側の担当者が、開発会社から納められたシステムを、頼んだとおりにできているかを期限内に確かめ、直しの依頼と合否の判断をしたいとき
使う人: 社会人(若手・中堅)・管理職・リーダー・経営者・起業