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

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

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

程序員即是寫程序的人，編程即是寫程序的過程。

現(xiàn)在再讓我們?yōu)樯厦娴亩x加上一些限制條件。

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

• 輸出要優(yōu)雅（原文beautiful）。
• 輸入要優(yōu)雅。
• 程序本身要優(yōu)雅。
• 輸入文檔詳盡準確。
• 程序本身的文檔詳盡準確。
• 程序經(jīng)歷過嚴格的測試，能夠保證正確的結果。
• 程序提供的解決方案的文檔詳盡。
• 程序要解決的問題本身的文檔詳盡。

當添加了這些限制之后，編程就變得非常困難了。對于一些特定的情況，我們可以適當放寬以上的限制條件。下面就來介紹幾種典型的情況：

不需要維護的程序

我們寫程序常常只是為了輸出。這種情況下，輸入和程序本身并不一定要考慮未來維護的問題，也不必一定要寫得那么優(yōu)雅并配備詳盡的文檔。

我寫過的一本關于Erlang的書的排版程序就是這種情況。當這本書發(fā)表之后，再維護輸入和排版程序就顯得沒什么必要了。只要輸出看起來不錯就可以了，雜亂的XML輸入文件和測試程序不需要維護。

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

需要被維護的程序

需要被維護的程序剛好和上面的情況相反。輸入和程序本身要優(yōu)雅，相關文檔也要詳盡。

我前些天和一個寫網(wǎng)絡應用的顧問聊天，他說只要程序的輸出了正確的結果（網(wǎng)站看起來沒什么問題各種功能也能正常工作），用戶就認定這個項目已經(jīng)完成了然后項目經(jīng)理就把他加進下一個項目組里。

他們不明白對于網(wǎng)站來講僅僅看起來OK是不夠的，也根本沒有預留時間給整理代碼，編寫文檔這些對未來網(wǎng)站維護有幫助的事情，下一個項目就開始了。

其他使編程變得困難的事

還有三件事會使編程變得困難：

• 處理本來不應當出現(xiàn)的問題。
• 沒有慢吞吞地學習新知識的時間。
• 苛刻的系統(tǒng)環(huán)境。

就讓我們來看看程序員的時間是怎樣被這些家伙吃掉的吧。

處理本來不應當出現(xiàn)的問題

我經(jīng)常要用一些別人編寫的軟件來解決問題，但我往往并不能夠很好地理解這些程序。

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

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

利用Google搜索一個bug的解決方案簡直像賭博一樣令人沮喪。我用Google搜索了半天終于發(fā)現(xiàn)了一個倒霉蛋也遇到和我一模一樣的問題，哈哈哈哈哈。但是當我滿懷期盼地點開鏈接的時候。。。什么都沒有，這個問題還沒有人解答。

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

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

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

問題的關鍵在于諸如此類的事情占據(jù)了程序員60%到70%的時間。我曾經(jīng)花了一周才讓一個出問題的LDAP服務器重新工作了，因為老大不讓我自己寫這個服務器。我在折騰了一周這個用C語言開發(fā)的，文檔寫得很爛的破玩意之后，終于決定把老大的話拋在腦后，用中午吃飯的時間自己寫了一個Erlang的版本，問題才終于解決了。

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

現(xiàn)在我已經(jīng)不會對實現(xiàn)那些古董級的協(xié)議感到興奮了，但一般說來和用別人的代碼相比自己重新實現(xiàn)往往會節(jié)省更多的時間。

解決問題和學習是不同的

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

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

以排版程序為例，我曾經(jīng)在這三款軟件面前搖擺不定：Tex／Latex，XSLT－FO，Erlguten。

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

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

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

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

有些工作場所的設計使編程更加困難，無隔板開放式辦公室那嘈雜的環(huán)境，破壞了我們的注意力，移動電話的打擾，以及互聯(lián)網(wǎng)都會分散我們的注意力。

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

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

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

做一名優(yōu)秀程序員需要很長的時間，你需要學習很多東西，當遇到問題的時候，你需要知道向誰請教。

驚人但是事實

當我完成本文檢查內(nèi)容的拼寫時,但我使用emacs-ispell模式檢查拼寫,它罷工了,并顯示沒發(fā)現(xiàn)aspell

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

我不相信上帝有惡意,也不相信我房間里左手沙發(fā)的物理定律和我右手的不同,但有間接證據(jù)表明正好相反.

我不明白我明明什么都沒做,我的拼寫檢查器就出了問題.為了檢查上次文檔的拼寫,我安裝一個Erlang新版本和Julia,并寫下了一些講義

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

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

英文原文：Why Programming is Difficult

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