Ruby、Rails周りのコードレビュー時に先輩に指摘された点メモ
【Rails】Controllerに書く処理か、Modelに書く処理かを考えよう
この処理はModelに書くべきだ、Controllerに書くべきだという指摘が多かった。きちんとMVCの役割を捉えつつ、どこで処理するのが自然でわかりやすいかを考えよう。
【Rails】Enumを使おう
enum hoge: %i(foo bar baz)
のように書けば、テーブルのhoge
カラムの値(0, 1, 2)と対応しRails内ではfoo bar baz
として扱えるので数値を使うよりも意味合いを捉えやすい。この辺りが非常に参考になる。
いまさらながらRails4.1から導入されたEnumが便利なのでまとめてみた - Rails Webook
【Ruby】コメントはやっていることではなく背景を書こう
ちょっとこれはRubyに特化したものではないが、コード内のコメントはやっていることではなくて、なぜその処理が必要なのかや根拠などを記載する方がよい。例えば、
# 完了に更新 State.complete!
と書いてもそれはコードを見ればわかることなので、
# ここで完了に更新することで○○画面で非表示になる State.complete!
のようになぜこの処理をする必要があるのかなどを書くほうがよい。逆にそれ以外の場合はコメント書かなくて良いのでコード量を減らせる。
【Ruby】=
は左辺に右辺を代入しつつ右辺の値が返る
irb(main):001:0> hoge = 1 => 1
なので、
hoge = 1 if hoge puts hoge # => 1 end
は
if hoge = 1 puts hoge # => 1 end
と書けるよということ。
【Rails】Modelのscopeを活用しよう
Modelにscopeをで検索処理を書くとデフォルトで全レコードが返るので、条件が指定された時のみ絞るということができる。 参考:http://qiita.com/ishidamakot/items/7afa6630eee3f95513a6
scope :name_like, -> name { where('name like ?', "%#{name}%") if name.present? }
【Rails】ActiveRecord::Concernをつかうと便利
この辺り参考。
» ActiveSupport::Concern でハッピーなモジュールライフを送る TECHSCORE BLOG
ControllerやModelにActiveRecord::Concernを使ってメソッド定義をしておくとincludeすれば共通的に使えるので便利だったりする。
ペパボに入っての半年間で感じたこと
この記事はPepabo Advent Calendar 2015の23日目の記事です。
※技術系のエントリではありません。
GMOペパボ株式会社に2015年7月に入社して半年間たちました。ムームードメインのエンジニアとして働いています。入社3ヶ月で試用期間が終わり、やっと半年経ち来月から有給休暇が付与されます。この半年で感じたことなどを書いていきます。
スピーディーなリリースに感動
SIerに近い仕事をしていた頃は以下の様な流れが普通でした。
1. 仕様書作成(Excel) 2. 仕様書レビュー 3. テスト設計書作成(Excel) 4. テスト設計書レビュー 5. 実装 6. コードレビュー 7. 詳細テスト(UNITテスト) 8. 結合テスト(人間) 9. リリース
新卒で入った会社はこれに加えて各セグメントで承認作業があり、承認されないと次に進めなかったので更に工程が多かったです。
それが今のチームに入ってからはほぼ以下の流れです。
1. コードを修正 2. コードレビュー 3. テストが通ればリリース
仕様書は基本作りません。大きなサービス改修や機能追加の時などは仕様書を作りますが、まだそのような案件の開発には携わっていません。
コードを書く際には必ずUNITテスト、可能ならばE2Eテストを書き、E2Eテストが通っているならばそれをエビデンスにすることで人間がテストをしなくても良いルールになっています。
スピードが命
とにかくスピードを第一に仕事をすることができ、自分にとってはやりやすいです。偶然見つけた小さな不具合などもPull Requestを出してOKが出れば即リリースできるので、ユーザの良くないサービス体験を素早く改善できるところが楽しいです。
(Excelで仕様書を作るような仕事はしたくないと思っていたので、そういう環境で働けて良かった。。)
エンジニアの人数が少ない
入社する前はこれだけ大規模なWEBサービスなのだから、エンジニアの数も相当いると思っていました。しかし入社してみると少数でした。ちなみに現在ムームードメインのエンジニアは3人です。
ムームードメインは10年以上稼働しているサービスで、安定しているサービスだと思いますが、日々何かしらの不具合があったり、要望の対応であったりとタスクは常に途絶えません。それには少ないエンジニアでもまわせていける仕組みがしっかりとしていると感じています。
Github Enterprise
一番は全社的にGithub Enterpriseで仕事を進めるという点。
マネージャ、ディレクター、デザイナー、カスタマーサービスでも全てGithubのIssueとPull Requestで作業を管理しています。部門ごとに、ここはExcelしかダメ、紙でしかダメなどの差異がなく、Githubで統一されているというのは非常に仕事を進めやすいです。
文章はmarkdownで書かないといけないですが、エンジニア以外も皆使いこなしているのがすごいと思いました。
ディレクターが統計のためにSQLが書けたり、R言語が書けたりと、全社的に枠にとらわれずに仕事していこうという姿勢が見えて非常に良いと感じています。
幅広い知識が必要
エンジニアが少ない分、フロントエンド・データベース・ネットワーク・インフラなどのサービスを構成しているものは全て知っていないとやっていけません。コーディングができるだけではダメで、むしろ前述の知識を集結してコーディングに反映するべきです。ペパボに入社する前まではインフラの仕事は全くやっていないのでゼロからのスタートでしたが、できなくてもやってみるという姿勢で取り組むことで少しずつ知識が付いていることを感じています。
ペパボのコンセプトである「 いるだけで成長できる環境 」という環境は十分にあると思いますので、あとは自分の仕事への取り組み方次第だと思います。
改善していこうという気持ち
ペパボはWEBサービスとして10年を超えているサービスがいくつかあります。ただサービスとして止まっているものはなく、常に改善していこうという姿勢を内部からでも感じることができています。
ホスティングサービスでは例として以下の様なサービス向上が最近でも行われています。
ロリポップ! - モジュール版PHPに対応 lolipop.jp
ムームードメイン − HTTP/2に対応 muumuu-domain.com
8日目の記事で @pyama86 さんが書いていますが、既存のメールベースでのエラーチェックをログベースに変え、本当に必要なもののみSlackに通知することで埋もれがちだったエラーを素早く察知することができサービス改善することができるようになりました。
tech.pepabo.com
自分が知らないサービス向上は他サービスにもたくさんあります。
WEB業界は止まれば終わりなので、そのつもりで自分も継続してサービス改善していきたいと思っています。
まとめ
1エンジニアの視点でペパボを見ていて感じた良い点を挙げてみました。
主にムームードメインの話になっていますが、Slackのいろいろなチャンネルを見たりすると活発に議論が行われていて素晴らしいと感じます。このエントリを見て、少しでもペパボに興味を持っていただけたなら幸いです。
Gitコマンドについて調べる【git fetch】
git fetch
git fetch
は、リモートリポジトリの変更をローカルリポジトリに取り込みます。ローカルリポジトリには取り込みますが、ワーキングツリーには反映されませんので、現在編集中のファイルが変更されることはありません。
$ git fetch
引数なしで実行したとき、upstreamブランチの設定がない場合はデフォルトでoriginのリモートブランチをfetchします。リモートリポジトリ名、ブランチ名を指定する事もできます。
$ git fetch [リモートリポジトリ名] $ git fetch [リモートリポジトリ名] [ブランチ名]
例)
$ git fetch origin $ git fetch origin master
オプション
--all
すべてのリモートブランチをfetchします。
$ git fetch --all
-p
、--prune
リモートブランチで消去されたブランチをローカルブランチからも自動的に消すオプションです。masterブランチにマージされ消去したリモ^とブランチもgit fetch
するだけではローカルブランチからは消えません。ですので-p
または--prune
オプションでローカルブランチからも消去します。
$ git fetch -p $ git fetch --prune