コードを腐らせがちなので、心がけるべきことを自戒も込めて書きました。
メソッドの切り分け方について参考になる規則をまとめます。
メソッドの分解がよくなるとどうなるか
1.メンテナンス性があがる
結果が局所的になるため、変更の影響を抑えることができる
柔軟に変更ができ、また変更が容易になる
障害が起きた時も保守しやすく、拡張もしやすくなる
2.コードが読みやすくシンプルになる
ほかの部分も類推できるようになる
情報が隠蔽され、必要なものだけ見えるようになる
抽象化してコードが読めるようにいなる
3.できるだけ作らなくても開発ができるようになる
作らないで開発は究極の効率化
実績のあるコードを使用することで、品質があがる
どうやって切り分けたらいいのか
むやみやたらと切り分ければいいってものではない
DRY
Don't Repear Yourself.
大原則のコードのコピペ厳禁 ついこの前コピペでコード作った。
コードを抽象化し、処理のまとまりに名前をつける
それを繰り返し出てくる部分と置き換える
SLAP
Single Level of Abstraction Principle
抽象化レベルの統一
DRYで抽象化するときに抽象化概念のレベルで分離させる
メソッドを抽象レベルに沿って分割すると、高い抽象レベルのメソッドが目次の役割を果たしてくれるので読みやすくなる
対称性をもたせる
コードの一貫性
同じことは同じ表現にする
抽象化レベルで統一するとき、同じ種類、同質のものは同じレベルで合わせる
あるメソッド内で呼び出すメソッドの抽象度は同じレベルにする
変更頻度の確認
変更理由でグルーピングする
対称性のうちのひとつ、時間に関するレベルでの分離
変更理由が多いものは脆いコードなので、分離する
たとえば、毎年変更する必要のある部分と一般的に使える部分を分離することで一般的に使えるコードの品質を担保できる
関心で分離
関心単位でモジュール化
対称性のうちのひとつ、関心に関するレベルでの分離
たとえば「Mode-View-Controller」のフレームワークではそれぞれに役割があり、関心が分かれている
メソッドも同じように関心がまざらないように分離すると読みやすくなる
まとめ
頑張っていっぱいコード書いていっぱい直せばいいかな！
コードは必ず変更されるということを念頭に、品質のいいコードを目指したいと思います
参考文献
プリンシプルオブプログラミング（著：上田 勲）秀和システム
達人プログラマー(著：Andrew Hunt、 David Thomas)オーム社