『早計な最適化は諸悪の根源』とは👀？

はじめに

「読みやすいコードのガイドライン」という本を読んでいる中で、

早計な最適化は諸悪の根源

という言葉が紹介されていたので、この内容について記したいと思います。

早計な最適化は諸悪の根源...👀

この言葉はDonald Knuth氏が提唱された考えでして、¹

計算時間の最適化や使用メモリの効率化などといったパフォーマンスの向上施策は、

その実に97%が無駄であり、かえって逆効果になることもあるので、

まずは可読性やメンテナンス性が高く、

変更容易性があるコードを書く方が良い、

といった考え方のことです。

ユースケースとしては...

• 可変なオブジェクトの使い回し

• 遅延初期化

• キャッシュ

といったことが挙げられています。

また、上記内容についてより分かり易く解説していただいている

記事もありました。

こちらの記事の中では...

たとえば処理Ａの過程でできたリソースを、せっかくだから処理Ｂで使いまわせば
効率が良いじゃないか、といったことが行われます。
もったいない精神と考えてもいいかもしれません。

このように具体例を交えて解説していただいていますが、

確かにこういったシーンってありますよね💦

ただこの場合、引用元の記事の中でも解説されていますが、

処理Bは処理Aに依存することになり、処理Aの修正は処理Bにも波及し、

処理Bを修正する際は処理Aにもそれが波及する、といったことが起こってしまいます。。。

このような状況になってしまうと、

プログラムがどのように走っているのかを掴みづらくなり、

コードの修正や機能追加、新規機能の開発をする際にも

それをやりづらくしてしまったり、または欠陥となって故障に繋がる...

といったことが起こってしまいそうですよね。。。😨

ユーザー視点に立ってパフォーマンスを改善したつもりが、

コードや設計の悪化によりデグレーションに陥り、

かえってユーザーに不利益を与えてしまう。。。

これだとちょっと悲しいですよね😣

こちらの記事の中で解説されていたことを踏まえまして...

• まずは綺麗なコードを書くこと

• 上流工程から要求や要件、仕様をきちんと定義すること

• 真に解決したいこと、妥協してもいいことはないのか考えること

• 実は別のより良い解決案がないかなどを模索し提案すること

• シフトレフトを適用し、試験性を確保して、リスクを減らしていくこと

こういったことをまず最初に行うことが重要なんでしょうね🤔

参照

読みやすいコードのガイドライン

1. 「読みやすいコードのガイドライン」 第1章 33頁 ↩