Downloaded 11 times
技術的負債とリファクタリング
- 1.
- 2. 自己紹介 ● HN: 神速 ●twitter: @sinsoku_listy ● github: sinsoku ● 所属: 株式会社grooves ● Ruby/Rails歴: 6年くらい
- 3.
- 4.
- 5.
- 6. 今日話すこと 1. DB制約 2. 変更しやすいコード 3.リファクタリングはいつやるの？
- 7.
- 8. null: false は基本的に必須 ●3値論理は複雑なので避ける ○ Ruby 側で nil チェックが増える ● 意図しないデータ挿入を防ぐ ● NULL は不定で、空文字列とは違う ○ 値比較、インデックス、UNIQUE制約でハマる
- 9.
- 10.
- 11. UNIQUE制約にも気をつける ● 意図しないデータ挿入を防ぐ ● 後から追加するのが大変 ※users.email にUNIQUE制約を追加する良い知見をお持ちの方、後ほど教えて頂ける と嬉しいです。
- 12.
- 13.
- 14. 読みやすいコード ● 分かりやすい変数名 ● 短い行数のクラス・メソッド ●ABCSize の小さいコード ○ RuboCop で検出できます ● 過剰な DRY よりも可読性
- 15. eval, send の少ないコード eval,send があると影響範囲が分かりづらい eval のコード例
- 16.
- 17.
- 18.
- 19. ソフトウェア開発は難しい ● 予想外の仕様の追加 ● 限られた時間 ●技術力のあるエンジニアの不足 ○ コード化されていないインフラ ○ RESTful ではない URL ○ fat controller ○ `includes` や `sort` が書かれている view ● ...etc
- 20.
- 22.
- 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制約を厳しくする ● 読みやすく、消しやすいコードを意識する ●リファクタリングは常にする 技術的負債は必ず生まれるので、常に返済し続け るのが大事！（少額の技術的負債なら...）