Rails Developer Meetup に参加してきました【2日目】

はじめに

3月25日に開催されたRails Developer Meetup（2日目）に参加しました。
私が拝聴したセッションの内容の一部を簡単に紹介します。
1日目の記事はこちら

Rails Developer Meetup

2日目の会場は株式会社ドリコム様のオフィスの一角をお借りして行われました。
イベントの詳細は下記よりご確認ください。
http://techplay.jp/event/655769

また、資料につきましては下記のサイト様がまとめてくださっています。
https://qiita.com/dyoshimitsu/items/20a41ab656d2da80e4d9

それでは、当日の内容を振り返ります。

テストのないレガシーなRailsアプリをリファクタした話

株式会社スタディスト様のランチセッションでの発表です。

内容としては５年ほど前に開発したBtoB向けサービスのRailsのバージョンをおよそ半年かけて上げる際に行ったリファクタリングに関しての発表です。

なぜリファクタリングしたのか

Railsのバージョンを上げる際様々な箇所でエラーが発生します（e.g. 引数が変わった）
リファクタリングを行うことで対応箇所を減らすことができます。

リファクタリングでは下記の3つの要点があります。

1. コードを3種類に分類する
2. 処理をモデルに寄せる
3. 処理を共通化する

それぞれについて説明します。

コードを3種類に分類する

3種類とは、「必要かつ使用が明確な処理」、「不要な処理」、「（必要なのか）わからない処理」です。

「必要かつ使用が明確な処理」に関してはあるべき流れに沿って書き直しました。

「不要な処理」に関しては勿論削除しました。
ただし、メソッドは呼ばれているけれど実は呼び出し元も不要な場合があるので、本当に不要なのか確認するのが大変だったそうです。

「わからない処理」に関しては、本流とは別の場所にまとめて、不要だとわかったときに削除しました。

モデルに寄せる

モデルに寄せることでテストがしやすくなります（コントローラのテストは時間がかかる）
また、今後サービス層などを導入する際に処理を分離しやすくなります。

共通化

コントローラ感はconcernに、APIとWeb間はcommonに、モデル間はmoduleに共通の処理を記述していきます。

環境面の整理

コードの品質を上げるためにRubocopを導入し、プルリク時にSideCIで自動チェックするようにしました。

また、プルリクに関しては最低2人がOKを出すまでマージしないなど、ルール面を整備しました。

リファクタリング結果

コードの行数が約44,000行から約28,000行に削減され、テストコードの行数が6行から約3000行に増加しました。

知性の習得 – 新人研修内容の一考察

本発表は新人教育を行う方（メンター）の養成講座のような内容です。

新人教育では仕事のやり方などを教えますが、新人に本当に必要なのはいかにして学んでいくかという方法ではないかという考えから、知性とは何かということに関して考察します。

また、発表では最初に新人教育に当たっての参考書籍が紹介されていますので、初学者の方は一読をおすすめします。

知性とは

知性に関しては発表資料から引用します。

型と実践

知性は「型」と「実践」に分解することができます。

「型」と「知識」を野球に例えると、「型」はボールの投げ方やバットの振り方などの知識で「実践」は実際にボールを撃ってみる行為です。

見て学ぶは本当か

日々の観察からわかるのは結果であり、他にどんな「型」があって、なぜその「型」を使ったのかという理由まではわかりません。

研修で教えるべきは「実践」

「型」については座学で学ぶことができますが、「実践」はメンターがいる方がより理解が深まります。

FintechとRailsとgRPCと

株式会社お金のデザインのサービス（THEO）を例に、マイクロサービスの良さとgRPCのメリット・デメリットについての発表です。
全体的に駆け足の発表となりました。

個人的には一番おもしろいセッションだったので、資料の一読をお薦めします。

どのような開発チームが良いか

入出金や口座管理など高い可用性とセキュリティが求められる箇所はJava、UI/UXの部分はRailsやVue.js、市場で証券を売買する部分はC++などそれぞれ得意な分野を担当する。

どのように各サービスをつなぐか

ここで登場するのがgRPCです。

APIの設計方針としてREST、RPCが、データの表現形式としてJSON、Protocol Buffersなどがあります。
登壇者曰く、RESTとRPCの違いの一つとして「APIの設計時にどこに着目するか」が挙げられます。

RESTではリソースに着目し、RPCではアクションに着目します。
RESTの方が向いているケースとしてCRUD、RPCの方が向いているケースとしてSlackのようなチャットサービスのAPIが挙げられていました。

チャットサービスを例にしたAPI

ユーザがあるチャンネルから退出するアクションをleave、あるユーザをチャンネルから追放するアクションをkickとすると、leaveとkickを綺麗なRESTで表現するのは難しいです。

これらをRPCで表現すると下記のようになります。

URL: https://example.com/api/leaveFromChannel
body: { "channel_id": 123, "user_id": 456 }

URL: https://example.com/api/kickFromChannel
body: { "channel_id": 123, "user_id": 456 }

gRPCでの表現形式

デフォルトではProtocol Buffer（Protobuf）が採用されています。
Protobuf大きなのメリットしては下記が挙げられます。

• 型がある
• messageに相当するクラスが自動生成される
• 違うチームの開発者ともコミュニケーションしやすい

反面デメリットとしは下記が挙げられます。

• curlなどで手軽に試せない
• 確認のために簡単なクライアントを書く必要がる

RailsへのgRPCの導入

導入に関しましては発表資料を御覧ください。

さいごに

一番興味を持ったのはgRPCでした。
gRPCに関してはなかなか使う機会が無いのですが、ぜひ使ってみたいと思います。