『早計な最適化は諸悪の根源』とは👀？
はじめに
「読みやすいコードのガイドライン」という本を読んでいる中で、
早計な最適化は諸悪の根源
という言葉が紹介されていたので、この内容について記したいと思います。
早計な最適化は諸悪の根源...👀
この言葉はDonald Knuth氏が提唱された考えでして、[1]
計算時間の最適化や使用メモリの効率化などといったパフォーマンスの向上施策は、
その実に97%が無駄であり、かえって逆効果になることもあるので、
まずは可読性やメンテナンス性が高く、
変更容易性があるコードを書く方が良い、
といった考え方のことです。
ユースケースとしては...
-
可変なオブジェクトの使い回し
-
遅延初期化
-
キャッシュ
といったことが挙げられています。
また、上記内容についてより分かり易く解説していただいている
記事もありました。
こちらの記事の中では...
たとえば処理Ａの過程でできたリソースを、せっかくだから処理Ｂで使いまわせば
効率が良いじゃないか、といったことが行われます。
もったいない精神と考えてもいいかもしれません。
このように具体例を交えて解説していただいていますが、
確かにこういったシーンってありますよね💦
ただこの場合、引用元の記事の中でも解説されていますが、
処理Bは処理Aに依存することになり、処理Aの修正は処理Bにも波及し、
処理Bを修正する際は処理Aにもそれが波及する、といったことが起こってしまいます。。。
このような状況になってしまうと、
プログラムがどのように走っているのかを掴みづらくなり、
コードの修正や機能追加、新規機能の開発をする際にも
それをやりづらくしてしまったり、または欠陥となって故障に繋がる...
といったことが起こってしまいそうですよね。。。😨
ユーザー視点に立ってパフォーマンスを改善したつもりが、
コードや設計の悪化によりデグレーションに陥り、
かえってユーザーに不利益を与えてしまう。。。
これだとちょっと悲しいですよね😣
こちらの記事の中で解説されていたことを踏まえまして...
-
まずは綺麗なコードを書くこと
-
上流工程から要求や要件、仕様をきちんと定義すること
-
真に解決したいこと、妥協してもいいことはないのか考えること
-
実は別のより良い解決案がないかなどを模索し提案すること
-
シフトレフトを適用し、試験性を確保して、リスクを減らしていくこと
こういったことをまず最初に行うことが重要なんでしょうね🤔
参照
-
「読みやすいコードのガイドライン」 第1章 33頁 ↩︎
Discussion