お前らこれどう見る？(Cの話ではないが)
> 正しい共通化とは、「同じものを共通化すること」であり「同じようなものを共通化すること」ではない。
https://xtech.nikkei.com/it/atcl/column/17/031300081/041000005/?P=2

俺はこの筆者が間違いだと思うが。
俺は後者も積極的に共通化して、というよりは積極的に「共通ルーチンを使うように」コーディングし、
結果的に「殆ど同じ事をやっているルーチン」の濫造を防いで行数を減らす＝コードの規模を抑えることの方が重要だと見ている。
つまり、この失敗ケースで最初に目指した物の方が近い。

「同じ物を共通化する」ではコードは減らない。「ほぼ同じだがちょっと違う」が大量発生してしまう。
だから最初から「同様のルーチンが必要」と分かっていればそれなりに緩く作って汎用性にするし、
当初それが分からない場合は当然「専用（＝非汎用）ルーチン」となっているが、
仕様変更で同様の物を追加で書く際に、それと纏めて無理にでも共通化する。
結果的に俺はそれで上手く行っている。（つもり）
なお俺も以前はこの作者と同様、「まず自由（つまり局所最適化）に組んで、その後共通部分を共通化」だった。
ただそれだとコードの依存性はそれぞれ別のルーチンを使うので当然減るのだが、
結果的に「ほぼ同じだがちょっと違う」だけのルーチンがやたら出来て、その後の長期的保守性が著しく落ちる。
というか、長期的保守性って結局のところ、「もう一度読み直すのにかかる時間」でしかないから、
結局は「コードの読みやすさ」＊「コードの量」であり、同じようなルーチンが山ほどあるのは悪だと気づいた。

違いはおそらく、開発フロー、つまりウォーターフォールとアジャイルの違い、また、
昔のテスト方式へのこだわり（＝一文字でも変更した部分は全部テストやり直し）から来ていると思う。
共通ルーチンがなければ、追加機能で仕様変更した際、追加部分にしか変更が影響しないので当然デグレードの危険は低くなる。
ただしそれだと無駄にコードが膨らんでいくだけで、割と早い段階で破綻すると気づいた。
とはいえ上記の俺の「上手く行っている」ははっきり言ってテストはほぼやってないので、
テストについて問題があるのは事実だが。