🌟

【API設計】早すぎる最適化は諸悪の根源!!!

2023/03/06に公開

概要

ある機能を複数社に外部APIとして提供する機会があった。
設計の際に、「ある企業だけレスポンスに+αの情報を付け加えたい」などがあったときに備えて、
エンドポイントを以下のように分けた方が後々楽だったりするなんて血迷ったことを考えたので、この辺の思考について整理。

api/v1/customized/comapny_a/~~~
api/v1/customized/comapny_b/~~~
api/v1/customized/comapny_c/~~~

結論: 早すぎる最適化は悪の根源

Qiitaでこの辺の記事が大変参考になった。

結局のところ、早すぎる最適化は諸悪の根源ということだ。

きれいな（修正が容易な）コードであれば、最適化も容易です。
逆に最適化によって修正が難しくなったコードは、きれいにするのも困難です。

今回の場合、仮にまた要望が出ていない時点で個社別にエンドポイントを切り出してしまうと、
結局は共通処理のためのファイルを作成するはめになる。言葉にするとわかりやすいが、その状態をいざコードに落とし込むと見にくさがある。仮に個別に要望が出た時に、同じ担当者であればいいが、それが新入社員だったりまだ経験の浅い担当者だった場合は、この共通処理から個別に切り出すことは意外と心理的負担が大きかったりする。（影響範囲がわからず怖い）

だったら、汎用性の高いAPIとして今回は確立させておいて、別の機能が必要であれば、別途APIを作ってやる方が、何かと柔軟性は高い。

まとめ

なんでもかんでも詰め込むのではなく、今現時点での最適性を考えた上で設計を考える。
早すぎる最適化は諸悪の根源！

概要

結論: 早すぎる最適化は悪の根源

まとめ

Discussion