經典的編程引言

最近在一個網站上看到了一篇文章，收集了一些經典的編程引言，特意摘了幾條比較喜歡的放在這裡。再附上自己的理解。

1、過早的最佳化是萬惡之源。

Premature optimization is the root of all evil!
- Donald Knuth

嗯。有道理，一般來說，需求變更會導致代碼變更，代碼變更會導致你做的代碼最佳化工作付諸東流。所以，往往採用 “ 先實現再最佳化 ” 的原則，不管代碼效能有多麼差，先實現功能再說，把功能拿給客戶，當客戶確認了這個功能就是他要的東西而不是什麼別的，（通常他會提出一些小意見），那麼好，接下來，就可以實現這些小意見了，並且可以放心的最佳化代碼了，至少不必擔心大部分的最佳化工作付諸東流了。呵呵。

 

另外還有幾種情況，也是和不要過早最佳化有關。

 

要實現非常複雜、非常難於調試的演算法，那麼剛開始的時候一定不要考慮最佳化的問題，用最安全、最簡單、最有失水準的代碼，先實現功能再說。當功能實現沒有問題了，再考慮最佳化效能的問題。如果一開始就加入最佳化，會使調試工作變成噩夢。

 

當整個系統沒有開發完成之前，有些代碼先不要最佳化，因為它也許根本不是瓶頸。如果一段代碼，執行起來需要0.5秒，費盡心機把它最佳化成只需要0.1秒，沒有必要，以人的反應速度，恐怕不會在意。反之，如果一段代碼執行起來需要兩個小時，倒是需要好好考慮如何最佳化的問題了。

 

直接調整彙編代碼來最佳化程式被稱為黑色藝術，你得比編譯器更聰明，才能保證你調整彙編代碼是在最佳化程式而不是慢化程式。當然，敢這麼做的人，一般都比編譯器聰明。這項工作也需要放到後面來做，因為進階語言代碼的變更會使彙編最佳化泡湯。

2、在水裡行走和以一個需求規格進行軟體開發，有一點是相同的，那就是如果水或需求都被凍住了，那麼行走和軟體開發都會變得容易。

Walking on water and developing software from a specification are easy if both are frozen
- Edward V Berard

客戶也許永遠表達不清楚自己想要什麼，或許不光是表達不清，也許自己都沒有搞明白要什麼。所以大部分時間，程式員是在水裡行走，而不是在冰上行走。當然，做一條船就可以了，我們可以在把代碼做成可配置的，通過幾個標誌變數就可以輕鬆的改變代碼功能。做船是要花功夫的，同樣，把程式做成可配置也是有開銷的，例如代碼體積增大、調試難度增加等等，看您如何取捨了。據說有很厲害的軟體，可以通過指令碼變更軟體功能，這可不是一般的船了，是豪華郵輪，光造這船都需要下血本了，我覺得：不值。也就微軟這樣的大鱷能夠玩的起，Office就是帶VBA指令碼功能對吧，可惜大部分人不會用。

3、Hofstadter 定理：“一件事情總是會花費比你預期更多的時間，就算是你已經考慮過本條Hofstadter 定理”。

It always takes longer than you expect, even when you take into account Hofstadter’s Law.
- Hofstadter’s Law

我同意。你想改代碼C，當你去改的時候才發現，必須先改了A，才能夠改C。當你把A、C都改好了，你發現，B也需要做聯動修改才能正常工作。有沒有辦法預估出所有要做的改動呢，當然可以，但是花費的時間並不比改代碼少，誰願意讓自己完成工作的時間加倍呢是吧。

4、有些遇到問題的人總是會說“我知道，我會使用Regex”，那麼，你現在有兩個問題了。（意思是：你本想用Regex來解決你已有問題，但實際上你又引入了“Regex”的一個新問題）

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems
- Jamie Zawinski

這個問題，大概和上一條有些聯絡。

5、偵錯工具的難度是寫代碼的兩倍。因此，如果你的代碼寫的太聰明了，恐怕就沒能力調試它了。

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
- Brian Kernighan

距我理解，這是告誡程式員，寫代碼不要太用技巧。可讀性、可維護性、可調試性往往更為重要。確實，讓代碼盡量的好讀、好調試，會使你的代碼變得缺乏技巧，有失水準，甚至效能變差、佔用記憶體變多。但是，從現代軟體工程的角度來說，大部分時候，可讀性與可調試性更為重要。

6、用程式碼數來衡量開發進度，無異於用重量來衡量製造飛機的進度。

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
- Bill Gates

在一個軟體系統中，有些代碼，不用動腦子，光動手就可以寫出來。有些代碼，僅有幾句，卻需要花費巨大的推理演算才能寫下來。不同的代碼，含金量不同。我想，比爾蓋子還想表達另一層意思：軟體開發中隨時都有意外情況，10000行代碼，你寫了9999行，一切都很順利，但前面的9999行代碼的順利並不代表後面的代碼也會順利，也許就在你寫完第10000行代碼，以為大功告成的時候，程式崩潰了。

原文：http://blog.csdn.net/haoel/archive/2009/06/01/4233454.aspx