The Rules of Programming ルール1 | できるだけ単純であるべきだが、単純化してはいけない

どうも

今回はThe Rules of Programmingのルール1「できるだけ単純であるべきだが、単純化してはいけない」について、概要のポイントを簡単にまとめておきたいと思います

結論としては、「要求される機能要件、非機能要件を満たす最もシンプルな書き方を目指そう」

  • コードの単純さ・複雑さには以下の要素が影響する
    • 書かれているコードの量
    • 持ち込んでいる概念の数
    • 説明するのにかかる時間の量
      • 個人的にはサイクロマティックな複雑度だけではない気がしている
      • 特に非常に短いコードであっても、持ち込まれる概念の数が多い場合は、記述量は少なくても、複雑な場合はあると思う
  • 単純化してはいけない
    • コードは単純である方が良い
    • ただある課題を解くことを意図して書かれたコードは、常にその課題をクリアする必要がある
    • コードを単純にすることを優先して、課題がクリアされない状況が起こるのはNG
      • 例えばrailsならn + 1を放置したほうが、状況によってはコードが単純化することがある
      • だけどもし仮にデータベースへの問い合わせの数が、今後増える可能性があるときは、対応しておいた方が良いだろうと思った
    • コード内をDryに保つことは、単純化にも複雑化にもつながる可能性がある
    • 特に単純な概念で、コード量も多くない場合は、重複箇所をそのまま残す方が、コードとしてシンプルになることもある
      • 個人的にはあまりにメソッドが分けられている処理は読みづらいので、そういった部分はドメインごとのまとまりにするなど、センスが出るところだなと思います
  • 結局、この「できるだけ単純であるべきだが、単純化してはいけない」が最も重要
    • プログラミングの中心にあるのは複雑性(最終的にプロジェクトがうまくいかなくなるのは複雑性が原因となる)
    • 良いコードとは、プログラム全体の複雑性を少量に抑えているコード
    • 複雑性を取り除いたり、システム全体の複雑性を上げないコードを書くことを目指すこと
      • みずほ銀行のシステムもそうだが、複雑であればあるほど工数はかかるし、費用もかかる
      • 複雑性を下げることがコードを書く上で重要という概念は理解できる

いったん、こんな感じでまとめておきます

では!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA