なんのための法則?かを考える
〇〇の原則に反しているからこのコードはダメだとか、××の原則に従っているかららこれでいい、というのは、ただのマウンティング。
あくまで、そのコードに即して、良さ悪さを具体的に語れなければならない。
その上で、この点は〇〇の原則が言っていることと合致するね、という話になるのであって。
設計原則やルールで縛ろうとするのは、たぶん、無駄をしたくないからでしょう。
その考えが間違っている。セコ過ぎて話にならない。
設計や創作は、それ自体、知性と思考の大富豪的蕩尽であり、それが何かを生み出すかは、無駄なことをどれだけ考えたり会話するかにかかっているんです。
「唯一のベストのやり方」を見つけて「横展開」したいという願望は、初級者にありがち。僕も昔そうだった。ある種の中二病なんだと思う。
実際に動くソフトウェアを作るという責任を自分で引き受ける経験を積むうちに、治ってくる。部分的な仕事だけしていると治らない。フィードバックがないからね。 まっとうな人は、こうしろとは言わない。
デザインパターンは、こんな状況ではこんな設計を検討したら?と言っているだけ。リファクタリング本は、こんな「臭い」がしたら、こんなことやってみれば?と言っているだけ。 こうしろとは言っていない。それを判断できるのは、実際の設計者だけだからだ。
自分もやりがちなので気をつけたい
文脈が大事。文脈を無視して適用できるような万能な法則ほど、怪しい。