対象読者
- オブジェクト指向の原理原則が取っ付きにくい方
- ドメイン駆動設計(DDD)などのプラクティスを使用してもコード品質が良くならないと感じている方
結論
コーディングスタイルはプログラマの宗派・思想・趣味嗜好の数だけ存在する。当然、みんな違ってみんない良い訳ではない。良い方法はプログラミング原則または無数のテクニックとしてまとめられていたりいなかったりする。
結局どれが最善の方法なのかも分からないし、そもそも良い手法を理解すること自体も難しい場合がある。例えば、SOLIDの原則やらデザインパターンは抽象的で難しい。
しかし、人間がプログラムを読み書きする以上、良いプログラムは人間の認知能力に則したもののはずだ。故にリーダブルであることが良いコードの条件と一般的に言われる。ただ、リーダブルという指針も抽象的で応用しづらい。
そこで、本稿は良いプログラムを書くための具体的かつ明解な原則を提案する。すなわち、「一度に把握すべき情報の数をマジカルナンバー以下にせよ」だ。
- マジカルナンバー
- 同時に認識するチャンクを常に7個以下にする
- チャンクを大きくする仕組み:関数、クラス
- 手続き型の限界
- 継承の限界
- 関数は20行程度にすべし
- クラスのメンバは7個以下にすべし
マジカルナンバー4；ヒトが把握できる情報の数
マジカルナンバーとは、人間が短期記憶に保持できる情報の数だ。一度に把握できる要素数の上限とも換言できるだろう。マジカルナンバーには以下のように２つの説がある。
- マジカルナンバー７：マジカルナンバーは7±2とする説(1956年）
- マジカルナンバー４：マジカルナンバーは4±1とする説(2001年)
新しく提唱されたマジカルナンバー４の方が妥当とされているようだ[1]。さらには近年では「マジカルナンバー4」の最小の数字である「マジカルナンバー3」も浸透し始めているらしい[2]。
このように、意外にも人間が把握できる情報量は少ない。聞き慣れない概念や業務内容についての話が理解しづらいのも当然だ。同様に巨大なメソッドやクラス、トランザクションスクリプトも理解しづらい。
情報のかたまり「チャンク」
ヒトは高々4個程度の情報しか一度に扱えないらしい。あれ？おかしくないだろうか。それにしてはコミュニケーションが高度過ぎやしないか。ちょっとした短文でも大量に情報がやり取りできる場合もあるし。
雑にマジカルナンバーを説明してしまったことをここに謝罪する。より正しくは「人間が短期記憶に保持できるチャンクの数」だ。
チャンクとは「情報のかたまり」のことで、大小さまざまだ。大きいチャンクを用いることで高度な（多くの）情報伝達が可能となる。
といっても抽象的で分かりづらいので、ありがちなチャンクが利用例「電話番号」について説明する。電話番号は11桁程度の数字の羅列だ。すでにマジカルナンバーを超えてしまっているので、ヒトが電話番号を覚えるのは容易ではない。そこで「xxx-yyyy-zzzz」みたいに番号を３分割する。つまり、11個のチャンクをマジカルナンバー以下の3つのチャンクにまとめると把握しやすくなる。
プログラムのチャンクを大きくする仕組み
追加機能はモデルを再設計する機会 いふ文とかで誤魔化さない
機能の共通化までの視点しかない
責務を明確に定義する
前者にはドメインを深く捉えたモデルを構築しようとする気概がまだない。うまく処理を分割して、インターフェースによって切り替えを行うことはできない。保守のときに、この機能を変更、追加したいという要望に対して、前者には応えられない。共通化という視点だけでは、長いメソッドでも無頓着に許容してしまう恐れがあるから。
コメント