※UIは内心気に入ってます。
MVPリリース後、
自分のアプリを見直したところ
以下の問題点が見つかりました。
作成したアプリ
SaveData
URL: https://savedata-app.onrender.com/
GitHub: https://github.com/Zundabyon/SaveData
テストアカウント:
Email: test@test.com
Password: password
【問題点】
１：コードが煩雑に書かれている
コメントアウトが左側にベタ付け 下の " /div "がかぶっているなど
- 書き方が同じファイル内でも一致していない
- それぞれのコントローラー内でも一致していないので見づらい
- インデントが一致しておらず、見づらい、エラーの原因になる
２：一部に債務（やること、処理）が偏ってしまい、見づらい
- 年表画面（ダッシュボード）のshow.html.erbファイル内にCSS、JSが
まとめて書かれているため、冗長なコードになっている
切り分けできるのは切り分けしよう
３：いらないコードやファイルが存在している
「せんし」のほかに 「warrior」が混在している 呼び出している画像は一緒
見るからに危ない
- 使っていないメソッド名なども存在しており、エラーの原因になる可能性
可読性の低下にもつながる
４：適当でない量のコメント
- あまり考えなくても良いようなところにもコメントアウトしているので
コードが縦長になってしまい、可読性低下
５：READMEが魅力的でない
- ここは別記事で触れることにします。
これらによって起こりそうなこと
１：エラーの発生
インデント違い、債務によって段を分けないことで
自らエラーを誘発する可能性もある
２：可読性の低下
自分だけ読めてもNG、、、
例えば別の方と共同開発したり、６ヶ月後に自らアップデートしたりする際に
困る。理解する時間のロスが起きる可能性あり
３：今後の拡張性に影響
今後機能を追加しようと思っても全てを動かす必要があり、難解
今後の方針
設計の見直しをした上で本リリースの実装を始める
今のうちに「型」を確定させる
そのために行うこと
１：いいコード、悪いコードのサイドキャッチアップ
- 講義を参考に自分のコードと照らし合わせる
- リーダブルコードで見やすいコードの理解
この二つの資料とAI(ChatGPT 5.2 Claude)と相談し合いながら作っていきます。
２：やることごとにISSUEの切り出し
- 先にISSUE含め設計してからでないと二の舞になるので
ここにむしろ時間をかける
実装内容は明かせませんが、
少なくとも公開できるところだと
- RSPECの実装 自分でテストコードを書く 今ゼロ👉
- 他ユーザーとのシェア機能の実装 思い出の共有
- ゲームデータの入力をもっと簡単に すごいAPIありました あとでね
その他必須実装要素数 １０
３：スケジュールと照らし合わせ
かけられる開発期間 35日/8h = 300h（約） 150ストーリーポイント
本リリース 4/6（予定）
これをISSUEに割り振っていく
その中で必須のものから順に実装し、確実に実装を終了させる
もちろんそれで開発終了ではなく、本リリース後も続けていく
４：キャッチアップの手段、ルール
公式文書参考
AIには基本的に実装内容ごとに教科書を作っていただく程度にとどめる
UIUXに関しては基本的に画面遷移図を参考に任せる
壁打ちとして(あくまで主ではなく右腕として使用する)使用する
ちなみにAIにレビュー ご興味のある方どうぞ
【ChatGPTによる添削 備忘録】
本リリースとして「甘い部分」5項目
① 責務の偏り（Fat Controller / View / Model）
根拠（現状）
Controllerに「画像削除・権限チェック・デバッグログ・分岐」が混在
（例：remove_cover_image、authorize_user!、大量ログ）。
Viewに「職業→画像の巨大ハッシュ」などロジックが埋まっている。
Userモデルに「章システム定数」「パスワード無し更新」などドメイン＋認証寄りの処理が同居。
なぜ問題か
仕様追加のたびに“触る場所が増える”→バグ混入率が上がる（認知負荷が増える：Sweller, 1988）
② 本番向けでないデバッグログが残っている
根拠（現状）
CREATE DEBUG / UPDATE DEBUG / Raw params 等が controller に直書き。
なぜ問題か
ログがノイズ化して障害解析が遅くなる
パラメータ内容によっては情報露出リスクが上がる（運用上の事故要因）
③ 画像表示・生成のパフォーマンスと責務が混線
根拠（現状）
Model側で variant URL をキャッシュ生成している一方、
Dashboard view は image_tag game.cover_image で直接出しており、方針が統一されていない。
なぜ問題か
画像は“遅さ”の主因になりやすいのに、どこで最適化するかが曖昧だと改善が続かない（本番で体感が落ちる）
④ 認可（Authorization）の設計が局所最適
根拠（現状）
authorize_user! が controller 内に手書きで、対象アクションも増えると重複が増える。
なぜ問題か
“追加機能のたびに漏れる”典型（共有・他人の年表閲覧・コメント等を入れると一気に破綻しやすい）
⑤ 本リリース運用の土台（監視・エラー収集・CI）が見えにくい
根拠（現状）
Render の render.yaml は migrate 実行など最低限のみで、監視・通知・品質ゲートは別途必要。
なぜ問題か
本リリースは「落ちたときに気づける」「原因を辿れる」が最重要。ここが薄いと改善サイクルが回らない
AIと自分のレビュー比較してみて それとまとめ
おおむね自分のレビューと同じ評価でした。
もちろんこれが全てではないと思います。
が、初心者から見ても見づらいものは見づらいです。
幸い、現役のエンジニアに添削依頼もしていただける環境なので
しっかり活用させていただき
胸を張って「自分のアプリのこういうところが好きです！」
「ここを頑張りました！」と言えるように開発に全力を尽くしたいと思います。