RUNTEQに入っての気づき【1.5ヶ月目編】
June 19, 2020
こんにちは、たわらです。
RUNTEQ というプログラミングスクールに入って、はやいもので 1.5 ヶ月になりました。入学して学習をしていくなかでの気づきを振り返っておこうと思います。
スクール入学すると、こんなふうな気づきがあるよ、という１つのケースになれば、と思います。人によっては、遅っ！ とツッコミが入るかもしれません。
ちなみに、スクールに入る前は、Progate で HTML/CSS、Ruby、Rails，JavaScript、Git、CommandLine、SQL を一周して、Rails チュートリアルを一周して（ほぼ写経）、現場 Rails を一周した（ほぼ写経）程度のプログラミング知識でした。
RUNTEQ スクールのカリキュラムの基礎編を 7~8 割程度こなしたところです。毎日８時間以上は学習をしていたと思います。
１ クラスメソッドとインスタンスの違い
・User とか Board など大文字からはじまる変数に使う find とか new とかがクラスメソッド
・User とか Board などからつくったインスタンスに使うのがインスタンスメソッド
クラスのなかで作ったメソッドだからクラスメソッドかと思いきや、そうではない。この偏見に長い期間呪縛されていた。
２ 入力値と出力値を気にする
メソッドに渡す引数は何で、出力値は何かを意識するようになった。戻り値がどのクラスのインスタンスなのか、true/false なのかなどを確認するようになりました。このことで、自分が何のためにこのメソッドを利用しているかがより実感できるようになりました。
３ メソッドは対象のオブジェクトが持っているものしか使えない
たとえば
@board = current_user.boards.find(params[:id])
というコードがあります。
「現在のユーザーが作成した掲示板のうち、id と一致するレコードを変数に格納する」コードです。
なんとなく、ユーザーモデルと掲示板モデルを関連させてるから.boards ってメソッドを使ってるんだと思っていました。なぜ.boards ってメソッドを利用できるのかを理解していなかったです。
これをもっとコード目線？で見ると、、、
current_user はログインしているユーザーオブジェクトを返してます。（戻り値の意識！）
で、ユーザーモデルにはhas_many :boards と関連付けのために書いてます。で、こうすると引数で渡したシンボルの名前でメソッドが追加で使えるようになる！（Rails ガイドにはきちんと記述がある）
なので、ユーザーモデルのインスタンスに対して.boards というメソッドが使えるようになるのですね。
で、この理屈でいくと、.find は？ これはユーザーモデルや掲示板モデルが継承しているApplicationRecord にあるから（たぶん）、ユーザーモデルなどのインスタンスに使えるのですね。
つまり、とどのつまり、最終的に、結局、メソッドをただ利用しているのではなく、前のオブジェクトを確認してメソッドを使うことを意識しよう、ということ。
もっと個人的なイメージの話をすれば、メソッドはどこか宙に無数に浮いているものを、対象のオブジェクトに対して選んでいるような感覚だったが、対象のオブジェクトの中にあるメソッドしか使えないことに気づくと、思考の焦点が拡散せずに対象オブジェクトの正体を正確に理解しようと、考えられるようになった。
「メソッドを呼び出す」って何だよ、わかりにくい表現だな、と思っていたけど、この気づきによって「呼び出す」実感が持てました。
４ リソースを特定して処理をする、という考え方（パターン）に気づく
たとえば、値を更新するような、次のようなコードがあるとします。
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 から引っ張ってきます（リソースの特定する）。
で、それを、あれやこれやと処理をするというパターンです。
これは、どんな処理を書く場合にも共通する考えです。一度実感すれば、当たり前かもしれませんが、なかなか気づけなかったですね。
５ デバッグや開発者ツールで処理の流れを確認する
エラーが発生すると、その周辺ばかり気にして、右往左往して時間を費やしていましたが、とにもかくにもまずは処理の流れの確認が重要だと気づきました。
そのために、binding.pryなどのデバッグツールをよく使うように意識しました。paramsにはどんな値が入っているか、入っていないかをコンソールで確認すると、現状の問題点を整理できます。
また、ブラウザの開発者ツールをよく使うようになりました。特に、Element タブや Network タブにて、フォームタグの action 属性や method 属性で、どんな URL でどんな HTTP リクエストをしているかを確認するようになりました。
６ 公式ドキュメントを確認する
公式なんて情報過多で、読むのダルい、課題を解決するのに必要最低限の情報を Qiita や個人ブログで探して最短で実装するのがクールだ、という考えを捨てること。すみませんでした。ごめんなさい。
Rails ガイドや RubyonRailsAPI や GitHub の Readme を見ておくことが大切です。どんなオブジェクトにどんなメソッドを使っていて、どんなオプションを使うことができるのか、が網羅されているからです。
最後に
また思いついたら、追記します。
読んでくださったかた、ありがとうございます。