良いコードを目指して ~リファクタリング~

今日はリファクタリングについて着目して行きたいと思います。

リファクタリングとは、処理結果などが変わらないように注意しつつ中身(コード)を整理することを言います！

まさに、私が目指す”良いコード”に近づく作業です。

主にコードそのものについては他の記事で記述しているので、今回の記事ではリファクタリングの中でもメソッド出しに注目して行きます。

メソッド出しをするということは、引数とreturnを持つ１つのメソッドを作成するということです。

メソッドとして実装することで、引数とreturn以外はほぼ呼び出し元には関連の無いコードになるでしょう。

その結果、呼び出し元コードも、メソッド側のコードもお互いに小依存の関係となり、改修のしやすさにつながります。

再利用性がない処理をメソッド出ししたとしても、結合度を低くすることに繋がることもあります。

例えば、DBの販売履歴テーブルから特定の条件でSELECTし、Dtoクラスに加工する処理があったとします。

単純に１つのロジック内で処理をしていると、どこからどこまでがDtoクラス加工に関与しているのかもコードを読まないといけなく、また改修をする場合は更に他に影響があるかを見なければなりません。

引数を販売履歴のrow(またはList)、returnをDtoクラス(またはList)のconvertSaleshistoryToDtoメソッドとしてメソッド出ししている場合は、加工する処理を改修するとしてもメソッド内に着目すればよいため改修がかなりしやすくなると思います。

細かい部分をメソッド出しすると、結合度を下げることに繋がらないかもしれません。

なるべく大きな処理の纏まりとしてメソッド出しができそうな場所を見つけたら、進んで実行しましょう。

これは、メソッド出しをする際の一番わかりやすい目的だと思います。

複数回出現する、同じまたは酷似した処理をメソッド出しすることは基本的にメリットしかありません。

何回も書かなくて済みますし、修正するときも１箇所だけなので良いコードにより近づきます。

私の感覚ですが、汎用性を持たせるのであればなるべくシンプルなメソッドにしましょう。
(極端な例だと、"Nullを空文字,それ以外はそのまま"で返すようなメソッド)

いきなり、先ほど書いたことと矛盾していていますね笑

必ず両方とも守らなければいけないことはなく、むしろ両方の要素を持ったメソッドは少ないでしょう。

メソッド出しをするときは、どういう目的で抽出をするのかを意識して行いましょう！

コードはシンプルな方が読みやすいです。

メソッド出しをすると、コードをスクロールして読む量が減ります。

実際には別メソッドに記述しているだけですが、そのまま列挙された200行のコードと100行のコード*2では、後者のほうが読みやすい場合の方が多いでしょう。

あっちこっちに飛び過ぎると、可読性が低下しますが、適度なメソッド出しは可読性をもあげるのです！！

リファクタリング作業は、定義されていない正解に向かっていくような作業なので、人によって終わらせるタイミングは異なると思います。

また、時間をかければ良いコードに近づけるというものでもありません。
私自身今でも、この作業が果たして正解なのか悩みます。。。

慣れない頃は無理に全体を見ず、ロジッククラスやDaoクラスに１度目を通して見るくらいが良いのではないかと思います。

また、最大でも２回くらいがリファクタリング作業の効率が良い期間かなと感じます。
３回目以降は、よくわからなくなってしまったり、箇所が少なかったりと作業効率が悪くなる気がします。(経験談)

まずは１回、目を通すくらいの感覚がちょうどいいと思うので、やってなかった方は是非やってみましょう！！

リファクタリング作業は自分でやってもなかなかは捗らないかもしれません。

そういう時は他の人にソースをレビューしてもらうと、気付けなかった点に気付けるかもしれません。

Keecom's Yuruyuru Outputs