処理速度と拡張性・保守性

優秀なエンジニアは拡張性・保守性と処理速度を上手く両立させます。

拡張性や保守性のために処理速度を犠牲にするエンジニアは優秀な
エンジニアとは呼べません。

拡張性や保守性は開発サイドの都合であり直接ユーザを利するものでは
ありません、対して処理速度はユーザのアクションに対する応答(に掛かる)
時間にダイレクトに影響します。
拡張性・保守性はユーザにとって評価しにくい指標であり、
アクションに対する応答(に掛かる)時間は評価しやすい指標です。
この点を忘れてはいけません。

保守性は、誰でも(馬鹿でも)わかるプログラムを書くことではありません。

保守性について...推敲中あるいは省略

拡張性がそれほど重要な要件でない用途では、拡張性は高いものの処理速度
の遅いライブラリAと拡張性はそれほどないが処理速度の速いライブラリBが
あった場合、大抵の人間はライブラリBを選びます。

拡張性が重要になる用件は限られています。

現状では必要のない拡張を見越して作り込む行為は馬鹿げています。
現状では拡張性の必要ない場合、拡張性の高いクラス設計を行っても実際に
その設計が役に立つケースはほとんどありません、時間を掛けるだけ無駄です。

拡張性は高いものの処理速度を度外視したクラス設計を行ったばかりに、
処理速度は遅く、作った人間以外には殆ど使われなかった(OSS)プロダクトは
山ほどあります。

「必要なモノは必要なトキに、シンプル イズ ベスト」、YAGNIの原則
を徹底するのが無駄なコストを掛けない鉄則です。

推敲中。

[蛇足]
ヘボいエンジニアに限って「保守性と拡張性」を主張して、
馬鹿みたいに遅いロジックを書き散らかしているのが現状。