tawara's blog

雑記。個人の見解です。

RUNTEQに入っての気づき【1.5ヶ月目編】

こんにちは、たわらです。

RUNTEQというプログラミングスクールに入って、はやいもので1.5ヶ月になりました。入学して学習をしていくなかでの気づきを振り返っておこうと思います。

スクール入学すると、こんなふうな気づきがあるよ、という1つのケースになれば、と思います。人によっては、遅っ! とツッコミが入るかもしれません。

ちなみに、スクールに入る前は、ProgateでHTML/CSSRubyRailsJavaScript、Git、CommandLine、SQLを一周して、Railsチュートリアルを一周して(ほぼ写経)、現場Railsを一周した(ほぼ写経)程度のプログラミング知識でした。

RUNTEQスクールのカリキュラムの基礎編を7~8割程度こなしたところです。毎日8時間以上は学習をしていたと思います。

1 クラスメソッドとインスタンスの違い

・UserとかBoardなど大文字からはじまる変数に使うfindとかnewとかがクラスメソッド

・UserとかBoardなどからつくったインスタンスに使うのがインスタンスメソッド

クラスのなかで作ったメソッドだからクラスメソッドかと思いきや、そうではない。この偏見に長い期間呪縛されていた。

2 入力値と出力値を気にする

メソッドに渡す引数は何で、出力値は何かを意識するようになった。戻り値がどのクラスのインスタンスなのか、true/falseなのかなどを確認するようになりました。このことで、自分が何のためにこのメソッドを利用しているかがより実感できるようになりました。

3 メソッドは対象のオブジェクトが持っているものしか使えない

たとえば

@board = current_user.boards.find(params[:id])

というコードがあります。

「現在のユーザーが作成した掲示板のうち、idと一致するレコードを変数に格納する」コードです。

なんとなく、ユーザーモデルと掲示板モデルを関連させてるから.boards ってメソッドを使ってるんだと思っていました。なぜ.boards ってメソッドを利用できるのかを理解していなかったです。

これをもっとコード目線?で見ると、、、

current_user はログインしているユーザーオブジェクトを返してます。(戻り値の意識!)

で、ユーザーモデルにはhas_many :boards と関連付けのために書いてます。で、こうすると引数で渡したシンボルの名前でメソッドが追加で使えるようになる!(Railsガイドにはきちんと記述がある)

なので、ユーザーモデルのインスタンスに対して.boards というメソッドが使えるようになるのですね。

で、この理屈でいくと、.find は? これはユーザーモデルや掲示板モデルが継承しているApplicationRecord にあるから(たぶん)、ユーザーモデルなどのインスタンスに使えるのですね。

つまり、とどのつまり、最終的に、結局、メソッドをただ利用しているのではなく、前のオブジェクトを確認してメソッドを使うことを意識しよう、ということ。

もっと個人的なイメージの話をすれば、メソッドはどこか宙に無数に浮いているものを、対象のオブジェクトに対して選んでいるような感覚だったが、対象のオブジェクトの中にあるメソッドしか使えないことに気づくと、思考の焦点が拡散せずに対象オブジェクトの正体を正確に理解しようと、考えられるようになった。

「メソッドを呼び出す」って何だよ、わかりにくい表現だな、と思っていたけど、この気づきによって「呼び出す」実感が持てました。

4 リソースを特定して処理をする、という考え方(パターン)に気づく

たとえば、値を更新するような、次のようなコードがあるとします。

def update
  @board = current_user.boards.find(params[:id])
  if @board.update(board_params)
    redirect_to board_path(@board), success: '掲示板を更新しました'
  else
    flash.now[:danger] = '掲示板を更新できませんでした'
    render :edit
  end
end

まず、内容を更新したい掲示板を、あの手この手でDBから引っ張ってきます(リソースの特定する)。

で、それを、あれやこれやと処理をするというパターンです。

これは、どんな処理を書く場合にも共通する考えです。一度実感すれば、当たり前かもしれませんが、なかなか気づけなかったですね。

5 デバッグや開発者ツールで処理の流れを確認する

エラーが発生すると、その周辺ばかり気にして、右往左往して時間を費やしていましたが、とにもかくにもまずは処理の流れの確認が重要だと気づきました。

そのために、binding.pryなどのデバッグツールをよく使うように意識しました。paramsにはどんな値が入っているか、入っていないかをコンソールで確認すると、現状の問題点を整理できます。

また、ブラウザの開発者ツールをよく使うようになりました。特に、ElementタブやNetworkタブにて、フォームタグのaction属性やmethod属性で、どんなURLでどんなHTTPリクエストをしているかを確認するようになりました。

6 公式ドキュメントを確認する

公式なんて情報過多で、読むのダルい、課題を解決するのに必要最低限の情報をQiitaや個人ブログで探して最短で実装するのがクールだ、という考えを捨てること。すみませんでした。ごめんなさい。

RailsガイドやRubyonRailsAPIやGitHubのReadmeを見ておくことが大切です。どんなオブジェクトにどんなメソッドを使っていて、どんなオプションを使うことができるのか、が網羅されているからです。

最後に

また思いついたら、追記します。

読んでくださったかた、ありがとうございます。

参考文献

qiita.com

qiita.com