程式設計師需要克服的10大障礙

解釋軟體開發過程是很讓人崩潰的一件事。那些不會寫**的傢伙可能在這一行有所了解，但是正如定義所說的，他們不會寫**。在他們眼中，我們就是一群待在昏暗的房間中弓著背噼里啪啦敲鍵盤的程式猿。

搞不好你的朋友家人還有同事，甚至有可能會有編碼「不是正當職業」的想法呢，呵呵。

假設給定一組簡單的——難聽點說就是考慮不周的——需求，你需要制定資料儲存庫、**結構、演算法、通訊協議，以及只要能解決業務問題就得去完成的各種技術內容。然後，還需要用一種通俗易懂，哪怕是外行人也能明白的方式解發布來，並在規定期限內交付給客戶。

很少有開發人員能真正做好這一點。

這是每個開發人員的噩夢。試想一下，以前一點也沒有接觸過的任務，突然要你確定完成它所需要的時間，是不是有點天方夜譚呢？可能曾經也寫過類似的**，但是卻並不是在有著相同問題和限制的同乙個系統中，好吧！

這個時候，那真的只能靠經驗了。但是大多數程式設計師會低估時間，原因可能是因為他們只考慮了編碼這部分而忽略了其他。

條條大路通羅馬，解決方案也是。借鑑別人的**可能意味著要花上很多時間去研究上千行**以了解整個的思路。而且，要是恰巧原先的開發人員一點也不留注釋和文件的話——甚至只是個半途而廢的半成品專案——那就更加令人頭大了！

敏捷開發會造成範圍蠕變，這讓人既沮喪又無奈——特別是當你突然心血來潮要加點什麼愚不可及的功能的話，更甚。結果如何你自己心知肚明，你的團隊也明白失敗沒商量。但是客戶其實知道得更清楚，所以要是失敗不可避免地降臨時，那麼就全都是你的責任，因為你居然不相信客戶的眼光。

複雜的軟體永遠達不到完美的境界。我們不可能無限制地優化，這也是為什麼軟體專案從不在規定日期到來之前發布的原因。

另一方面，很多人都會抱有「先就這樣吧——以後再來改進」的心態。現在這些**是可以好好工作，但是這些人也明白這會成為明日的煩惱和失敗。當然，你不會再來修復和除錯了，它們會被留給下乙個可憐的開發人員。

既可以自己編寫單元測試，也可以組團通過軟體來測試，不過不要妄想能發現所有bug……

寫文件的確是費時又費力。很少有開發人員擅長並願意花時間去寫/閱讀文件。

我們每天都需要處理各種技術問題，例如硬碟崩潰、驅動衝突、軟體故障等等。雖然這並非是我們軟體開發人員的工作，但是要是不解決這些的話，我們是沒法繼續工作的。

當然這些中斷時間不應該對交付進度產生影響或者增加成本，但是這可能嗎？

上述任務通通可以總結為「如何與人打交道」。令人奇怪的是，非專業人士不會去指點飛行員應該如何駕駛飛機，也不會跑去和電工說我的房子需要重新佈線等等，但是他們卻非常喜歡在軟體開發上面指手畫腳，提供各種異想天開的點子。

關於這一點，我還真提不出什麼好的解決方法，所以，唉，各位，我們還是接受有一半的地球人他們的iq低於平均值的事實吧！

英文原文：

the ten toughest tasks in development

碼農網– 小峰