zakkiのブログ

IT関連などの雑記のブログです

コードの分離の有効性について


とにもかくにも、コードは、徹底的に分離したほうがいい


処理1に使う変数

処理2に使う変数

処理1

処理2

例えば、こんな処理があったとする。


このような時は、

プライベートメソッド1をコール
プライベートメソッド2をコール


プライベートメソッド1
    処理1に使う変数
    
    処理1

プライベートメソッド2
    処理2に使う変数
    
    処理2

こうすればいいだけ。

以上。


なんだけど、

こんなの当たり前だろうと思う人は多いと思う。

ただ、現場のコードでは、結構な確率で、この当たり前ができていない。


分離することのメリット


まず、コードというものは、どんどん肥大化していくことを思い出してほしい。

実務経験がある人なら、上記のパターンが、こんなことになることを知っていると思う。


処理1に使う変数

処理2に使う変数

処理3に使う変数

処理1
処理1の追加処理1

処理2
処理2の追加処理1
処理2の追加処理2

処理3

処理1の追加処理2


こうなってくると、ぐちゃぐちゃになり、メンテナンスコストが増大する。

おまけに、1つではなく、2つほど増大する。

  • コードを把握するコストの増大
  • コードを破壊するリスクによるコストの増大


これがもし、さっきの、分離されているコードだった場合はこのようになる。

プライベートメソッド1をコール
プライベートメソッド2をコール
プライベートメソッド3をコール


プライベートメソッド1
    処理1に使う変数
    
    処理1
    処理1の追加処理1
    処理1の追加処理2


プライベートメソッド2
    処理2に使う変数
    
    処理2
    処理2の追加処理1
    処理2の追加処理2

プライベートメソッド3
    処理3に使う変数
    
    処理3

圧倒的にメンテナンスコストが軽減される状態が、システムを廃棄するか、リファクタリングするまでずっと続く。

つまり、とてもお得ということ。


コードを分離するときのコツ


最初から、コードが肥大化するときの、においをかぎ取ること。

この嗅覚を身につけることは、とても大事。


そして、コードが肥大化しそうな場所は、あらかじめ分離しておく。


よくわからない場合は、キレイに、掃除できそうなところは、最初から、掃除しておく程度でも、結構違ってくる。

ただし、ヒューマンリソースは有限の為、できるだけ、手間がかからないで、最大限の効果が出る箇所に限定するしかなくなると思う。

つまり、やはり、上記の通り、現実問題として、嗅覚が必要となる。








画像提供元: いらすとや