共有理解（Shared Understanding）と思いやり注入（Decency Injection）
BEAR.Sundayを知ってはいても「名前もキャラもゆるいのに、妙にストイックで・・・」と思っている方が多いのかもしれない。
「RESTを尊重」すべき、「入力は明示的」であるべきで、「依存は注入（Dependency Injection）」されてオブジェクトグラフになるべき、「本質的な関心と横断的な関心は分ける（Aspect Oriented Programming）」べきで・・・と「べき論」が多いフレームワークのようにも映るかもしれない。
この他にも、BEARとその周囲のパッケージには以下のような特徴[1]がある。
- 制約[2]を重視したコード
- 静的解析ツールを用いて、IDEでの補完を重視
- 手続きではなく構造を宣言
- 暗黙的になりがちな情報はJSONにして説明可能に
- セマンティックバージョニングを守り、後方互換性を守り続ける
- ジャーゴンを嫌い、理解するのに文脈が必要となるような省略語などは使わない
- 言語自体のバージョンアップなどで、よりわかりやすい書き方があれば積極的に取り入れる
ではそれらはそもそも何のためなのか？
結局は「共有理解」のためなのではと気がついた。
これは単に「知識を共有して属人性を排除しよう」とか「独りよがりではなく、共感を得らえるようにしよう」とか、そういうことではない。
仮に理解を共有する相手が、未来の自分しかいない場合でも、同様に行われるべきである。
書いていて心地いいとか、楽に書けるとか、テストのときに差し替えられて便利だとか、あるいは結果的にパフォーマンスがよいということよりも、「共有理解」の方がまず先にあるべきなんだと思う。
もし明日の自分が理解に手間取るようなコードだったら、それがどんなに最新の記述で行数が少なく処理が速かったとしてもほとんど意味がないのだから。
Clean Codeという本の「コメントで、ダメなコードを取り繕うことはできない」という正しすぎる強烈なメッセージのせいで、必要なコメントまで書くことをためらってしまうケースがある。
でもほとんどの場合、コメントはあった方がいい。静的解析用の記述でフォローできないような事柄は大いにコメントを書くべきだと思う。
コーディングには、もう一つ大事なDIがある。それはDecency Injection（思いやり注入）だ。
目指すべきは、やさしいコードで、思いやりはどんどん注入しておいた方がいい。
Discussion