程序員需要克服的10大障礙
軟件開發中最艱巨的任務其實并不是代碼。寫代碼是一種鍛煉，一種邏輯思維上的鍛煉，相比于開發人員在日常工作中要執行的其他任務，它可顯得可愛多了。如果你覺得自己才剛剛跨入這個行業，只能算個業余程序員，那么為了確保能躋身專業領域，有些障礙你必須得克服……
1.解釋做了什么
解釋軟件開發過程是很讓人崩潰的一件事。那些不會寫代碼的家伙可能在這一行有所了解，但是正如定義所說的，他們不會寫代碼。在他們眼中，我們就是一群待在昏暗的房間中弓著背噼里啪啦敲鍵盤的程序猿。
搞不好你的朋友家人還有同事，甚至有可能會有編碼“不是正當職業”的想法呢，呵呵。
2.可視化解決方案
假設給定一組簡單的——難聽點說就是考慮不周的——需求，你需要制定數據存儲庫、代碼結構、算法、通信協議，以及只要能解決業務問題就得去完成的各種技術內容。然后，還需要用一種通俗易懂，哪怕是外行人也能明白的方式解釋出來，并在規定期限內交付給客戶。
很少有開發人員能真正做好這一點。
3.預估交付時間
這是每個開發人員的噩夢。試想一下，以前一點也沒有接觸過的任務，突然要你確定完成它所需要的時間，是不是有點天方夜譚呢？可能曾經也寫過類似的代碼，但是卻并不是在有著相同問題和限制的同一個系統中，好吧！
這個時候，那真的只能靠經驗了。但是大多數程序員會低估時間，原因可能是因為他們只考慮了編碼這部分而忽略了其他。
4.借鑒別人的代碼
條條大路通羅馬，解決方案也是。借鑒別人的代碼可能意味著要花上很多時間去研究上千行代碼以了解整個的思路。而且，要是恰巧原先的開發人員一點也不留注釋和文檔的話——甚至只是個半途而廢的半成品項目——那就更加令人頭大了！
5.范圍蠕變和你自認為神奇的功能
敏捷開發會造成范圍蠕變，這讓人既沮喪又無奈——特別是當你突然心血來潮要加點什么愚不可及的功能的話，更甚。結果如何你自己心知肚明，你的團隊也 明白失敗沒商量。但是客戶其實知道得更清楚，所以要是失敗不可避免地降臨時，那么就全都是你的責任，因為你居然不相信客戶的眼光。
6.優化不足和過度優化之間的平衡
復雜的軟件永遠達不到完美的境界。我們不可能無限制地優化，這也是為什么軟件項目從不在規定日期到來之前發布的原因。
另一方面，很多人都會抱有“先就這樣吧——以后再來改進”的心態。現在這些代碼是可以好好工作，但是這些人也明白這會成為明日的煩惱和失敗。當然，你不會再來修復和調試了，它們會被留給下一個可憐的開發人員。
7.測試代碼
既可以自己編寫單元測試，也可以組團通過軟件來測試，不過不要妄想能發現所有bug……
- 復雜的軟件可能會包含成千上萬行代碼。系統可能有著數十億種可能的相互作用和路徑，想要全部測試是不可能的。
- 同樣的，一個軟件在不同的條件下，不同的系統里碰到的軟件不同，其交互的結果也不盡相同。我們沒辦法測試所有可能的情況。
- 想要編寫出好的單元測試是一件既繁瑣又艱難的工作。在理想情況下，測試應該在軟件開發項目開工之前就寫好——但是要是我們先寫這個的話，我們怎么向客戶解釋四個星期過去了為什么一點進程都沒有？
- 單元測試不會突出顯示每一個bug。雖然我們都希望能有一個專門的小組來編寫測試然后積極去發現問題，但是由于現實條件的限制——成本控制和時間 限制，這對于很多項目而言都是奢望，所以大都需要開發團隊自己來編寫測試。而他們在編寫時總是會無意識地避免任何不妥當的邊界情況。
- 程序員會用一種邏輯方式去解決問題，但是用戶很少會這樣做；所以有時候用戶會幫我們找到一些我們自己察覺不出來或者根本想不到的問題。
8.寫代碼文檔
寫文檔的確是費時又費力。很少有開發人員擅長并愿意花時間去寫/閱讀文檔。
9.處理硬件問題
我們每天都需要處理各種技術問題，例如硬盤崩潰、驅動沖突、軟件故障等等。雖然這并非是我們軟件開發人員的工作，但是要是不解決這些的話，我們是沒法繼續工作的。
然而很多人卻會莫名其妙地認為，搞IT的就應該懂所有關于電腦的東西。當他們碰到問題，他們第一時間想的就是聯系我們來解決，而且不管什么問題都這樣，真心是讓人無語又崩潰。
當然這些中斷時間不應該對交付進度產生影響或者增加成本，但是這可能嗎？
10.和人打交道
上述任務通通可以總結為“如何與人打交道”。令人奇怪的是，非專業人士不會去指點飛行員應該如何駕駛飛機，也不會跑去和電工說我的房子需要重新布線等等，但是他們卻非常喜歡在軟件開發上面指手畫腳，提供各種異想天開的點子。
關于這一點，我還真提不出什么好的解決方法，所以，唉，各位，我們還是接受有一半的地球人他們的IQ低于平均值的事實吧！
譯文鏈接：http://原網站已經失效/article/10-toughest-task-in-programming.html
英文原文：The Ten Toughest Tasks in Development
翻譯作者：碼農網 – 小峰