為神馬說寫程式是很艱難的

  

我曾經認為程式設計很容易， 但多年之後我慢慢意識到我錯了: 一份程式設計師的工作和我理解的"寫程式"是不同的。

起初我覺得程式設計無非就是命令計算機工作， 而這相對來說並不算難。 在工作了二十多年之後，我愈發覺得這實在是非常容易的事情。

定義1：程式是一種由輸入到輸出的變換。

程式設計師即是寫程式的人，程式設計即是寫程式的過程。

現在再讓我們為上面的定義加上一些限制條件。

定義2：程式是一種滿足以下條件的，由輸入到輸出的變換：

• 輸出要優雅（原文 beautiful）。
• 輸入要優雅。
• 程式本身要優雅。
• 輸入文件詳盡準確。
• 程式本身的文件詳盡準確。
• 程式經歷過嚴格的測試，能夠保證正確的結果。
• 程式提供的解決方案的文件詳盡。
• 程式要解決的問題本身的文件詳盡。 

當新增了這些限制之後，程式設計就變得非常困難了。對於一些特定的情況，我們可以適當放寬以上的限制條件。下面就來介紹幾種典型的情況：

不需要維護的程式

我們寫程式常常只是為了輸出。這種情況下，輸入和程式本身並不一定要考慮未來維護的問題，也不必一定要寫得那麼優雅並配備詳盡的文件。

我寫過的一本關於 Erlang 的書的排版程式就是這種情況。當這本書發表之後，再維護輸入和排版程式就顯得沒什麼必要了。只要輸出看起來不錯就可以了，雜亂的 XML 輸入檔案和測試程式不需要維護。

如果這本書再版，訂正只需要稍微更改一下輸入就可以了。即使輸入檔案沒有詳細的文件，這件事做起來也非常容易。

需要被維護的程式

需要被維護的程式剛好和上面的情況相反。輸入和程式本身要優雅，相關文件也要詳盡。

我前些天和一個寫網路應用的顧問聊天，他說只要程式的輸出了正確的結果（網站看起來沒什麼問題各種功能也能正常工作），使用者就認定這個專案已經完成了然後專案經理就把他加進下一個專案組裡。

他們不明白對於網站來講僅僅看起來 OK 是不夠的，也根本沒有預留時間給整理程式碼，編寫文件這些對未來網站維護有幫助的事情，下一個專案就開始了。

其他使程式設計變得困難的事

還有三件事會使程式設計變得困難：

• 處理本來不應當出現的問題。
• 沒有慢吞吞地學習新知識的時間。
• 苛刻的系統環境。

就讓我們來看看程式設計師的時間是怎樣被這些傢伙吃掉的吧。

處理本來不應當出現的問題

我經常要用一些別人編寫的軟體來解決問題，但我往往並不能夠很好地理解這些程式。

一款優秀的軟體有準確的文件告訴我如何使用它，但真實世界中的情況常常要糟糕得多：不是沒有文件就是文件寫得不準確。

文件這樣寫道：“依次執行 XYZ 命令，就會得到結果 PQR。”而你執行 XYZ 之後得到的結果根本不是 PQR！這種情況下你要怎麼辦？如果你足夠走運，寫這個程式的老兄就在附近，你大可以走上去掐死他；大多數人只能去 Google 一下試試運氣，或者試著讀一下原始碼看看能否找到答案。

利用 Google 搜尋一個 bug 的解決方案簡直像賭博一樣令人沮喪。我用 Google 搜尋了半天終於發現了一個倒黴蛋也遇到和我一模一樣的問題，哈哈哈哈哈。但是當我滿懷期盼地點開連結的時候。。。什麼都沒有，這個問題還沒有人解答。

為什麼這個補丁別人可以用我就不行，是因為我衰神附體了嗎？還是我所處的空間扭曲到正常人類世界的物理定律已經失效的地步？雖然這很令人沮喪，但不同的機器初始狀態會不一樣也很正常，因此能夠解決別人 bug 的補丁在我的機器上可能並不適用。

有時我會這樣想：要是我們都用 Smalltalk 程式設計，都從同樣的起始狀態開始執行就好了。Smalltalk 程式設計師一定生活在一個根本不用擔心這種問題的美好的世界裡，但那也只是暫時的，當他們的程式和其他語言編寫的程式通訊的時候，他們終究會明白這個世界有多麼的殘酷。

排查程式的錯誤也是令人沮喪的，因為你並不清楚 bug 最後到底為什麼消失了，是因為你最後一次的改動嗎？還是因為你之前所有改動效果的總和？

問題的關鍵在於諸如此類的事情佔據了程式設計師 60% 到 70% 的時間。我曾經花了一週才讓一個出問題的 LDAP 伺服器重新工作了，因為老大不讓我自己寫這個伺服器。我在折騰了一週這個用C語言開發的，文件寫得很爛的破玩意之後，終於決定把老大的話拋在腦後，用中午吃飯的時間自己寫了一個 Erlang 的版本，問題才終於解決了。

我承認我寫的並不是一個完整的 LDAP 伺服器，但我也不需要一個完整的 LDAP 伺服器，只要其中的一些命令列可以工作就可以了，這解決起來非常容易。

現在我已經不會對實現那些古董級的協議感到興奮了，但一般說來和用別人的程式碼相比自己重新實現往往會節省更多的時間。

解決問題和學習是不同的

我是一個徹頭徹尾的懶鬼。當我想用 Latex 插入一個圖表的之前我不想先看完 391 頁文件。你當然可以指責我懶惰，我也明白照理來說我應當先把那篇熱情洋溢的文件讀完，但我只有十分鐘，根本沒法讀完那篇文件。

當我需要解決問題的時候，我需要的是快速的解決方案，這個時候過於冗長的說明文件對我我來說就是災難。

以排版程式為例，我曾經在這三款軟體面前搖擺不定：Tex／Latex，XSLT－FO，Erlguten。

差不多每三年我都會強烈地想使用 postscript 來寫文件，每當我有這種感覺的時候，我都會深吸一口氣，然後靜靜地等待這種感覺自己消失。

我猜詹巴蒂斯塔波多尼在 1818 年製作他的 Manuale Tipografico (詹巴蒂斯塔波多尼的 Manuale Tipografico 被稱為最偉大的模式標本的書的印刷。發行追授於 1818 年在帕爾馬由波多尼的忠實遺孀瑪格麗特，兩卷本著作中包含的 142 羅馬字母琳琅滿目相應斜體，許多指令碼和異國情調的字型，以及鮮花和裝飾品驚人的集合)無人問津，可能排版一頁都要耗時一週，讓機器完成枯燥而危險的任務可以使我們解放出更多的時間

我問過我的老闆，他是否需要漂亮的幻燈片來演講。他說需要，但要我明天之前給他。這讓我沒有合適的時間來學習 TeX (我猜可能需要一兩年)，沒時間實現自己的排版語言(我猜需要5-10 年)，沒時間把它記載到附錄中，我權衡了需要時間去學習的幾個方案，最終選擇了 PowerPoint。

惡劣的程式設計環境

有些工作場所的設計使程式設計更加困難，無隔板開放式辦公室那嘈雜的環境，破壞了我們的注意力，行動電話的打擾，以及網際網路都會分散我們的注意力。

幸運的是我們還有可去的地方，那就是睡覺。很多程式設計問題是在睡覺過程中解決的。

有兩種方法：首先將考慮的問題記住，然後睡覺，第二天醒來一些問題就被解決了，So Easy；

另一種方法是睡覺前在一些論壇或者用 tweet 發個帖子，第二天已經有人將解決方法發給你了。

做一名優秀程式設計師需要很長的時間，你需要學習很多東西，當遇到問題的時候，你需要知道向誰請教。

驚人但是事實

當我完成本文檢查內容的拼寫時，但我使用 emacs-ispell 模式檢查拼寫，它罷工了，並顯示沒發現 aspell

我的 emacs 拼寫檢查器在本地忠實的工作了好幾年。就在我抱怨生活一成不變時，它跌破我的眼鏡。

我不相信上帝有惡意，也不相信我房間裡左手沙發的物理定律和我右手的不同，但有間接證據表明正好相反。

我不明白我明明什麼都沒做，我的拼寫檢查器就出了問題。為了檢查上次文件的拼寫，我安裝一個 Erlang 新版本和 Julia，並寫下了一些講義

幸運的是，11 分鐘如同在 Google 賭場工作。 第二個建議性的工作:我不知道問什麼我的 emacs 不能找到 aspell-生命太短，問題太莫名。

我猜有些事我們永遠不知道答案。

英文原文：Why Programming is Difficult