共通化と抽象化
@shibu_jp: 循環的複雑度とか行数で見るの、いまいちだよな、と思っていたが、The Philosophy of Software Designにまんんまそれっぽいことが書いてあった。行数が短くてもmalloc/freeを意識しなきゃいけないようなコード、いつどう呼ばれるかわからんフレームワーク内部のコードは認知的負荷が大きいと。 そしたら共通処理なんて名前つけんやろ
そんで関心を凝縮して粒感出てきたら勝ち
輪郭ふわふわしてる時点ではまだ未成熟
機能の共通化によって、コードのメンテナンス性を上げていくことによって、かえって依存関係をふやしてモノリス化を促進したと思っています - そうですね！機能の共通化は諸刃の剣ですね。保守容易性を上げることが必ずしも柔軟性をもたらさないと言うのは、興味深い話です。
「共通化しないと将来的に変更が大規模になる」について
大規模でも単純な置き換えなら集中すれば数日〜1週間で終わるものもある
共通化というのはそれだけ高度な能力が求められ、運用コストもかかる
どれだけ上手く本質のみを共通化できるかどうか
意図や知識 (状況・問題・解決方法) が重複していると自信を持って言える場合にのみ共通化すべき
自信がないなら共通化せずに愚直に書いたほうが個別対応できるので後から方針を変えやすい
基本的に未来予知は不可能
共通化する際の関数設計
optionalな引数を増やさない
ifで分岐しない
パターンを用意して呼び出し側で切り替える