「コーディング」の投稿

バックエンド開発専門のskillsを作りたい。 名前：dev-backend 書き込んでよい場所 //任意のディレクトリ **これ以外は書き換えない。** 画面・コンポーネントの不具合を見つけたら `dev-frontend` へ依頼を出す。 (上記は任意) 起動コマンド /dev-backend

以下の作業を、いつ中断されてもよい形に刻んでください。私は30分後に内容を忘れます。 # 出力形式 ## 1. 刻んだ手順 | # | やること | 所要の見当 | この段階が終わったとき、動く状態か | 再開するとき最初に見るファイル | |---|---|---|---|---| 刻む原則： - 1段階は30分以内で終わる大きさ - 各段階の終わりで、壊れたまま止まらないようにする - 途中で止められない段階がある場合は、そう明記する ## 2. 中断してはいけない区間 - [#〜#] / なぜ途中で止めると危ないか / どうしても止めるときの退避方法 ## 3. 各段階の終わりに残すメモ - 何を書き残せば再開できるか（テンプレートの形で） ## 4. 今日やらないと決めてよい段階 - [#] / 後回しにできる理由 # 制約 - コードを書かない。作業の分解まで。 - 「まず設計する」のような曖昧な段階を作らない。終わったかどうかが自分で判定できる形にする。 - 所要時間は「見当」と明記する。正確な見積もりとして書かない。 - 1段階に複数のファイルの大きな変更を詰め込まない。 # 作業 （何を作る・直すか） # いま動いているか （動いている / 壊れている / まだ何も無い）

仕様書とコードが食い違っています。どちらが正しいかは決めないでください。両方の言い分を書いてください。 # 出力形式 ## 1. 食い違っている点 | # | 仕様書ではこう | コードではこう | どちらかで利用者の体験が変わるか | |---|---|---|---| ## 2. 各食い違いについて ### 食い違い[#] - **仕様書の言い分**：この仕様が正しいとしたら、どんな意図があったか - **コードの言い分**：この実装が正しいとしたら、どんな事情でこうなったか（仕様書に書かれていない制約に当たった可能性など） - **どちらが後から書かれたか**（判断材料があれば） - **決めるために必要な情報** ## 3. 実は食い違っていないもの - [項目] / 読み方の違いにすぎない理由 ## 4. どちらを直すにせよ、影響が出る場所 - [場所] # 制約 - 判定を出さない。「コードが正しいです」と書かない。 - 仕様書を無条件に正しいものとして扱わない。書かれた時点では分からなかったことがある。 - 食い違いが無い場合は、無理に探さず「食い違いは見当たりません」と書く。 - 3を必ず確認する。読み違いを食い違いとして数えない。 # 仕様書（該当部分） （ここに貼る） # コード （ここに貼る）

以下のコードとテストがあります。コードにわざと欠陥を入れた場合、テストが落ちるかを考えてください。実際にコードを書き換える必要はありません。 # 出力形式 ## 1. 仕込む欠陥と、テストの反応 | # | どこをどう壊すか | このテストは落ちるか | 落ちない場合、何が検査されていないか | |---|---|---|---| 仕込む欠陥の例（コードに合うものを選ぶ）： - 条件の不等号を1つずらす - 早期リターンを消す - 例外の握りつぶしを足す - 引数の順番を入れ替える - 空・0・負・最大値のときだけ違う値を返すようにする ## 2. 素通りする欠陥（本題） - [欠陥] / これを検出するには、どんなテストが要るか（テストの名前と、確認する内容だけ書く） ## 3. テストが検査しているつもりで検査していないこと - [項目] / なぜそう言えるか ## 4. 追加すべきテスト（優先順に3つまで） - [テスト名] / 何を固定するためのものか # 制約 - テストコードを書かない。名前と検査内容まで。 - 「カバレッジを上げましょう」と書かない。通った行数と検査の質は別。 - コードに存在しない分岐を仮定して欠陥を作らない。 - 落ちるテストばかりになった場合は、テストは十分だと書く。無理に穴を作らない。 # コード （ここに貼る） # テスト （ここに貼る）

以下の機能を作ろうとしています。作らないほうがよい理由を、全力で出してください。 # 出力形式 ## 1. 作らない案 | # | 代わりの手段 | それで足りる条件 | 足りない条件 | |---|---|---|---| （既存の機能で代用する／手作業でやる／そもそもやらない／後回しにする、を最低限検討する） ## 2. 作った場合に、ずっと払い続けるもの - [何を] / いつ効いてくるか（データが増えたとき／人が増えたとき／仕様が変わったとき） ## 3. この機能が本当に要ると分かる兆候 - [兆候] / これが観測できたら作ってよい ## 4. それでも作るなら、最小の形 - 削れる部分を全部削った形（機能の説明を3行以内で） ## 5. 反対しきれなかった点 - この機能を作るべき理由として、あなたが崩せなかったもの # 制約 - 私に同意しない。作る前提で話を進めない。 - 「ユーザーが喜びます」のような検証できない理由を認めない。 - 4を書くときも、元の案の機能を全部残さない。必ず削る。 - 5を必ず書く。反対一色にすると判断材料にならない。 # 作ろうとしている機能 （何を、なぜ作りたいか） # 今の利用者数・利用頻度 （分かる範囲。無ければ「まだ利用者はいない」と書く）

以下のコードを読んで、書いた人の意図を推定してください。直し方は聞いていません。 # 出力形式 ## 1. 素直に書けばこうなるはず、という形 （一般的な書き方との違いを1〜3点） ## 2. なぜそうしなかったのかの推定 | 違っている箇所 | 考えられる理由 | 確からしさ | |---|---|---| 確からしさは「コードから読める / 状況から推測できる / 単なる想像」の3段階。 ## 3. 消すと壊れる可能性がある箇所 - [箇所] / 何のためにあるか / 消した場合に起きること ## 4. 本当に不要かもしれない箇所 - [箇所] / なぜ不要と思うか / 消す前に確認すべきこと ## 5. 書いた人に聞くべきこと（1つ） - [質問] # 制約 - 「単なる想像」に分類したものを断定形で書かない。 - 書いた人を批判しない。当時の制約を推定する。 - 3を省略しない。変わった書き方には理由があることが多い。 - 4に挙げるものは、確認方法とセットで書く。確認方法を示せないものは3に回す。 # コード （ここに貼る） # 分かっている背景（無ければ「不明」） （いつ書かれたか、どんな環境で動いているか）

これから以下の機能を作ります。実装の前に、失敗したときの挙動を決めたいです。 # 出力形式 ## 1. 失敗しうる場面 | # | 何が起きるか | 起きる確率の見当 | 気づけるか | |---|---|---|---| （通信が切れる、権限が無い、二重に送信される、途中で止まる、想定外の値が来る、同時に別の人が操作する、を最低限検討する） ## 2. それぞれの挙動 | # | 利用者に何を見せるか | 内部でどうするか（再試行/中断/巻き戻し） | 記録に残すか | |---|---|---|---| ## 3. 中途半端な状態が残るもの - [場面] / どんな状態が残るか / どう復旧するか ## 4. 今回は対応しないと決めるもの - [場面] / 対応しない理由 / 起きたらどうなるか ## 5. 決めるのに情報が足りない点 - [項目] # 制約 - 「エラーメッセージを表示する」で終わらせない。何を表示するか、その後どうなるかまで書く。 - 4を必ず書く。全部に対応する前提だと実装が終わらない。 - 利用者に見せる文言は日本語で、原因ではなく次の行動が分かる形で書く。 - 3が空になることはまずない。空にする前に、処理が途中で止まる場面を探す。 # 作る機能 （何をする機能か。誰が使うか） # 使っている仕組み （例：Webフォームからサーバーに送信してDBに保存する）

以下の処理について、ログ出力を設計してください。 # 出力形式 ## 1. 事故が起きたときに知りたいこと - [知りたいこと] / それが無いと何が分からないか ## 2. 出すログ | 場所（処理のどこ） | レベル | 出す内容 | 1で挙げたどれに対応するか | |---|---|---|---| ## 3. 出してはいけない情報 - [項目] / 代わりに何を出すか（例：メールアドレスそのものではなく、識別できない形の値） ## 4. 出さないと決めたもの - [項目] / 出さない理由（量が多すぎる／後から復元できる） ## 5. 正常時にも出すべきもの - 異常時だけのログでは、いつから壊れていたかが分からない。正常系で最低限残すもの # 制約 - 全部の行にログを入れる設計にしない。多いログは無いのと同じ。 - ログの文言に、その時点の変数名だけを並べない。何が起きたかが読める文にする。 - 個人情報・認証情報・トークンをログに出す設計を書かない。 - 「必要に応じて」と書かない。出すか出さないかを決める。 # 処理の内容 （コードでも、処理の流れの説明でもよい） # 誰がこのログを読むか （例：自分だけ / 運用担当 / 障害時に初めて見る人）

以下のコードについて、外から来る値の扱いを点検してください。 # 出力形式 ## 1. 外から来る値の一覧 | どこから来るか（フォーム/URL/ヘッダ/ファイル/外部API/DB） | 変数 | この値を信用しているか | |---|---|---| ## 2. 信用してしまっている箇所 - [箇所] / どんな値が来ると困るか（種類の説明。実際の攻撃文字列は書かない） ## 3. 検証が要る観点 - 型・長さ・文字種・範囲・必須／任意 - 検証をどこでやるべきか（画面側だけでは不十分な理由も含めて） ## 4. 権限の確認が抜けている箇所 - [箇所] / 「ログインしている」だけで「その人のものか」を確認していない箇所 ## 5. エラー時に出しすぎている情報 - [箇所] / 外に見せてよい形 # 制約 - 攻撃の実例となる文字列やコードを書かない。危険な入力の「種類」を日本語で説明する。 - 修正コードを書かない。指摘まで。 - 「サニタイズしましょう」で終わらせない。どの値を、どこで、何に対して検証するかを書く。 - コードから読み取れない部分（フレームワーク側で処理されている可能性）は、断定せず確認事項として書く。 # 言語・フレームワーク （例：Next.js / Django） # コード （ここに貼る）

以下のコードを整理したいです。安全な順番を作ってください。 # 出力形式 ## 0. 今テストはあるか - 無い場合、最初に書くべきテストは何か（振る舞いを固定するための最小限のもの） ## 1. 順番 | # | やること | この段階で壊れる可能性 | 終わったことをどう確認するか | |---|---|---|---| 順番の原則： - 振る舞いを変えない変更を先、変える変更を後 - 影響範囲の狭いものを先 - 各段階は、単独でコミットできる大きさにする ## 2. 一度にやってはいけない組み合わせ - [Aと B] / 同時にやると何が分からなくなるか ## 3. やらないほうがよい整理 - [項目] / 今やる価値が無い理由 ## 4. 途中でやめても大丈夫な地点 - どこまでやれば、中途半端でも害が無いか # 制約 - 整理後のコードを書かない。順番の設計まで。 - 全部やる前提で書かない。3と4を必ず書く。 - 「読みやすくなります」を理由にしない。何が起きにくくなるかを書く。 - テストが無い状態で振る舞いを変える手順を1番目に置かない。 # コード （ここに貼る） # 整理したい理由 （例：機能を足したいが触れない / 同じ処理が散らばっている）