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

f:id:ryoutaku_jo:20190215233011p:plain

【結論】
・コードリーディングとは、
 他人が書いたコードを読み解くこと

・本格的なソフトウェアのコードを読む事で、
 多くのテクニックやノウハウの実践方法を理解できる

・大規模なコードは効果的な読み方を
 理解していないと、読み解くことが難しい


【目次】


【本題】

GitLabのコードリーディングをしてみた

本日参加した勉強会で、GitLabのコードリーディングをして来ました。

GitLabとは・・・オープンソースのGitリポジトリ管理ソフトウェア
         自前のサーバーにコードを保管できるので、
         セキュリティや情報管理の観点で、GitHubより優れている。

かなりの大規模なサービスなので、コードを読み解くのに苦労しましたが、
その中で、コードリーディングの効果を強く感じたので、今回はそれをまとめます。

コードリーディングとは

端的に言えば、他人が書いたコードを読み解くことです。
チーム開発する中で、他メンバーが書いたコードの仕組みを読み解いて、
開発を円滑に進める目的の他にも、オープンソースのコードを読む事で、
様々なテクニックやノウハウの実践方法を学ぶ効果も期待できます。

GItHubには良質なコードが大量に公開されているので、
それらを理解することが出来れば、更なるスキルアップに繋がります。

但し、大規模なサービスは、下記の理由などで、
コードを読み解くのが困難なケースが多いです。
・コード量が多い
・テクニックが複合的
・概念が新しい

特にコード量の多さは、参照元の情報が複数の別ファイルに亘っているケースと相まって、
コードリーディングの難易度を上げています。

その問題に対処するには、効果的なコードリーティングの手法を理解する必要があります。
では、実際にコードリーディングを進めてみます。

Issues機能を読み解く

今回は、下記のIssues機能のコードを読み解いて行きたいと思います。

f:id:ryoutaku_jo:20190215233103p:plain

この様に、Issuesが一覧で表示される機能です。
このIssuesを、どの様にデータベースから取得して来ているか調べます。

0:リポジトリをダウンロードする

コードリーディングをするにあたり、対象のリポジトリをダウンロードします。

github.com

なおターミナルで「git clone」コマンドを実行するのも方法ですが、
大規模プロジェクトの場合、直接ZIPファイルをダウンロードした方が早いそうです。

f:id:ryoutaku_jo:20190215234503p:plain

1:controllerを探す

まず、ビューにデータを渡しているcontrollerを特定します。
その際に、役立つのが「URL(パス)」です。

f:id:ryoutaku_jo:20190215233545p:plain

f:id:ryoutaku_jo:20190215233600p:plain

上のパスと、下の画像を見比べて見ると分かる通り、
パスは「アカウント名/リポジトリ名/Issues」という表記になっています。

一般的に一覧表示機能は「index」アクションで実装しますが、
その際のルーティングは、「〜/controller名」となるのが一般的です。

つまり、「Issues」というcontrollerを、まず探せば良いという事になります。

また「アカウント名/リポジトリ名/Issues」という様に、controller名の前に、
ホスト名以外のパスが表記されている事から、
controllerはフォルダ分けされて管理されている可能性が考えられます。

その点を踏まえて、コントローラーを探します。

f:id:ryoutaku_jo:20190215234530p:plain

f:id:ryoutaku_jo:20190215234551p:plain

f:id:ryoutaku_jo:20190215234607p:plain

という訳で見つかりました。
フォルダから探すときは、関連性が高そうな名前から探します。
または、検索機能で探す方法も便利です。

2:indexアクションを探す

一覧表示機能なので、indexアクションで定義されていると考えられます。
なので、まずindexアクションを探します。

f:id:ryoutaku_jo:20190215234911p:plain

見つかりました。
「@Issues」というインスタンス変数が、Issuesの一覧データだと考えられます。
では、このデータをどの様に取得しているのか調べます。

3:@Issuablesの定義元を探す

「@Issues」は「@Issuables」というインスタンス変数が代入されているので、
「@Issuables」がどういったデータなのか調べます。

indexアクション内で定義されていない@Issuablesを呼び出すには
before_actionを利用していると考えられるので、before_actionの中で、
最も関連性が高そうなメソッドを探します。

f:id:ryoutaku_jo:20190217111620p:plain

「set_issuables_index」という名前なので、これの可能性が高そうです。

なお、onlyで呼び出すアクションを指定していますが、
指定するアクションは「set_issuables_index_only_actions」というメソッドで定義されています。
このメソッドがindexを指定しているのか探ります。

f:id:ryoutaku_jo:20190217111929p:plain

同じファイルで定義されていました。
indexを指定しているので、こちらを深掘りして一先ず問題ないでしょう。

では、「set_issuables_index」「@Issuables」を調べて行きますが、
同じファイル内では定義されていませんでした。

その場合、別ファイルで定義されていると考えられます。
別ファイルで定義されている可能性がある場合は、別ファイルを読み込むための
「include」のコードを見ていきます。

f:id:ryoutaku_jo:20190215235709p:plain

この中で、最も関連性の高い名前のファイルから探していきます。
Issuesの一覧データという事で、「IssuableCollections」が最も関連性が高いので、そちらを見ます。

f:id:ryoutaku_jo:20190215235840p:plain

f:id:ryoutaku_jo:20190215235902p:plain

f:id:ryoutaku_jo:20190215235921p:plain

そうすると、「@issuables」を定義している
「set_issuables_index」というメソッドを発見しました。

総括

まだまだコードリーディングは始まったばかりですが、
ここからも相当なボリュームがあるので、続きは明日にします

このくらい大規模なコードをコードリーディングするのは
初めてだったので、かなり読み解くのに苦労しましたが、
手を動かしたり、技術書を読むだけでは得られない
実際の現場での活用法を知れたのは非常に良かったと感じます。

今後の学習にも取り入れて行きたいと思います。

《今日の学習進捗》

チーム開発:21日目
一通りの機能実装は完了する。
あとは細部の修正と、追加機能の実装をして完成。
新規登録機能のフォームをキーアップする!

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

残り・・・「9273時間!」