【導(dǎo)讀】：作為程序員，你會如何跟非程序員解釋寫程序不容易這件事?為啥看不見摸不著的程序需要花時間去寫去維護(hù)?很多人其實都沒想明白。來看看 Erlang 之父 Joe Armstrong 的感觸。

編程為什么這么難?

多年前我曾一度認(rèn)為編程很簡單，然而隨著歲月的流逝，我終于意識到編程并不是件容易的事。這是因為，我所認(rèn)為的「究竟什么是編程」和「程序員到底是做什么的」，在感知上已經(jīng)漸漸地發(fā)生了轉(zhuǎn)變。

定義1：所謂程序就是一種把輸入轉(zhuǎn)化為輸出的東西，程序員就是寫程序的人，編程就是寫程序的這個行為;

現(xiàn)在讓我們給我對程序的這個定義加一些約束吧。

定義2： 所謂程序就是在遵從下列約束的條件下，把一些輸入轉(zhuǎn)化為輸出的東西。

• 程序輸出是優(yōu)美的;
• 程序輸入是優(yōu)美的;
• 程序本身也是優(yōu)美的;
• 程序輸入有著完好并正確的文檔;
• 程序本身也是有著完好并正確的文檔;
• 程序是經(jīng)過良好測試過并驗證是正確的;
• 正在解決的問題是十分明確的;
• 整個問題本身也是十分明確的;

加上這些約束后，編程就變得非常困難了?，F(xiàn)在對于一個特定的問題，上述一部分約束是可以放松的。幾個典型的設(shè)想是：

不必持續(xù)維護(hù)的程序

我們經(jīng)常僅僅為了得到輸出結(jié)果而寫程序。 這種情況下，程序的輸入和程序本身以后是不需要維護(hù)的，因此這些不必詮釋地特別優(yōu)美和充分。

我的 Erlang 這本書就是這樣的一個例子。一旦書出版了，為了寫書而使用的程序以及輸入部分就不必在維護(hù)了。程序結(jié)果看起來很優(yōu)美，但是輸入部分只是一堆混亂的 xml 文件，為了寫書而用到的一些測試代碼也永遠(yuǎn)不必保留了。

書的勘誤表和為了后續(xù)重版的一些必要訂正只是涉及到了輸入部分的輕微修改，即使程序的輸入部分并沒有很完善的整理記錄過，這也是很容易操作的。

必須要維護(hù)的程序

對于那些從頭到尾都要進(jìn)行維護(hù)的程序來說就是這種。程序的輸入和程序本身都必須詮釋地特別優(yōu)美，文檔和注釋完整而優(yōu)雅。

我不久之前和一位開發(fā) Web 應(yīng)用程序的計算機(jī)咨詢師聊天。他說一旦程序的輸出看起來沒問題了(即網(wǎng)站看起來不錯，程序似乎也可以運行了)，客戶就會認(rèn)為項目已經(jīng)完成了，項目經(jīng)理就會把他分配到下一個項目上去。

在下一個項目啟動之前，不僅網(wǎng)站要看起來不錯，而且編寫的代碼也應(yīng)該是整理有序并且有案可循的。但是人們沒有空閑時間這么做，也無法理解這個觀點。而這類項目就是在將來需要一直被維護(hù)的。

還有什么因素讓編程困難?

還有其他三個因素讓編程變得困難：

• 修復(fù)本不應(yīng)該出問題的程序
• 沒時間學(xué)習(xí)
• 編程的惡劣環(huán)境

這三個問題全是「時間的小偷」，讓我們具體來看看：

修復(fù)本不該出問題的程序

為了解決某個特定的問題，我經(jīng)常會使用既不是我寫的，我也不是很理解的軟件。最好的情況是，這個我不得不用的程序有一份描述精確的使用說明。 但是往往這個程序要么沒有描述文件要么就是描述文件是錯誤的。

那么， 當(dāng)文件寫著：『做XYZ后，就會發(fā)生PQR』，而你做了『XYZ』后，『PQR』卻沒發(fā)生的時候，你該怎么辦呢?如果你很幸運，寫這個程序的人就在你旁邊，那么你就能直接過去問搞定這些問題。不是這樣的話，你要么用Google碰碰運氣，要么就直接挖出源代碼找答案吧。

用Google這個「大賭場」找怎么修復(fù)bug，真的是讓人極度沮喪的事兒。我簡單 Google 搜索一下，然后會發(fā)現(xiàn)一些記錄，某個可憐不幸的家伙也遇到了和我正好一樣的問題。我喜出望外，顫抖著用手指輸入可以除掉詛咒的魔法指令…..然后…..啥也沒有改變。問題依然存在。

為啥這修復(fù)工作對其他人有效對我沒用呢。難道有個邪惡的神監(jiān)視著我，還是我處于宇宙中暫時不符合物理規(guī)律的局部區(qū)域?我們兩個機(jī)器的初始狀態(tài)不同，因此在一種狀態(tài)內(nèi)修復(fù)一個機(jī)器bug的方法未必能修復(fù)另一種狀態(tài)下機(jī)器的bug。

正像有時候我想用 smalltalk 編程，我們都用一模一樣的程序映像開始著手-Smalltalk 的程序員必須活在這種情況不會發(fā)生的理想的天堂里，但是一旦有一天，甚至他們自己的程序可能不得不和其他程序?qū)υ挼臅r候，好玩兒的事就開始了。修復(fù)被破壞的東西帶來的沮喪是雙重的，即便你已經(jīng)趕走了bug，你也真的并不知道這是不是你要修復(fù)的最后一個問題，也不知道你所做的改變帶來的實際影響。

順便說一句，這類問題耗費了我大部分的時間， 粗率估算一下大概占用60-70%。我曾經(jīng)用了超過一星期的時間試圖讓一個壞了的LDAP服務(wù)器工作，我的老板禁止我執(zhí)行我自己的LDAP服務(wù)器，然而和這個用 C 編碼歸檔混亂的壞了的 LDAP 服務(wù)器斗爭了一周后，我記憶模糊了一些，也忘記了老板說的話，意外地在午餐休息的時候用 Erlang 在 scratch 里成功地運行了服務(wù)器。

老實說，這并不是一個完整的LDAP服務(wù)器，但是我也不需要一個完整的LDAP服務(wù)器。我只想運行一些命令而已，這其實是很容易修復(fù)的。 現(xiàn)在我對執(zhí)行陳舊又變態(tài)的協(xié)議沒有什么樂趣，而通常情況下最快的進(jìn)行方式是在scratch里重新實現(xiàn)他們。

解決問題而不是學(xué)習(xí)

我懶，我就是個懶蟲。當(dāng)我想在LaTeX里放入一個圖表的時候，我不想先讀一遍391頁的操作手冊。現(xiàn)在我猜你肯定會指責(zé)我的懶惰和不健全的品德。我也知道我想應(yīng)該先讀一下這份優(yōu)秀的手冊，但是我想十分鐘內(nèi)在文檔中放入一個圖表，那么讀完391頁的手冊是不可能的。解決這類問題時，我會選擇更快的解決方法—但是長期來看這樣損失慘重。

制作文檔這事兒，我一直猶豫是使用TeX/LaTeX，XSLT-FO還是我自己的 Erlguten。

大約每三年我都有一次強烈的欲望把自己所有的文檔直接在postscript中寫一遍，然而之后我只是做個深呼吸后等這個想法慢慢消失。

我猜 Giambattista Bondoni 在 1818 年發(fā)明他的手工印刷的時候，并沒有特別關(guān)心排版一頁紙是否要花費幾個星期。但是現(xiàn)在我們讓機(jī)器做這些無聊又危險的事兒，我們就有了更多的時間卻沒有時間把事兒做對了。

我問我老板他是否需要一個炫酷的幻燈片做下次的講座，他說需要并要求我在明天之前交給他。這使我沒時間正確地學(xué)Tex(我估計幾年可以完成這個事兒)，也沒時間實現(xiàn)我自己的排版語言(大概要用5年時間)，也沒時間在postscript里直接寫(大概要一周左右)—這樣我估計我還是用PowerPoint吧。

編程的惡劣環(huán)境

如果你讀到了這里，你就會理解我說編程真的很難的話了。原因是工作場所就是設(shè)計來讓編程更難的。我們開放的工作場所，提供了破壞我們聚精會神的吵鬧環(huán)境，打擾我們的手機(jī)和讓我們分心的因特網(wǎng)。

幸運的是，我們可以去不會打擾我們的地方。那就是睡覺。很多編程問題都是在睡覺的時候解決的。

有兩個辦法，第一你把問題上傳到你的大腦里然后睡覺，第二天起床后一些問題就解決了。很簡單。

第二，你把問題在睡前放到網(wǎng)上或者推特上。第二天就會有人發(fā)給你解決辦法了。成為一個好的程序員是需要很長時間的，你需要學(xué)習(xí)很多的知識也需要知道當(dāng)你卡殼的時候去問誰。

令人驚訝的事實

當(dāng)我完成這篇文章的時候，我想檢查下內(nèi)容的拼寫。 emacs的ispell模式罷工了。這個我一直用于拼寫檢查的程序，現(xiàn)在無法搜索到一個拼寫。

我的emacs拼寫檢查器在這臺機(jī)器上忠實的工作了好幾年了。就在我抱怨花費半生時間修復(fù)本不應(yīng)該出問題的程序的時候，我的emacs拼寫檢查器壞掉了。

我不信邪神，也不信我現(xiàn)在打字的起居室沙發(fā)的左邊角落不遵循物理定侓。盡管有些間接的證據(jù)似乎在反駁我。

我不知道我的拼寫檢查器壞掉的原因—一切看起來都沒問題，我沒有改變?nèi)魏螙|西。哦從我上次檢查文本拼寫后，我只安裝了新版的Erlang安裝了Julia，并寫了一些講座筆記而已。

幸運的是，在Google賭場里工作了11分鐘后，第二個如何修復(fù)我的問題的建議起效了。 然而我還是不懂為什么 emacs 不能搜索一個拼寫。人生苦短，來不及找尋所有答案。

我猜大概只是有些事情我們永遠(yuǎn)不會明白罷了。