The sadistic approach to writing ruby
自分のコードを厳しく評価しながら書こう！
- 今回のトピックは大きいプロジェクトでなりがちな問題を事前に防ぐ手段の紹介！
What is the issue?
- 初期のclassやmethodは至って単純。業務ロジックやデータの関連が少ないからちょっと汚くてもまだ大丈夫…だと後悔しますよね？
- 追加のロジックや複雑な関連ができてくるとそもそも元のmethodやclassが何をしてるかなんてわかんなくなってくるよね（namingがダメだとなおさら）
When should we fix this problem?
- 問題がおきてからじゃあもう遅い！
- コードが読めなくなった時点でrefactorするのが極端に難しくなる。
- そもそも読めないコードは触りたくなくなる
- 目で見える汚さになる前にツールを使って複雑過ぎるmethodやclassをその場で検知しよう！
Why?
- レビューで基本的に落とされるだろうけど、レビューされる前に自動で検知された方が楽では？（bad codeの効率的な検知）
- 汚くなってから「あれ、これって何するんだっけ、、え、んん？」ってなるのがほんとにつらくなる
And onto a demo
-
Flog (ruby.sadi.st)
-
Ryan Davis
-
Demo