コードを腐らせがちなので、心がけるべきことを自戒も込めて書きました。
メソッドの切り分け方について参考になる規則をまとめます。

メソッドの分解がよくなるとどうなるか

結果が局所的になるため、変更の影響を抑えることができる
柔軟に変更ができ、また変更が容易になる
障害が起きた時も保守しやすく、拡張もしやすくなる

ほかの部分も類推できるようになる
情報が隠蔽され、必要なものだけ見えるようになる
抽象化してコードが読めるようにいなる

作らないで開発は究極の効率化
実績のあるコードを使用することで、品質があがる

どうやって切り分けたらいいのか

むやみやたらと切り分ければいいってものではない

Don't Repear Yourself.
大原則のコードのコピペ厳禁　~~ついこの前コピペでコード作った。~~
コードを抽象化し、処理のまとまりに名前をつける
それを繰り返し出てくる部分と置き換える

Single Level of Abstraction Principle
抽象化レベルの統一
DRYで抽象化するときに抽象化概念のレベルで分離させる
メソッドを抽象レベルに沿って分割すると、高い抽象レベルのメソッドが目次の役割を果たしてくれるので読みやすくなる

コードの一貫性
同じことは同じ表現にする
抽象化レベルで統一するとき、同じ種類、同質のものは同じレベルで合わせる
あるメソッド内で呼び出すメソッドの抽象度は同じレベルにする

変更理由でグルーピングする
対称性のうちのひとつ、時間に関するレベルでの分離
変更理由が多いものは脆いコードなので、分離する
たとえば、毎年変更する必要のある部分と一般的に使える部分を分離することで一般的に使えるコードの品質を担保できる

関心単位でモジュール化
対称性のうちのひとつ、関心に関するレベルでの分離
たとえば「Mode-View-Controller」のフレームワークではそれぞれに役割があり、関心が分かれている
メソッドも同じように関心がまざらないように分離すると読みやすくなる

頑張っていっぱいコード書いていっぱい直せばいいかな！
コードは必ず変更されるということを念頭に、品質のいいコードを目指したいと思います

プリンシプルオブプログラミング（著：上田勲）秀和システム　
達人プログラマー(著：Andrew Hunt、 David Thomas)オーム社