Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ふつうの
Railsアプリケーション開発
2017-06-22
Rails Developers Meetup #2
大仲 能史 a.k.a. @onk
自己紹介
• 大仲 能史 a.k.a. @onk
• 株式会社ドリコム
• Railsエンジニア歴8年ぐらい
– 1.2.6から触り始めた
– 本格的にproductionで使ってるのは3.0から
1
過去のRailsっぽい発表
2
https://www.slideshare.net/takafumionaka/
今日の話
ふつうのRailsアプ
リケーション開発
3
ふつうの、とは
Railsエンジニアが
Railsエンジニアらしい
作業に集中できる
4
例えば
•bin/setup
•bin/update
知っている人ノシ
5
bin/setup
git clone後に
これを叩くだけで
すべての準備が整う
6
bin/update
git pull後に
これを叩くだけで
すべての準備が整う
7
別の方法でも構わない
docker-compose up –d
でも構わないが、
1コマンドで開発環境が
立ち上がるのが大事
8
bin/setup, bin/update
READMEに環境構築手順
を細かく書いて伝える作
業から解放される
楽にするための努力を惜
しむな
9
みたいな話をします
よろしくお願いします
<(_ _)>
10
simpleとeasy
11
simpleとeasy
simpleとeasyの違いを
知っている人ノシ
12
simpleとeasy
simple
設計に筋が通って
すっきりしていること
easy
使うときに
簡単・便利だということ
13
simpleとeasy
simple
絶対的な概念
easy
相対的な概念
14
simpleとeasy
simple
絶対的な概念
easy
相対的な概念
15
easyかどうか
使う人のコンテキストによって
変わる
今までに触れたことのある概念
に近いとeasyと感じる
16
easy=驚き最小の原則
最近言わなくなりましたね
その人のバックグラウンドに
よって驚き最小かどうかが変わ
るので、設計哲学として成立し
づらい
17
コンテキストによってeasyな例
FileUtils.rm_f(list)
シェルのコマンド体系に慣れて
る人ならrm -fとすぐに分かる
18
コンテキストによってeasyな例
FileUtils.rm_f(list)
シェルのコマンド体系に慣れて
る人ならrm -fとすぐに分かる
FileUtils.rm(list, force:
true) と同じ
19
simpleとeasyの例
kaminari gem v1.0.0
kaminari-core
kaminari-activerecord
kaminari-actionview
kaminari-mongoid
kaminari-sinatr...
simpleとeasyの例
各環境向けのコードをプラグイ
ンとして切り出すことでコアの
設計指針をsimpleに保つ
導入や使い方のeasyさはプラグ
イン側で担保する
21
simpleとeasyの他の例
同じプラグイン機構でも、
某認証系のgemはeasyだけど
simpleではないかもしれない
すべての要望を満たすライブラ
リはsimpleを保ちづらい
22
Railsとeasy
23
Railsとeasy
Railsはもともとeasyであること
を目指しているフレームワーク
24
Railsとeasy
90%のことをうまくやる [要出典]
出典忘れたし、80%だったかもしれないので
後で誰か教えてください<(_ _)>
残り10%はeasyにはできないこ
とが分かっているので本体では
対応しない
25
Railsとeasy
CoCは「規約を知ってる人」に
とってeasyになる仕組み
何がどこにあるか分かる
設定を書かなくてよい
26
最近見た象徴的な例
shared section of secrets.yml
Rails v5.1.0から
config/secrets.ymlにshared機
能が増えてる
27
https://github.com/rails/rails...
shared section of secrets.yml
# shared:
# api_key: a1B2c3D4e5F6
development:
...
test:
...
production:
...
28
shared section of secrets.yml
Rafael
「独自ルール持ち込まなくても
普通のYAMLで十分じゃね?」
29
default: &default
api_key: 3b7cd727
development:
<<...
shared section of secrets.yml
DHH
「その書き方ないわー。マジ分
かりづらいし見つけづらい」
「でも書けなくするわけじゃな
いから、YAMLに則りたいなら
そうすればええんちゃう」
30
ここから分かること
一般的でなくても、使うときに
よりeasyになるなら取り入れて
いく姿勢=Rails Way
31
Rails is opinionated framework
認識を合わせて、共通認識のも
とでeasyであることで加速しよ
うというフレームワークを僕た
ちは使っている
Rails Wayに全力で乗っかるこ
とで、easyになる
32
simpleでなくても良いの?
simpleなライブラリを組み合わ
せたり、simpleなライブラリに
薄いwrapperをかませたりする
ことでeasyにすることができる
easyを目指してsimpleを捨てる
わけではない。両方取る。
33
ここまでのまとめ
• 「ふつう」とは何か (再定義)
– 共通認識のもとでeasyになっていること
• simpleとeasy
– easyはsimpleの上に成り立っている
– easyを維持しているのが良いRailsアプリケー
ションだと言...
ドリコムとeasy
35
WillPaginate2Kaminari
Kaminariへの移行時の注意点
ARとArrayで書き方が違う
36
# AR の場合
User.page(params[:page])
# Array の場合
array = Array(100...
WillPaginate2Kaminari
Arrayでも同じメソッドで使え
るようにして移行を簡単に
37
# AR の場合
User.paginate(page: params[:page])
# Array の場合
array = Arr...
to_id
38
class Integer
def to_id
self
end
end
class String
def to_id
Integer(self)
end
end
class ActiveRecord::Base
def to...
to_id
必ずidにできる安心感
AR本体で対応してるので不要では
ある
39
class Book < ActiveRecord::Base
scope :author_is, ->(author) {
where(author_id: a...
count_by
どのユーザにいくら詫び石を配
れば良いのかを集計するのによ
く使っていた(過去形
40
%w[a a b c c c].count_by(&:itself)
# => {"a"=>2, "b"=>1, "c"=>3}
activerecord-unsigned-column-
ext
create_table, referencesに
何もオプションを書かなくても
主キーが必ずunsigned bigint
になる
41
activerecord-turntable
アプリケーションが何も指定し
なくても水平分散できる痛みの
少ない複数DB
SQLをパースしてuser_idを取り
出し、自動的に接続するDBを決
定する
42
ユーザ認証
自作はするが、業界スタンダー
ドとインタフェースを合わせる
current_userでログインユー
ザが取れるとか、
authenticate_user!で強制的
にログインさせるとか
43
(ちょっと休憩)
44
ここからのアジェンダ
共通認識を作る
easyを作る
easyを作る体制を作る
45
共通認識を作る
46
まずは個人で始める
自分の認識と、世の中の一般的
なRailsエンジニアとの認識を合
わせる
47
大量にインプットする
はてブ、Qiita、StackOverflow
等を「Ruby」「Rails」で購読
し、眺める
眺めていると感覚が身に付く
定番ライブラリの使い方
ハマりがちな罠
48
bundle update当番
使っているgemがどんなもので、
どのように開発しているのかを
眺める
面白いし、興味が沸くのでgem
と仲良くなれる
人に注目するようになる
49
野良コードレビュー
社内の複数アプリを全体的に眺
め、同じ轍を踏まないようにと
か便利そうだったら横展開とか
「同じ指摘を何度か見たぞ」と
いう共通認識が増えていく
50
野良コードレビュー 頻出
NOT NULL制約
UNIQUE INDEX
51
野良コードレビュー 頻出
DateTimeは使わない
Time - DateTimeでエラーに
なったりDateTime -1で1日減っ
てしまったりして罠が多い
52
野良コードレビュー 頻出
同値比較したいならeqです。同
一性を比較したい時だけbeを使
いましょう
ruby2.4からはIntegerなので、
Fixnumの同一性に頼るのは避け
たい
53
野良コードレビュー 頻出
ユーザの持ち物は必ずcurrent_userか
ら関連を辿って取得する
where(user_id: current_user.id)
はミスすると他人の持ち物が見えてし
まったりするので。
Friendshipでsr...
野良コードレビュー 頻出
UserItem, UserActivity等、クラ
ス名のprefixとしてUserを付け
ることでルール違反に気づきや
すくしている。クラス名が現れ
た瞬間に大抵ミス
(ASTで違反チェックできそう……
55
重複コードをライブラリ化
社内gemをバンバン作り、同じ
gemを使うことでコードの書き
方が似ていく
「見慣れた書き方かどうか」と
いう共通認識が増えていく
56
最後まで直しきる
「一部だけ導入して残りは順
次」だと、共通認識にたどり着
けない
数百ファイルぐらいなら気合い
で直そう。やっていきです
57
複雑なことをしない
Controller, Model, View,
FormObject以外はほとんど使
わない
Service層はやりきる覚悟があ
るなら使ってよし
58
OSSの文脈に乗る
• コード規約がある
– onkcop
• テストがある
– rake (default task) でテストが走る
• CIが回っている
– rubocop, rspec, deploy
• READMEにバッヂを載せる
...
easyを作る
60
発生しないようにする
効果的なのはAとC
Aは自動化、Cはそもそも発生
しないようにする
61
自動化の鬼になる
手順書を見かけたら自動化可能
だと思え
まずは自動化を考え、全自動が
無理ならせめてスクリプト化
スクリプト名とEnter以外を叩
きたくない
62
時間がかからないようにする
時間は全員に共通する原資
例えばdb:migrate:resetでは
なくdb:setupを使う
複数DB環境でdb/schema.rbを
整備し続けるのは少し努力が必
要だが、やる
63
デフォルト値を入れる
書きたくないものを書かなくて
も良いようにしたい
とはいえ書き忘れが不具合に繋
がるものは早期にエラーになる
ようにする(バランス
64
デフォルト値を入れる
例えば認証をbefore_actionで
やっているなら、
ApplicationControllerに書けな
いかを考える
only指定だと漏れたときに困る
ので安全に振る理由もある
65
一般的かどうかを意識する
判断基準の大本に常に「この書
き方は一般的かどうか」を持つ
逸脱するときは、共通認識のも
とでeasyかどうかで殴り倒す
冒頭で紹介したDHHを思い
出して自らに乗り移らせる
66
コミュニケーションの境目
コミュニケーションコストの改
善はとても考えやすい
会話しなくても進められるよう
に、パラレルにするには何が
整っていれば良いのかを考え、
そう動けるようコードを変える
67
コミュニケーションの境目
クライアント・サーバー間のイ
ンタフェースをYAMLで定義し
て、このYAMLさえあれば開
発・検証ができるようにすると
か
68
easyを作る体制を
作る
69
“木を切り倒すのに8時間与え
られたとしたら、斧を研ぐの
に6時間使うだろう”
70
Abraham Lincoln
楽をするための努力を惜しまない
未整備による無駄なコストを避
けるために、有限時間内で最大
の準備をしたい
また、イテレーションで分かっ
た内容をもとにどんどん改善し
ていきたい
71
足回りは最初に整える
「これを保っていれば速度が落
ちない」という最低ラインを
持って、それを守れる環境づく
りを行う
これを一言で言うと「ふつう」
になる
72
足回りは最初に整える
テスト
もちろん書く
テストがないとPRマージし
ないのが「ふつう」
73
足回りは最初に整える
CI/CD
もちろん回す
継続的にデプロイし続けら
れるのが「ふつう」
74
足回りは最初に整える
メトリクス
もちろん取る
エラーやパフォーマンスを
継続的にチェックできるの
が「ふつう」
75
足回りは最初に整える
Chat連携
通知が一か所に集まってく
る仕組みを導入する
気づける、即対応できるの
が「ふつう」
76
足回りは最初に整える
Issue/Pull Request
テンプレートを書いておく
すべてのPRについてWhyが
分かるのが「ふつう」
77
simpleに始める
ブランチ運用
GitHub Flow
78
simpleに始める
routes
REST準拠を最初に考える
schema
正規化を崩さない
counter_cacheの無い状態
でまず作る
79
改善が回る環境づくり
ふりかえり
どうだったらもっと生産的
だったかをイテレーショ
ンごとに考える
80
改善が回る環境づくり
改善工数の確保
思いついた改善を入れるた
めに毎週数時間を使えるよ
う、チームにネゴっておく
81
改善が回る環境づくり
定点観測
取得しているメトリクスが
悪化傾向にないかの確認
改善が回っていない環境
だと絶対に悪化している
82
まとめ
83
まとめ(1/3)
• 「ふつう」とは何か
– 共通認識のもとでeasyになっていること
• simpleとeasy
– easyはsimpleの上に成り立っている
– easyを維持しているのが良いRailsアプリケー
ションだと言える
• e...
まとめ(2/3)
• 共通認識を作る
– まとまったインプットを入れて自分の中で基
準を持つ
– 「見たことがある」から雰囲気を醸成する
• easyを作る
– 繰り返してはならない、を刷り込む
– 一般的かを意識して書く
• それしか書けない...
まとめ(3/3)
• easyを作る体制を作る
– どうあれば「ふつう」なのかの基準がもうあ
るはずなので、そこに辿り着けるようにする
– 準備に時間を掛けるのを許容する
• 走りながら考えるのも大事なのでバランス
– 改善・挑戦がチーム課題に...
まとめ
今日の内容、一つ一つの「ふつ
う」は聞いたことのある話だっ
たと思う
87
ふつうの、とは(再掲)
Railsエンジニアが
Railsエンジニアらしい
作業に集中できる
88
まとめ
「ふつうのRailsアプリケーショ
ン開発」とは、どこかで見聞き
したことのある、現状の自分た
ちの状況より良さそうな開発環
境に辿り着く努力をし続けるこ
と
89
Upcoming SlideShare
Loading in …5
×

ふつうのRailsアプリケーション開発

23,824 views

Published on

2017-06-22 Rails Developers Meetup #2

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Download this 3-step guide to generating insane amounts of media coverage for your from LinkedIn: http://bit.ly/linkedin3stepguide
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

ふつうのRailsアプリケーション開発

  1. 1. ふつうの Railsアプリケーション開発 2017-06-22 Rails Developers Meetup #2 大仲 能史 a.k.a. @onk
  2. 2. 自己紹介 • 大仲 能史 a.k.a. @onk • 株式会社ドリコム • Railsエンジニア歴8年ぐらい – 1.2.6から触り始めた – 本格的にproductionで使ってるのは3.0から 1
  3. 3. 過去のRailsっぽい発表 2 https://www.slideshare.net/takafumionaka/
  4. 4. 今日の話 ふつうのRailsアプ リケーション開発 3
  5. 5. ふつうの、とは Railsエンジニアが Railsエンジニアらしい 作業に集中できる 4
  6. 6. 例えば •bin/setup •bin/update 知っている人ノシ 5
  7. 7. bin/setup git clone後に これを叩くだけで すべての準備が整う 6
  8. 8. bin/update git pull後に これを叩くだけで すべての準備が整う 7
  9. 9. 別の方法でも構わない docker-compose up –d でも構わないが、 1コマンドで開発環境が 立ち上がるのが大事 8
  10. 10. bin/setup, bin/update READMEに環境構築手順 を細かく書いて伝える作 業から解放される 楽にするための努力を惜 しむな 9
  11. 11. みたいな話をします よろしくお願いします <(_ _)> 10
  12. 12. simpleとeasy 11
  13. 13. simpleとeasy simpleとeasyの違いを 知っている人ノシ 12
  14. 14. simpleとeasy simple 設計に筋が通って すっきりしていること easy 使うときに 簡単・便利だということ 13
  15. 15. simpleとeasy simple 絶対的な概念 easy 相対的な概念 14
  16. 16. simpleとeasy simple 絶対的な概念 easy 相対的な概念 15
  17. 17. easyかどうか 使う人のコンテキストによって 変わる 今までに触れたことのある概念 に近いとeasyと感じる 16
  18. 18. easy=驚き最小の原則 最近言わなくなりましたね その人のバックグラウンドに よって驚き最小かどうかが変わ るので、設計哲学として成立し づらい 17
  19. 19. コンテキストによってeasyな例 FileUtils.rm_f(list) シェルのコマンド体系に慣れて る人ならrm -fとすぐに分かる 18
  20. 20. コンテキストによってeasyな例 FileUtils.rm_f(list) シェルのコマンド体系に慣れて る人ならrm -fとすぐに分かる FileUtils.rm(list, force: true) と同じ 19
  21. 21. simpleとeasyの例 kaminari gem v1.0.0 kaminari-core kaminari-activerecord kaminari-actionview kaminari-mongoid kaminari-sinatra 20
  22. 22. simpleとeasyの例 各環境向けのコードをプラグイ ンとして切り出すことでコアの 設計指針をsimpleに保つ 導入や使い方のeasyさはプラグ イン側で担保する 21
  23. 23. simpleとeasyの他の例 同じプラグイン機構でも、 某認証系のgemはeasyだけど simpleではないかもしれない すべての要望を満たすライブラ リはsimpleを保ちづらい 22
  24. 24. Railsとeasy 23
  25. 25. Railsとeasy Railsはもともとeasyであること を目指しているフレームワーク 24
  26. 26. Railsとeasy 90%のことをうまくやる [要出典] 出典忘れたし、80%だったかもしれないので 後で誰か教えてください<(_ _)> 残り10%はeasyにはできないこ とが分かっているので本体では 対応しない 25
  27. 27. Railsとeasy CoCは「規約を知ってる人」に とってeasyになる仕組み 何がどこにあるか分かる 設定を書かなくてよい 26
  28. 28. 最近見た象徴的な例 shared section of secrets.yml Rails v5.1.0から config/secrets.ymlにshared機 能が増えてる 27 https://github.com/rails/rails/commit/e530534265
  29. 29. shared section of secrets.yml # shared: # api_key: a1B2c3D4e5F6 development: ... test: ... production: ... 28
  30. 30. shared section of secrets.yml Rafael 「独自ルール持ち込まなくても 普通のYAMLで十分じゃね?」 29 default: &default api_key: 3b7cd727 development: <<: *default
  31. 31. shared section of secrets.yml DHH 「その書き方ないわー。マジ分 かりづらいし見つけづらい」 「でも書けなくするわけじゃな いから、YAMLに則りたいなら そうすればええんちゃう」 30
  32. 32. ここから分かること 一般的でなくても、使うときに よりeasyになるなら取り入れて いく姿勢=Rails Way 31
  33. 33. Rails is opinionated framework 認識を合わせて、共通認識のも とでeasyであることで加速しよ うというフレームワークを僕た ちは使っている Rails Wayに全力で乗っかるこ とで、easyになる 32
  34. 34. simpleでなくても良いの? simpleなライブラリを組み合わ せたり、simpleなライブラリに 薄いwrapperをかませたりする ことでeasyにすることができる easyを目指してsimpleを捨てる わけではない。両方取る。 33
  35. 35. ここまでのまとめ • 「ふつう」とは何か (再定義) – 共通認識のもとでeasyになっていること • simpleとeasy – easyはsimpleの上に成り立っている – easyを維持しているのが良いRailsアプリケー ションだと言える • easyだとどうなるか – 消耗しづらく、実装に集中できる – 「普通にやれば普通にうまくいく」状態 34
  36. 36. ドリコムとeasy 35
  37. 37. WillPaginate2Kaminari Kaminariへの移行時の注意点 ARとArrayで書き方が違う 36 # AR の場合 User.page(params[:page]) # Array の場合 array = Array(100) Kaminari.paginate_array(array).page
  38. 38. WillPaginate2Kaminari Arrayでも同じメソッドで使え るようにして移行を簡単に 37 # AR の場合 User.paginate(page: params[:page]) # Array の場合 array = Array(100) array.paginate(page: params[:page])
  39. 39. to_id 38 class Integer def to_id self end end class String def to_id Integer(self) end end class ActiveRecord::Base def to_id self.id end end
  40. 40. to_id 必ずidにできる安心感 AR本体で対応してるので不要では ある 39 class Book < ActiveRecord::Base scope :author_is, ->(author) { where(author_id: author.to_id) } end
  41. 41. count_by どのユーザにいくら詫び石を配 れば良いのかを集計するのによ く使っていた(過去形 40 %w[a a b c c c].count_by(&:itself) # => {"a"=>2, "b"=>1, "c"=>3}
  42. 42. activerecord-unsigned-column- ext create_table, referencesに 何もオプションを書かなくても 主キーが必ずunsigned bigint になる 41
  43. 43. activerecord-turntable アプリケーションが何も指定し なくても水平分散できる痛みの 少ない複数DB SQLをパースしてuser_idを取り 出し、自動的に接続するDBを決 定する 42
  44. 44. ユーザ認証 自作はするが、業界スタンダー ドとインタフェースを合わせる current_userでログインユー ザが取れるとか、 authenticate_user!で強制的 にログインさせるとか 43
  45. 45. (ちょっと休憩) 44
  46. 46. ここからのアジェンダ 共通認識を作る easyを作る easyを作る体制を作る 45
  47. 47. 共通認識を作る 46
  48. 48. まずは個人で始める 自分の認識と、世の中の一般的 なRailsエンジニアとの認識を合 わせる 47
  49. 49. 大量にインプットする はてブ、Qiita、StackOverflow 等を「Ruby」「Rails」で購読 し、眺める 眺めていると感覚が身に付く 定番ライブラリの使い方 ハマりがちな罠 48
  50. 50. bundle update当番 使っているgemがどんなもので、 どのように開発しているのかを 眺める 面白いし、興味が沸くのでgem と仲良くなれる 人に注目するようになる 49
  51. 51. 野良コードレビュー 社内の複数アプリを全体的に眺 め、同じ轍を踏まないようにと か便利そうだったら横展開とか 「同じ指摘を何度か見たぞ」と いう共通認識が増えていく 50
  52. 52. 野良コードレビュー 頻出 NOT NULL制約 UNIQUE INDEX 51
  53. 53. 野良コードレビュー 頻出 DateTimeは使わない Time - DateTimeでエラーに なったりDateTime -1で1日減っ てしまったりして罠が多い 52
  54. 54. 野良コードレビュー 頻出 同値比較したいならeqです。同 一性を比較したい時だけbeを使 いましょう ruby2.4からはIntegerなので、 Fixnumの同一性に頼るのは避け たい 53
  55. 55. 野良コードレビュー 頻出 ユーザの持ち物は必ずcurrent_userか ら関連を辿って取得する where(user_id: current_user.id) はミスすると他人の持ち物が見えてし まったりするので。 Friendshipでsrcとdstを間違えるミスに も繋がる 54
  56. 56. 野良コードレビュー 頻出 UserItem, UserActivity等、クラ ス名のprefixとしてUserを付け ることでルール違反に気づきや すくしている。クラス名が現れ た瞬間に大抵ミス (ASTで違反チェックできそう…… 55
  57. 57. 重複コードをライブラリ化 社内gemをバンバン作り、同じ gemを使うことでコードの書き 方が似ていく 「見慣れた書き方かどうか」と いう共通認識が増えていく 56
  58. 58. 最後まで直しきる 「一部だけ導入して残りは順 次」だと、共通認識にたどり着 けない 数百ファイルぐらいなら気合い で直そう。やっていきです 57
  59. 59. 複雑なことをしない Controller, Model, View, FormObject以外はほとんど使 わない Service層はやりきる覚悟があ るなら使ってよし 58
  60. 60. OSSの文脈に乗る • コード規約がある – onkcop • テストがある – rake (default task) でテストが走る • CIが回っている – rubocop, rspec, deploy • READMEにバッヂを載せる 59
  61. 61. easyを作る 60
  62. 62. 発生しないようにする 効果的なのはAとC Aは自動化、Cはそもそも発生 しないようにする 61
  63. 63. 自動化の鬼になる 手順書を見かけたら自動化可能 だと思え まずは自動化を考え、全自動が 無理ならせめてスクリプト化 スクリプト名とEnter以外を叩 きたくない 62
  64. 64. 時間がかからないようにする 時間は全員に共通する原資 例えばdb:migrate:resetでは なくdb:setupを使う 複数DB環境でdb/schema.rbを 整備し続けるのは少し努力が必 要だが、やる 63
  65. 65. デフォルト値を入れる 書きたくないものを書かなくて も良いようにしたい とはいえ書き忘れが不具合に繋 がるものは早期にエラーになる ようにする(バランス 64
  66. 66. デフォルト値を入れる 例えば認証をbefore_actionで やっているなら、 ApplicationControllerに書けな いかを考える only指定だと漏れたときに困る ので安全に振る理由もある 65
  67. 67. 一般的かどうかを意識する 判断基準の大本に常に「この書 き方は一般的かどうか」を持つ 逸脱するときは、共通認識のも とでeasyかどうかで殴り倒す 冒頭で紹介したDHHを思い 出して自らに乗り移らせる 66
  68. 68. コミュニケーションの境目 コミュニケーションコストの改 善はとても考えやすい 会話しなくても進められるよう に、パラレルにするには何が 整っていれば良いのかを考え、 そう動けるようコードを変える 67
  69. 69. コミュニケーションの境目 クライアント・サーバー間のイ ンタフェースをYAMLで定義し て、このYAMLさえあれば開 発・検証ができるようにすると か 68
  70. 70. easyを作る体制を 作る 69
  71. 71. “木を切り倒すのに8時間与え られたとしたら、斧を研ぐの に6時間使うだろう” 70 Abraham Lincoln
  72. 72. 楽をするための努力を惜しまない 未整備による無駄なコストを避 けるために、有限時間内で最大 の準備をしたい また、イテレーションで分かっ た内容をもとにどんどん改善し ていきたい 71
  73. 73. 足回りは最初に整える 「これを保っていれば速度が落 ちない」という最低ラインを 持って、それを守れる環境づく りを行う これを一言で言うと「ふつう」 になる 72
  74. 74. 足回りは最初に整える テスト もちろん書く テストがないとPRマージし ないのが「ふつう」 73
  75. 75. 足回りは最初に整える CI/CD もちろん回す 継続的にデプロイし続けら れるのが「ふつう」 74
  76. 76. 足回りは最初に整える メトリクス もちろん取る エラーやパフォーマンスを 継続的にチェックできるの が「ふつう」 75
  77. 77. 足回りは最初に整える Chat連携 通知が一か所に集まってく る仕組みを導入する 気づける、即対応できるの が「ふつう」 76
  78. 78. 足回りは最初に整える Issue/Pull Request テンプレートを書いておく すべてのPRについてWhyが 分かるのが「ふつう」 77
  79. 79. simpleに始める ブランチ運用 GitHub Flow 78
  80. 80. simpleに始める routes REST準拠を最初に考える schema 正規化を崩さない counter_cacheの無い状態 でまず作る 79
  81. 81. 改善が回る環境づくり ふりかえり どうだったらもっと生産的 だったかをイテレーショ ンごとに考える 80
  82. 82. 改善が回る環境づくり 改善工数の確保 思いついた改善を入れるた めに毎週数時間を使えるよ う、チームにネゴっておく 81
  83. 83. 改善が回る環境づくり 定点観測 取得しているメトリクスが 悪化傾向にないかの確認 改善が回っていない環境 だと絶対に悪化している 82
  84. 84. まとめ 83
  85. 85. まとめ(1/3) • 「ふつう」とは何か – 共通認識のもとでeasyになっていること • simpleとeasy – easyはsimpleの上に成り立っている – easyを維持しているのが良いRailsアプリケー ションだと言える • easyだとどうなるか – 消耗しづらく、実装に集中できる – 「普通にやれば普通にうまくいく」状態 84
  86. 86. まとめ(2/3) • 共通認識を作る – まとまったインプットを入れて自分の中で基 準を持つ – 「見たことがある」から雰囲気を醸成する • easyを作る – 繰り返してはならない、を刷り込む – 一般的かを意識して書く • それしか書けない仕組みづくりを行う 85
  87. 87. まとめ(3/3) • easyを作る体制を作る – どうあれば「ふつう」なのかの基準がもうあ るはずなので、そこに辿り着けるようにする – 準備に時間を掛けるのを許容する • 走りながら考えるのも大事なのでバランス – 改善・挑戦がチーム課題に含まれ、時間が確 保されている • 挑戦はもはや福利厚生 86
  88. 88. まとめ 今日の内容、一つ一つの「ふつ う」は聞いたことのある話だっ たと思う 87
  89. 89. ふつうの、とは(再掲) Railsエンジニアが Railsエンジニアらしい 作業に集中できる 88
  90. 90. まとめ 「ふつうのRailsアプリケーショ ン開発」とは、どこかで見聞き したことのある、現状の自分た ちの状況より良さそうな開発環 境に辿り着く努力をし続けるこ と 89

×