綴ります。プログラミング、アプリ開発について。
12.6 循環複雑度を減らす 内容 循環複雑度はコードの実行経路の数。 条件分岐がなければ、循環複雑度は１。条件分岐が１つの場合、異なる２つの経路があるので循環複雑度は２。２つの場合は４、３つの場合は８。。。 循環複雑度は幾何級数的に大きくなる。大きければ大きいほど条件パターンが増え、注意が行き届かなくなる場合があり、バグの発生率が高くなる。 なので少ないに越したことはない。 しかし、常に１にすることはできない。条件分岐を使わないことは実質ありえないからだ。循環複雑度を減らすテクニックとして、インスタンスの生成やメソッドの利用にポリモーフィズムを使う。そうすることで、プログラム上の条件分岐がなくなる。 学び 循環複雑度はバグの原因になるからなるべく減らそう。ポリモーフィズムを使っても減らすことができる。 循環複雑度は常に１にはできないよ。 学びを活かすアイディア・行動 現場のコーディング規約づくり。
12.5 意図によるプログラミング 内容 API、メソッド、サービスなどを外部に公開するとき、メソッドの中に実装を入れることはしない。実装は別のメソッドに移譲する。こうすれば、コードが読みやすくなる。 このテクニックを「意図によるプログラミング」と呼んでいる。（へー、そうなんだ） なぜ読みやすくなるのか？抽象レベルと具象レベルで観点が切り分けられ、観点に一貫性が出るから。抽象レベルでは「目的」を、具象レベルでは「やり方」を見ることができる。 抽象レベルを読み進めることで、プログラムの大枠の文脈を読むことができる。必要に応じて具象レベルの具体的な方法を読めば良い。 12.6 循環複雑度を減らす 循環複雑度はコードの実行経路の数。 条件分岐がなければ、循環複雑度は１。条件分岐が１つの場合、異なる２つの経路があるので循環複雑度は２。２つの場合は４、３つの場合は８。。。 循環複雑度は幾何級数的に大きくなる。大きければ大きいほど条件パターンが増え、注意が行き届かなくなる場合があり、バグの発生率が高くなる。 なので少ないに越したことはない。 しかし、常に１にすることはできない。条件分岐を使わないことは実質ありえないからだ。循環複雑度を減らすテクニックとして、インスタンスの生成やメソッドの利用にポリモーフィズムを使う。そうすることで、プログラム上の条件分岐がなくなる。 学び パブリックにするものは抽象レベルで定義すると、大きな文脈で読むことができるプログラムになりやすい。 「意図によるプログラミング」というワードでググってもわかりやすい情報は出てこない。。 循環複雑度はバグの原因になるからなるべく減らそう。ポリモーフィズムを使っても減らすことができる。 循環複雑度は常に１にはできないよ。 学びを活かすアイディア・行動 現場のコーディング規約づくり。抽象レベルの切り分けルール。 現場のコーディング規約づくり。