20191213_出張！Railsウォッチ in 銀座Rails#16

2019/12/13に銀座Rails#16で発表したスライドです。
https://ginza-rails.connpass.com/event/155467/
週刊Railsウォッチ: https://techracho.bpsinc.jp/tag/%e9%80%b1%e5%88%8arails%e3%82%a6%e3%82%a9%e3%83%83%e3%83%81

Transcript

1. 出張！Railsウォッチ
 in 銀座Rails#16
 森 雅智 / @morimorihoge 2019/12/13 1

2. About Me
 • 森 雅智： @morimorihoge
 • BPS株式会社でRailsの受託開発チームをやってたり、週1大学非常勤で Web開発を教えてたりします
 • Ruby/Rails歴は9年くらい。Web開発は15年くらい
 • 銀座Ralis #10でActiveRecordでVIEWを使おうという話をしました
 About BPS & TechRacho
 • Web受託開発や電子書籍製品開発をやっている会社です
 • TechRachoという自社技術Blogを運営しています
 ◦ 3年ほど前から平日毎日更新してます
 ◦ https://techracho.bpsinc.jp/ • お仕事相談、転職相談、TechRachoへのご意見など気軽にどうぞ
 ◦ https://www.bpsinc.jp/ 2

3. Railsウォッチとは？
 技術ブログTechRachoで毎週連載しているRails / Ruby界隈を中 心とした雑多な情報を提供する技術雑談マガジン
 3

4. @hachi8833（TechRacho編集部） • 八田昌三（はったしょうぞう） ◦ TechRacho 記事執筆・編集・翻訳（ 2016.08 〜） ◦ サイトメンテナンス ◦ ローカライズ業界出身 ◦ 好きなもの : 正規表現 /Go/Ruby/Goby など多数 • やってきたこと ◦ Rails チュートリアル翻訳・翻訳ディレクション ◦ Rails ガイド翻訳 ◦ Goby 言語メンテナー 4 ※今日はお休み
5. これまでの出張Railsウォッチのピックアップテーマ
 • Rails6新機能特集
 ◦ 銀座Rails#12: 複数DB対応
 ◦ 銀座Rails#13: ActionText、Trix
 ◦ 銀座Rails#14: ActionMailbox
 • Railsアプリケーション開発に関する雑多なテーマ
 ◦ 銀座Rails#15: production、development、staging環境につ いて
 5
 ※過去のスライドはTechRachoにて公開しています。「TechRacho 銀座Rails」あたりで 検索するとヒットしますので興味のある方はどうぞ

6. Ruby 2.7リリース迫る
 • 今年もクリスマス（すなわちRubyのリリース時期）が迫る！
 • パターンマッチ（exprimental）
 • @tmtms さんが怒涛のAdvent Calendar解説をしてたり
 ◦ https://qiita.com/advent-calendar/2019/ruby27 
 • @jnchito さんがパターンマッチのわかりやすい解説記事を出してくれています
 ◦ https://qiita.com/jnchito/items/9bb4aa1dcefa00257815 
 
 6

7. Rails: 6.0.2.rc2進行中＆5.2.4リリース
 • 11/5に6.0.1がリリースされたと思ったらもう6.0.2.rc2まできてました ◦ バグ修正や高速化が含まれるので、 Rails6利用者は追いかけるといいかも • 11/28に5.2.4もリリースされています。5.2ユーザーは上げましょう 7

8. 機能開発の設計レビューについて
 8

9. コードレビュー、やってますか？
 9
 • GitHubが普及してPull Requestベースの開発が標準となってきたWeb開発界隈で は、一般的にコードレビューが行われるようになった
 • 業務Rails界隈だとほとんどのプロジェクトで何らかのレビューは行われているので はないかと思われる
 • コードレビューのメリットやベストプラクティスについては先人の皆様が色々と記事 や本を出してくれているのでそちらを参照

10. 設計レビュー、やってますか？
 • 実装する前の設計時点でのレビュー、やっていますか？
 • 「コードを書いてPull Requestを出したけど、そもそも設計方針が間違っていると言 われて全部書き直しになってしまった」という経験は？
 • 文言修正やとても単純なバグ修正はともかく、ある程度大きな機能を実装する際に は設計レビューを行うと、手戻りのリスクを減らすことができる
 • 例えば以下のような機能は手戻りが発生すると影響範囲が大きくなりがち
 ◦ 会員登録・認証機能 
 ◦ 権限機能
 ◦ 証跡ログ機能
 ◦ API共通インターフェース 
 ◦ 外部システムデータ連携 
 ◦ などなど
 10

11. 機能要件の確定からPull Request作成まで
 僕はこんな感じで進めることが多いです。
 ※ここ最近は実装部分を他のメンバーにお願いすることが多い
 11

12. 実現方法の洗い出し
 • 後々になって「なんでこんな実装しちゃったんだ」とならないために大事
 • 最低でも２案は考えるようにしている。できれば３案以上出す
 • ググり力や普段からの情報収集、エンジニアとして開発経験値が効いてくるので、 思い浮かばなければ他の人にも聞いてみたりする
 12

13. 実現方法の洗い出しのコツ
 • 「一般的な解」をまずは探す
 ◦ Rails WayだったりメジャーGem だったり、一般的な問題であれば解法が見つかるはず 
 ◦ 「その問題に付いている名前」がわかるとググりやすい 
 • 問題の分解を試みる
 ◦ 大きい機能を作る場合、 複数の小さな機能の組み合わせ として見ることで、解法のパターンを増や せる
 ◦ 例：「ログイン機能」を「セッション管理」＋「ユーザー管理」として分解する、など 
 • その問題を含む、より大きな問題を解決できる方法を調べる
 ◦ 作りたい機能が一部として含まれる大きなライブラリやツール・サービスを利用 する
 ◦ 例：「ログイン機能」を実現するためにOAuthログインやSSOログインなどの認証サービスを検討す る、など
 13

14. 実現方法の検討と選択
 • それぞれの実現方法のメリット・デメリットを洗い出し、そのプロジェクトにどの方法 が一番フィットするのかを検討する
 • 複数案の中から根拠付きで方法を選択することで、潜在的なリスクや将来的な拡 張の可能性なども視野にした決定を行うことができる
 14

15. 実現方法の選択基準になり得るもの
 • ベストプラクティスがあるなら検討上位にする価値がある
 ◦ 多くの事例があるということはそれだけ枯れているということ 
 • システムの特殊性がある場合、その用途に特化したものも検討
 ◦ データの局所性が高 かったり、アクセス時刻の偏りが大きい サービスの場合はベストプラクティスが うまく行かないことがある 
 ◦ サーバーレス環境で動かしたい、インターネット接続不可 などの要件があると取り得る選択肢の幅 が一気に狭まることもある 
 • プロジェクトチームのスキルセットやリソースも検討
 ◦ 「誰かが使ったことのあるライブラリ」はフィジビリティ検証や調査・学習コストが抑えられる 
 ◦ バックエンドエンジニアとフロントエンドエンジニアのバランスや、インフラエンジニアの有無なども影 響する
 • プロジェクトの今後の計画を考慮
 ◦ 多機能なライブラリよりもシンプルなライブラリの方が障害時の追跡がしやすい利点 
 ◦ 将来的な拡張が決まっているならシンプルなライブラリよりも多機能なものを最初から入れてしまっ たほうが結果として手間が少なくなることも 
 15

16. 実装
 • Pull Request作成時、ソースコードだけではなく実現方法を選択した経緯も一緒に 記載することで、説得力のあるPull Requestになる
 • 実現方法の検討時に「動かしてみないと検証できない」という状態の場合はWIP PR として軽くフィジビリティ検証のための実装をしてみるというのもアリ
 16

17. その設計にした「理由」が説明できるか？
 • システム開発では「唯一の正解」は存在しないため「その時の状況からしてなるべく ベター」な選択をしていく必要がある
 ◦ 考えすぎるとYAGNI（Yet Ain't Gonna Need It）原則に反するので、損切りも大事 
 • Pull Requestの作成時に、自分の設計・実装を納得してもらうための「理由」を示す と良い設計レビューがしやすい
 ◦ プログラムコードのバグはソースを見ればわかるが、 設計の妥当性は背景や思想の説明がないと とてもやりにくい
 • 設計に関する議論はSlackやF2F MTGなど、プロジェクトチームに合った形でやれ ば良いが、必ずログやスケッチを残しておくこと
 ◦ 後から合流するかもしれないメンバーの設計理解 の役に立ったり、議論したという 証跡を残すことで 後々同じ話が蒸し返されないようにする ことができる
 17

18. 18
 残すPRやWikiなどに残すドキュメントの例 

19. 19
 検討した内容、及びそれらに対する評価 

20. 20
 検討結果と議論の内容の概要。 
 採用されなかった方式の理由なども 

21. 21
 将来的にプロジェクトのリスクや手戻りに繋 がりそうなリスクの共有 
 ※リスクの見える化と合意 

22. まとめ的なもの
 • 僕が設計周りを進める時にやっている考え方や進め方をまとめてみました
 • すべての開発にここまでやる必要があるかは微妙ですが、後々議論を呼びそうな ものはしっかり設計レビューしておくと、後々hateを生みづらくなると思います
 ◦ 「なんでこんな設計になってるんだ！！！」みたいなことを言ったり言われたりはみんな辛いですよ ね
 22

23. 補足：アンチパターンとは？
 23
 wikipedia: https://ja.wikipedia.org/wiki/アンチパターン より 

24. 宣伝：週刊Railsウォッチ 公開つっつき会
 • 毎月第一木曜日、社外の方も参加できる公開つっつき会を開 催してます
 ◦ 次回は2020/1/9（木）19:30～＠西新宿 BPS会議スペース にて（予定）
 • TechRachoの週刊Railsウォッチの最新記事、または「週刊 Railsウォッチ公開つっつき会」でぐぐってご参加下さい！
 24

25. 次回以降もブラッシュアップしていきます
 感想・リクエストなどあればTwitter
 #ginzarails
 @morimorihoge
 @hachi8833
 までお声かけください
 25