GitLabのコードリーディングをしてみた(後編)

f:id:ryoutaku_jo:20190218202132p:plain

【結論】
・機能を理解しやすい命名を行う事で、
 その後のコードリーディングを円滑に進めることが出来る。

・include元のメソッドは、include先でも使用できる

・文字と文字の間を、大文字にして区切りを表す記述方法を
「キャメルケース」といい、クラス名に利用される。

【目次】


【本題】

前回までの続き

下記の記事の続きです。

ryoutaku-jo.hatenablog.com

ryoutaku-jo.hatenablog.com

命名は非常に重要

f:id:ryoutaku_jo:20190217013858p:plain

前回は、set_sort_orderの定義元を探し出し、
そこで定義されている条件式の中のメソッドの定義元まで探りました。

f:id:ryoutaku_jo:20190217100712p:plain

f:id:ryoutaku_jo:20190217015341p:plain

f:id:ryoutaku_jo:20190217015355p:plain

ここでそれぞれのメソッド名を改めて見ていきます。

「set_sort_order_from_user_preference」・・・ユーザー設定からソート順を設定する
「set_sort_order_from_cookie」・・・クッキーからソート順を設定する
「default_sort_order」・・・デフォルトのソート順

これだけでも、set_sort_orderが何をするメソッドなのか、
大体読み取れるかと思います。

ここで思ったのは、
命名は本当に大事!!
ということです。

正直、まだまだRubyRails)を触り出して日が浅い私には
コードの動きを全て理解する事は困難ですが、
機能を理解出来る様な名前が付いているだけで、
コードリーディングの捗り方が全く違いました!

では、コードリーディングに戻ります。

8:finder_typeの内容を掘り下げる

これ以上「finder_options」を掘り下げるとキリが無いので、一旦戻ります。

元々、「finder_options」を掘り下げていたのも、
finder_class.newで生成されるオブジェクトがどういったプロパティを持っているのか
特定したかったからです。

  def issuable_finder_for(finder_class)
    finder_class.new(current_user, finder_options)
  end

そもそも、「issuable_finder_for」が引数で渡している「finder_class」が
どういった値なのか分からないと特定できない事を見落としていました・・・
とりあえずfinder_typeの内容から探り直します。

  def finder
    @finder ||= issuable_finder_for(finder_type)
  end

同じファイルでは定義されていませんでした。
その様な場合は、include元のファイルを探ります。
なぜなら、include元のメソッドは、include先でも使用できるからです。

では、include元の「issues_controller」を見てみます。

f:id:ryoutaku_jo:20190217121944p:plain

ありました!「IssuesFinder」という記述だけです。

なお、こういった文字と文字の間を、大文字にして区切りを表す記述方法を
「キャメルケース」
と言います。
そして、キャメルケースは、クラス名で使用される記述方法です。
その為、この「IssuesFinder」もクラス名を指している事が考えられます。

では、「IssuesFinder」クラスを定義しているファイルを探して来ます。

f:id:ryoutaku_jo:20190217122323p:plain

f:id:ryoutaku_jo:20190217122336p:plain

見つけました!
また、「IssuableFinder」というクラスを継承している事もわかったので、
そちらも確認してみます。

f:id:ryoutaku_jo:20190217123550p:plain

f:id:ryoutaku_jo:20190217123629p:plain

見つけました!
また、このクラスにはinitializeメソッドが定義されています。

f:id:ryoutaku_jo:20190217123721p:plain

initializeメソッドとは、それを定義しているクラスのオブジェクトが
新たに生成された際に、自動的に呼び出されるメソッドです。

これにより、「issuable_finder_for」では、
「@current_user」「@params」が自動生成されていることがわかります。

そして、そのインスタンス変数が、finderメソッドによって、
@finderに代入されます(空の場合)

9:issuables_collectionの内容を掘り下げる

finderの内容はわかったので、前に戻って、
issuables_collectionの内容を読み解きます。

  def issuables_collection
    finder.execute.preload(preload_for_collection)
  end

「execute」「preload」は、いずれもRails組み込みのメソッドの様ですね

http://railsdoc.com/references/executerailsdoc.com

railsguides.jp


では、引数で指定されている「preload_for_collection」を見ていきます。

f:id:ryoutaku_jo:20190217121318p:plain

「collection_type」も、同じファイルに定義されています。

f:id:ryoutaku_jo:20190217121442p:plain

「finder_type」がIssueかどうかで、引数の値が変わる様です。
「finder_type」は、先ほど探し出した通り、「IssuesFinder」と定義されています。

preloadの仕組みが調べてもよく分かりませんでしたので、
かなり曖昧になりますが、finderで取得したデータに対して、
何らかのSQL文を実行して、データを取得していると考えられます。

そして、そこで得られたデータを、set_issuables_indexメソッドで@issuablesにセットして、
最終的にindexで@issuesに代入され、issuesの一覧表示が可能になっていると考えられます。

総括

最後はかなり無理矢理進めましたが、一応最後までindexアクションを
構造を読み進めました。正直、現在の知識で理解するのが難しい内容ですが、
ただ手を動かすだけでは得られないノウハウを実践レベルで知れたのは、
今後のスキルアップに大いに役立つと感じました。

コードリーディングは、今後も継続していきたいと思います。

《今日の学習進捗》

チーム開発:23日目
今日は私用の為、開発に参加できず。
移動中の高速バスでブログを書く。

学習開始からの期間 :72日
今日までの合計時間:752h
一日あたりの平均学習時間:10.5h
今日までに到達すべき目標時間:658h
目標との解離:94h
「10,000時間」まで、

残り・・・「9248時間!」