3日連続 nazoです。
昨年から行っているチャレンジとして、Ruby on RailsによるWebサービスの開発があり、それが一段落しましたので、経緯と結果について報告させて頂きたいと思います。
なぜRuby on Railsにしたのか
それまでは PHP + Symfony2 での開発がメインだったのですが、完全新規のWebサービス開発の案件が始まるということで、技術調査を行うことにしました。訳あって決定権は私にあったのですが、技術調査を行う前に、まずジョイン予定メンバーから、どんな技術を使ってみたいか、アンケートを取ることにしました。
結果を見ると、Railsが多いということがわかりましたが、今からRailsは技術チャレンジとして適切なのか？と考え、第二案であるAngular2+Goを調査しました。しかし、Goはともかく、調査当時（2016年6月）のAngular2はリリース前で、かつ、RCの状態から大幅な改修が入っていたこともあり、「恐らく大丈夫だとは思うが、本当にこれと心中して大丈夫なのか？」という感想になり、見送ることにしました。現在ならまた別の判断になるかもしれません。
またそれ以外にも、「そもそもSPAが必要なサイトなのか？」とか「Goの他メンバーの経験の少なさを納期的にカバーできるか？」という問題もあったので、今回は見送ることにしました。
そして、第一候補だったRuby on Railsに戻ります。当時5.0が出る前後だったので、タイミング的に丁度よく、かつ「ノウハウが足りなくても検索すると何か出てくるだろう」というユーザー数の多さを理由に採用することにしました。
まとめると
- 普及度が高い
- メンバーからのリクエスト
という２点によるものです。
これ以外にも、インフラレベルで面倒が見れるかという点も焦点になりますが、そこは複雑な仕組みにしなければ大丈夫だろうと判断し、採用しました。
その判断ロジックは正しいのか？
技術選定についての議論はいくつかありますが、私は「業務を完遂できること」が最優先だと考えています。その中で、出来る限りの有意義なチャレンジを用意するというのが、正しい技術選定ではないでしょうか。
今更Railsということもあり「UUUMは技術チャレンジをしない会社なのか？」と思われてしまうかもしれませんが、Rails経験が少ないメンバーがRailsに挑戦するのも十分なチャレンジだと思いますし、その中で行われたことは言語の選択問わず有用な経験になっていると思います。
行ったこと
コード品質に関わることは最初に行う
まず行ったのが、rubocop 等の静的検査の整備、テスト及びCIの準備などです。とにかくメンバーが入ってきた時に品質をブレなくさせることが重要です。
rubocopは、onkcop をベースにカスタマイズしたルールを使用しております。overcommitを使うことによって、全員がコミット前チェックするようになり、コードレビューでの手間が大幅に削減されました。また、ルールについては、「ルールのためにソースを修正することがあまりに多い」のは不毛なので、適宜見直しを行っています。さらにovercommit を入れることにより、CIまで回さなくても静的検査を各メンバーが自主的に行えるようになっており、CIで静的検査に引っかかることはほぼない状態になっています。
テストはminitest とpower_assert の組み合わせで行うことにしました。RailsでのテストといえばRSpecのほうが有名ですが、RSpecは最終的なコードの可読性は高いものの、書くために文法を覚えるコストが高いので、assert { ... }だけ覚えれば書けるという手軽さを重視しました。テストの書き方について聞かれることはほとんどなかったと思います。
また、初期の時点である程度のテストを書いておくことで、メンバーが入ってきた時にテストの書き方がわかるようになります。このあたりを序盤でしっかり時間をかけておくと、後半でもペースが落ちなく、クオリティを保ったまま開発を続けることができます。
フロントエンドについて
今回の案件はあまりフロントエンドで凝ったことをするものではないので、SPAなどのような凝ったものは導入していません。パイプラインもSprockets任せにすることで、初期の環境構築の手間を削減しています。
フロントエンドのライブラリの導入はnpmに任せてます。またturbolinksは辛かったので切りました。
フロントエンドに関しては様々な議論が展開されていますが、通常のWebアプリケーションでそこまで凝った動作をするものでなければ、無難にRailsに乗っかっておいたほうがいいのではないかと思います。特にリリース初期で凝るのはYAGNI原則違反になる可能性が高いので、初期はRailsに乗っかっておき、サービスが成長してフロントエンドの重要性が高まってきたらRailsから切り離すというような運用が良いのではないかと思います。
とにかく責任を持つ
フレームワークや周辺ライブラリを選定した人は、その選定に一定の責任を持つ必要があります。もちろん、Railsのような巨大フレームワークを全て把握しておけというのは難しいですが、「何故それを選んだのか」「それを使うことによりどのようなメリットがあるのか」「他のものでは駄目だったのか」「メンテナンスされているのか・今後もメンテナンスされる見込みがあるのか」というのを的確に説明できる必要があります。特に、既製品があるにも関わらず自作するような場合は注意が必要です。
良かったこと
ぐぐると情報が出る
当初の狙い通りですが、さすが有名フレームワークだけあって、情報がとにかく多いです。ほとんどのケースで検索だけで解決することが多く、コミュニティの層の厚さを実感することができました。技術者としては未知の技術を開拓していくという楽しみもありますが、短時間で効率よく開発するためには良かったと思います。
ライブラリが充実している
とにかく有用なライブラリが多く、開発の快適さは圧倒的でした。特に開発時のデバッグなどで効果を発揮するライブラリが充実しており、問題が起こった時でもすぐ調査することができました。
良くなかったこと
ソースが追いづらい
Rubyの仕様上の問題ですが、困った時に該当の定義がどこにあるのかというのが非常に追いづらいです。ブレークポイントなどのデバッグ機能をフル活用することでカバーできるものの、やはりRails本体のコードを追ったりする時は辛いと感じました。
ライブラリが多すぎる
githubでスターが多いライブラリでも、有用でないもの、バグがあるものなど、使えないもの、最新バージョンに対応していないようなものが多く、自作したほうが良かったものもいくつかあります。
Railsに慣れるのが大変
いわゆるRails Wayがわからず、苦労されられることが多いと感じました。メンバーが揃って口にするのは「慣れるまでは大変だけど、慣れると楽」ということです。
まとめ
我々のような少人数ベンチャー企業で、スピード感を出して開発するにはRailsは最適ではないかと思います。逆に、一般的なWebアプリケーションでないもの、最初から大規模・高負荷になりそうなものは、Railsでできなくはないものの、他の選択肢も検討すべきかと思います。
RubyであればRails一択かと思いますが、もちろん他言語を選択してはいけないというわけではないので、結局はチームメンバーの希望を重視しつつ、筋の良い選定をするということが重要になるのではないでしょうか。今回は特にメンバーの希望を重視したため、メンバーからは好評でした。
UUUMでは、これからもエンジニア全員で話し合って、適切なチャレンジを行っていきたいと思います。