我曾經認為編程很容易, 但多年之后我慢慢意識到我錯了: 一份程序員的工作和我理解的"寫程序"是不同的.

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

定義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

譯文出自：http://www.oschina.net/translate/why-programming-is-difficult