![見出し画像](https://assets.st-note.com/production/uploads/images/151959586/rectangle_large_type_2_ccd521e221eae8bcfbad464b737dfbc6.png?width=1200)
いいリファクタリングをする基準を教えてくれます - 脳に収まるコードの書き方④ - ReadLog
前回の続きです。ここがこの本の最重要ポイントです。
前回はあまり読まなくていいです。この回だけ読んでください。
概要
タイトル:脳に収まるコードの書き方
ジャンル:技術書(情報系), ソフトウェア開発, プログラミング技法
備考:人間は7個までしか覚えられない、だから7章にこの内容を持ってきた!?
ここは本の紹介と記録を目的としたマガジンです。
時間がない人や面白い本を探している人向けです。
本の一部を引用しながら、少しでも興味を持ってもらうことを目指してます。
今回は7章だけです。
というか、この本のタイトルの内容が書いてあるのはここだけです。
脳に収まるコードの書き方
サイクロマティック複雑度に注意を払い、7を超えたら変更を拒否するようにします。
ソフトウェアは開発が進むごとに、コードが読みにくくなっていきます。
新しいコードを既存のメソッドにねじ込んで、目的の機能が追加できたころにはコードがぐちゃぐちゃになっています。
コードが複雑になってから回復することは難しいです。
全体で何がどうなっているのか分からないので、脳に収められないからです。
複雑になる前にコードを改善するため、1つのコードメトリクスを活用します。それが、「サイクロマティック複雑度」です。
この指標、実は以前も出てきています。
サイクロマティック複雑度が最大7になるようにする
※短期記憶できる限界が最大7個であるため(著者による定義)
が、その時は説明がありませんでした。
7章になってついにその正体が明かされるのです!
サイクロマティック複雑度は、コードの断片を通る経路を数えるものだと考えてください。
(中略)
1から始めて、ifやforが何回登場するかを数えます。キーワードが登場するごとに、(1から始まる)数字をインクリメントします。
要するに、コードの分岐の数です。
if文がわかりやすいですが、真のときと偽のときの2つの経路に分岐したとき、サイクロマティック複雑度が1増える、というわけです。
この分岐の数が7を超える(8以上になる)と脳に収まらなくなるのだ。
というのが著者の主張というわけです。わかりやすい!
もう少し詳しく
さて、「6つしかif文使えないとか何もできなくね?」と思った方がいるかもしれません。(if文がない状態でも複雑度は1です。)
安心してください。
1つのメソッド(関数)で7を超えなければ大丈夫なので。
あるメソッドのサイクロマティック複雑度が7を超えそうになったら、機能の塊ごとに新しいメソッドに切り分けたり、処理が変わらない形でサイクロマティック複雑度を削減しましょう。
(この本に厳密に従うなら、7を超えるのを待たずにもっと早い段階から切り分けるほうが良いです。)
切り分けたメソッドは適切なクラスに割り振りましょう。
もちろん、切り分けたメソッドがサイクロマティック複雑度が7を超えない必要もあります。再度切り分けるなどして
これを図示すると以下のようになります。
![](https://assets.st-note.com/img/1724594193334-yhP7He3U6X.png?width=1200)
大きな六角形が7つ、これ1つ1つがプログラマが一時記憶できる分岐を示します。
そしてその大きな六角形の中に、細かい六角形があります。これがメソッドに切り出された後の分岐処理になります。
適切なリファクタリングでサイクロマティック複雑度が抑えられている限り、プログラマは各メソッドを脳に収めることができるのです。
そしてこの図には見覚えがあるかもしれません。そう、これは表紙のイラストです。
これをひたすら繰り返して、どの部分を見ても脳に収まるコードにしましょう。
この構造を保つには、不断の努力が必要です。気を抜いたらグチャグチャなコードになってしまいますから。
著者はこの構造を指して「フラクタルアーキテクチャ」と呼んでいます。
非常に陳腐ですね。覚えやすくて助かります。
(シーマンアーキテクチャとか言われたら脳に収まるか怪しいところでした。)
まとめ
サイクロマティック複雑度が7を超えないように、コードを改修する。
改修し続ける。それが大事。
次:ちょいまち
おまけ
7章にはサイクロマティック複雑度以外の話も出てきます。
簡単にご紹介をしておきます。
1メソッドを80文字24行に収める
あくまでこの本の基準であるC#、かつ著者の基準です。
他の言語、他の人ごとに基準は変えても大丈夫です。
でも大事なことは、
1つの画面で1つのメソッドを見れるようにすること、です。
バリデーションメソッドは必要?
検証は、似たような処理を何度も行うことになります。
例えば、文字列を特定の形式に変換できるかどうか、とかです。
これはカプセル化によって解決することもできます。
バリデーションの処理を逐一書くのではなく、カプセル化されたオブジェクト格納することで、不正な値が入れば即エラーになります。
また、いったんオブジェクトにできれば、(適切にカプセル化されている限り)常に正常な状態が保たれます。
カプセル化については前回の記事を参照ください!
この記事が気に入ったらサポートをしてみませんか?