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

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

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

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

【目次】

【本題】

下記の記事の続きです。

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

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

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

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

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

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

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

これ以上「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」を見てみます。

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

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

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

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

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

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

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

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

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

  def issuables_collection
    finder.execute.preload(preload_for_collection)
  end

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

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

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

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

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

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

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

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