https://rails-developers-meetup.connpass.com/event/58046/

1. 技術的負債とリファクタリング
2017/06/22(木) Rails Developers Meetup #2

2. 自己紹介
● HN: 神速
● twitter: @sinsoku_listy
● github: sinsoku
● 所属: 株式会社grooves
● Ruby/Rails歴: 6年くらい

3. Forkwell の紹介

4. 技術的負債とは
> 手抜き、ハック、重複などなど、開発速度と期日の
名の下に、私たちは数々の 狼藉をコードベースにコ
ミットしている。技術的負債とは、そうした狼藉が時間
とともに積み重なったものだ。
引用: アジャイルサムライ p249

5. 自社のコードに技術的負債のない人

6. 今日話すこと
1. DB制約
2. 変更しやすいコード
3. リファクタリングはいつやるの？

7. 1. DB制約

8. null: false は基本的に必須
● 3値論理は複雑なので避ける
○ Ruby 側で nil チェックが増える
● 意図しないデータ挿入を防ぐ
● NULL は不定で、空文字列とは違う
○ 値比較、インデックス、UNIQUE制約でハマる

9. OAuth とスライドのデータが
同じテーブルのDB設計

10. null: false がつけられない...

11. UNIQUE制約にも気をつける
● 意図しないデータ挿入を防ぐ
● 後から追加するのが大変
※ users.email にUNIQUE制約を追加する良い知見をお持ちの方、後ほど教えて頂ける
と嬉しいです。

12. 2. 変更しやすいコード

13. コードの可視性
スコープの狭いメソッドは変更しやすい。
● private
● Refinements

14. 読みやすいコード
● 分かりやすい変数名
● 短い行数のクラス・メソッド
● ABCSize の小さいコード
○ RuboCop で検出できます
● 過剰な DRY よりも可読性

15. eval, send の少ないコード
eval, send があると影響範囲が分かりづらい
eval のコード例

16. 3. リファクタリングはいつやるの？

17. 引用: アジャイルサムライ p249

18. 良いコードは伝説
https://twitter.com/sinsoku_listy/status/163621382054346752

19. ソフトウェア開発は難しい
● 予想外の仕様の追加
● 限られた時間
● 技術力のあるエンジニアの不足
○ コード化されていないインフラ
○ RESTful ではない URL
○ fat controller
○ `includes` や `sort` が書かれている view
● ...etc

20. SessionsController#auth
メソッド行数は 90 行

22. 引用: アジャイルサムライ p253

23. 1つのプルリクが出来るまで
1. コードを読んで理解する
2. 変更方法を考える
3. 変更(コミット)する
4. 動作確認
5. レビュー＆マージ

24. リファクタリングはいつやるの？
1. コードを読んで理解する
○ 理解した内容をコードに反映する
○ スコープを狭くする（未使用なら消す）
2. 変更方法を考える
3. 変更(コミット)する
4. 動作確認
5. レビュー＆マージ

25. 理解した内容をコードに反映する
● 説明変数の導入
● メソッドの抽出
● メソッドの移動

26. スコープを狭くする(未使用なら消す)
● private にしていく
● git grep -n "method_name" で調べる
○ 未使用メソッドは躊躇なく消す
○ 不安なら "deprecated" をログに出し、後日消す

27. リファクタリングしていくと...
● 漏れている条件
● 意味のない処理
○ 絶対に true にならない条件
○ 絶対に呼ばれないメソッド
● 実は同じ処理のメソッドがある
など、気付けるようになります。

28. まとめ

29. まとめ
● DB制約を厳しくする
● 読みやすく、消しやすいコードを意識する
● リファクタリングは常にする
技術的負債は必ず生まれるので、常に返済し続け
るのが大事！（少額の技術的負債なら...）