為神馬說寫程序是件不容易的事
我曾經認為編程很容易, 但多年之後我慢慢意識到我錯了: 一份程序員的工作和我理解的"寫程序"是不同的。
起初我覺得編程無非就是命令計算機工作, 而這相對來說並不算難. 在工作了二十多年之後，我愈發覺得這實在是非常容易的事情。
定義 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。
摘自開源中國，譯者鳳陽馬超, 村長大神
譯文鏈接：https://www.oschina.net/translate/why-programming-is-difficult
TAG:計蒜客 |