カオス回避⇒共通化⇒カオス

関数の共通化についてです。少し共通化とは異なるかもしれないけど気にせず書いていく。
システムの製造、まぁほとんどはプログラミングの実装をしていると、この辺りは関数化して使いまわそうって時はいくらでもあると思う。

で、初心者が関数、共通化を覚え、それなりに経験を積んでいくと、ここは共通化できるでしょ？ここは共通化できないの？みたいになんでもかんでも共通化しようとする人がたまにいる。

本人は共通化してうまくやった、してやったり、これでシステムがスリム化し解りやすくなると思っているらしい・・・けどな、おまえ共通化する部分はちゃんと考えてから決めろ。これから仕様が決まる、もしくは、頻繁に変わる可能性がある部分を共通化するアホがどこにいるんだよ。

例えば、あるいくつかのイベントが発生した時、共通化して纏めようとある共通化関数を作り、その関数を呼び出そうとしている。でも、仕様はどんどん変わり、その関数もどんどん変わっていく。複数のイベントから呼び出されるわけだから、この場合はあの場合はとifなどのネストも増えていく。さらにどんどん増えていく。最初は意気揚々と共通化しようとしていたくせに、その共通化関数の中がいくら肥大化しても、新たに関数を作ろうとしない。何としてもその関数一つだけで作り上げようとする。どうやら、一度共通化しようと決めたから、なんとしてもそれ一つで完結しようと考えているらしい。そうなるとif,forなどが何重にもなった見事なスパゲッティが出来上がり。大げさな話ではなく、この前本当に入れ子が20以上ある糞コードを見た。最初は共通化してうまく纏めようとしたのに、結局とんでもないカオス状態になっている。いくら入口を一つにしても中身がとんでもないことになっている。

とりあえず、共通化しようとする部分は一概には言えないかもしれないけど、あまり修正が加わらない部分にしてほしい。
・機能要件ではなく非機能要件部分（例外処理、ログとか）
・DBのトランザクションみたいな部分
・文字列、日付などを扱うコード
・フレームワークやデザインパターン等のシナリオが決まっている部分。

書き上げてみると当たり前の事なんだけど・・・・もう一度言うけど、自分で考えて決めてほしい。

これはDBの正規化にもあてはまる。正規化を覚えると完璧に正規化しようと頭を悩ます人がいる。少しも冗長化しようとしない。そのつけがのちの製造に繋がってくとか全く考えない。それを説明しても、でも必要なくないでしょ？の一点張り。「じゃあお前がその製造部分もやれよ」・・・


とは仕事なので言えませんが。愚痴だらけの文章になってしまった。大人の対応で相手を諭すにはどうしたらいいのか？そして、自分も勘違いをしていないか？周りがちゃんと見えているか？日々そんな事を考えて生きています。