開発をしている時に、割と頻繁に悩むことはあると思う

例

PBFを実践するにあたって、1つのfeatureとはなにか？

Aomic Designを実践するにあたって、このComponentはmoleculeか？organismsか？

Gitのcommitを作るにあたって、このcommit大きすぎる？小さすぎる？

コードの抽象度を揃えて書くにしても、これとそれは抽象度揃ってる？バラバラ？

これとそれ、どちらのコードが可読性高い？

etc.

感覚に則ってやっていくのも良いが、気分に左右されると後々困る

「〇〇とは、△△だ」ということには、ある程度明確な指標が欲しい

チーム間で理解を共有できないと困る

未来の自分と理解を共有できないと困る

今の自分は「この粒度(大)が1つのfeatureだ」と思っても、他の人が「この粒度(小)が1つのfeatureだ」と言ったら、結局あまりわかりやすくならない

意見がぶつかった時も、指標がないと感覚だけを根拠にすることになってしまう

誰が、どのタイミングでやっても、同じ結果になるよね、ぐらいの指標を作れればかなり良い

再現性が高い

世界を良くできる

記憶を喪失しても耐える

経営理念も概念としては同じだな

会社をやっていく上で迷った時の判断軸になる

新しい人が参加する時に、自分に合っているかどうかの判断軸になる

社員の目指すベクトルが揃う

指標とは？

意見が対立した時、迷った時に、それに則れば選択できる、という状態にできればいい

指標の例

明確で厳密な定義ができればそれに越したことはない

けど、それができることってほとんど無いと思う

DBのtableを作る時の正規化は、論理的に道順が示されるので良い

優先順位を決める

e.g. コードをきれいに書くために、状態、結合、複雑姓、コード量の優先順位でリファクタする ref

フローチャート

優先順位みたいなものか

どうやって作るか？

しるかーー

論理的な根拠を集めていけば良さそう

「定義を決めるぞ！」と臨んでも、コーナーケースを見落としがち

実践しつつ、その時々の判断の理由のメモをちゃんと残す

そのメモがある意味指標になる

実践していくうちに、そのメモには別のコーナーケースが踏まえられていないことに気づく

また考えて決定し、その理由も残す

というのを着実に積み重ねていく