見出し画像

久しぶりにRailsで「ほしいものリスト」アプリをつくろうとして色々失敗した話

tom_R7春期応用情報

プログラミングの学習を開始して4ヶ月が経ち、『オブジェクト指向設計実践ガイド』もほぼほぼ読了しました。

学習開始からこのかた、HTML→CSS→Ruby→Rails→JS→Reactという感じでいろいろつまみ食いしてきましたが、そろそろオリジナルAppをつくってみよう。ということで、「ほしいものリスト」アプリを作ってみました。

その中で、いろいろ失敗したので備忘録（反省文？）として書き残しておきます。


ほしいものリストアプリの仕様

  • メインの機能

    • ほしいものを登録できる

    • 価格を登録できる

    • 説明を追加できる

    • 購入予定日を登録できる（オプション）

    • 商品URLを登録できる（オプション）

    • ほしいものは編集できる

    • ほしいものは削除できる

    • ほしいものリストの合計金額を算出できる

    • ほしいもの詳細画面を見ることができる

  • ユーザー管理関連

    • ユーザーログインしないと、リスト機能にアクセスできない

    • ユーザーログインしたら、自分のリストが表示される

    • 他のユーザーのリスト・ほしいもの詳細は見えない（URL直打ちした場合、自分のトップページへリダイレクトされる）

    • サインインしていないとき、すべての画面からサインインページにリダイレクトされる

    • サインインしていないとき、サインインページとサインアップページにのみアクセスできる

    • サインインしているときのみ、新規ほしいもの登録画面にアクセスできる

久しぶりのRails

上記のように、いわゆるCRUD（作成・読み込み・更新・削除）の機能を一通り思い出すとともに、ユーザーログイン状態によって動作を変えて、ユーザーごとに他の人のアイテムが見えないような仕様にしました。

通常SNSのようなアプリであれば、「ログインしなくても他人の投稿が見れる」という実装をすることが多いのですが、あくまでこれはログインした上で個人が使うことを想定したアプリ、ということにしています。

久しぶりのRailsということで、いろいろボロボロになったので失敗エピソードを供養しておきます。

失敗1：ページがダブってレンダリングされる

アプリ立ち上げ直後、「新規登録画面」で登録が終わったらトップページに遷移するコードを書きました。

すると、トップページに「新規登録画面」が並んで表示されるという変な現象に見舞われました。（スクショ撮り忘れた・・・）

ページが遷移しても、そこに無いはずの投稿ページが表示されている、というホラーみたいな現象です。

解決策：ビュー（html.erb）ファイルの拡張子を修正

久しぶりすぎたせいか、何を思ったかビューファイルの拡張子を「index.erb」にしていました。完全にReactの後遺症です。（Reactではだいたいindex.jsxかindex.tsxを使う）

この拡張子が間違っていると、こういうワケのわからんバグが起きるらしいです。

どうりでググっても答えが出てこないわけです。そもそもRailsの使い方から間違っているので、誰もこんなバグ引かないんですね。

大笑いしてないでちゃんと反省しなさい。

失敗2: とりあえず思いつくgemを全部一気にinstallしようとしてバグる

Railsうろ覚えマンの状態で、新しくRails newでアプリを立ち上げたもんですから、最初にGemfileを開いて意気揚々と、pry-railsとかFactoryBotとかdeviseとか、あらゆる思いつくgemを一気にぶちこみました。

案の定というか、deviseの設定のためにモデルを作ったりビューを作る段階で大量のエラーが出まくってドエライことになりました。

解決策：Gemは必要なとき、1個ずつ

GitHubからロールバックして、必要になってから1個ずつインストールすることでことなきを得ました。（一気にたくさんGemを入れるのはやめよう！）

失敗3：AIにコードを丸ごと改変させようと試み、コードを破壊される

とりあえず書き進めたコードを、何を思ったかAIに丸投げして、「アイテム全部取得して表にしておいてー」的なノリで丸コピして投げ、帰ってきたコードをそのままエディタに貼ったら何も動かなくなりました。

たとえば、ほしい物リストの「ほしい理由」的な意味合いでDBに「reason」カラムを入れておいたのですが、AIくんは一般的に「description」カラムを使うと思いこんでいるので、カラム名が全く合わずにエラー祭りになったという次第です。

解決策：AIに全部投げたら人力チェックの方が大変。人力で書いたコードをAIにチェックさせよう

そうです。AIの使い方が逆でした。
まずGoogleとかQiitaとかで検索して、自分でコードを書いてから、AIにチェックしてもらったり、そのコードをわずかに改善するために使うのが良さそうでした。楽をするポイントを間違えると、楽にならないのでした。

まとめ

失敗しながらいろいろ考えた結果、今の自分の実力では、コードを書いていくときの心構えは以下です。

  • 小さく変更し、こまめにテストする

  • こまめにGitにコミット・プッシュする（もしうっかり破壊してもロードできる）

  • 変更の目的を明らかにして、その目的を果たすための作業は一気にやる

  • 変更が簡単になるようにコードを書けと習ったが、まず動くコードを書く

  • 冗長でもいいからまず動かす。そのあとリファクタリングする

  • うろ覚えで適当にターミナルにコマンドをぶち込まない。調べてから叩く

  • 基礎ムーブ（ルーティング・コントローラの確認、バリデーション・ストロングパラメータ）は徹底して繰り返して覚える。適当な順番でやらない


要は「油断すな」ってことですね。

前回も書きましたが、やはり本ばかり読んで知識を入れても実際に書いて失敗するのがいちばん勉強になるなーと痛感しています。

以上です。
最後までお読みいただきありがとうございました。

いいなと思ったら応援しよう！