程式員最艱巨的任務跟編寫代碼沒有多少關系。編碼是邏輯思路的一種實踐,這跟程式員日常工作中的其它任務比起來相對簡單。如果你認為自己還是一個水準一般的程式員,在你真正的能進入到高手行列前,請確定你已經克服了下列晉級的障礙。
1、 解釋你在幹什麼
解釋軟體開發過程是一個很困難的事情。那些非程式員職業的人也許知道很多關于程式設計的事情,但很顯然,他們不會程式設計。對于他們來說,我們的生活就是在一間黑暗的屋子裡趴在鍵盤前消耗着咖啡。
你會在你的朋友、家人和同僚中遇到這樣的人,他會認為編碼不是一個正确的職業。
2、形象的說出軟體解決方案
根據一些簡短的需求——通常是一知半解的,你需要設計出資料結構,軟體架構,代碼算法,通信協定,以及其它所有針對商業問題的解決方案各種組成部分。然後你需要用一種外行人聽的懂的術語将它們表達出來,并需要在規定的時間裡送出給客戶。
很少有程式員能做好這些。
3、 評估工期
這是程式員痛苦的根源。在開發任務沒有完成之前,你是絕對沒有可能确定完成這個任務需要的時間。也許程式跟以前寫的很相似,但環境變了,問題變了,限制條件變了。
經驗會提供一定的判斷力,但大部分的程式員都習慣于低估問題難度。這其中的原因是他們隻考慮編碼方面的因素,而忽略了這個任務清單上的其它事務。
4、維護他人的代碼
針對一個問題可能會有一萬種解決方案,一萬種寫法。接手别人寫的代碼,意味着你要花無數的時間在成千上萬的代碼行裡探索,了解當初作者的思路。而且,如果是一個不相信注釋和文檔的程式員留下的半個項目,麻煩就更大了。
5、軟體邊界的模糊蔓延和讓人吐血的奇怪功能需求
雖然靈活開發方法給軟體範圍的膨脹提供了一定的預備空間,但這并沒有起到任何的作用——尤其是當你遇到一些由一時興起的怪念頭産生的功能需求。你知 道這樣做必定會失敗。你的團隊知道這樣做必定會失敗。但客戶覺得很好,而當失敗不可避免的出現時,全是你的錯,因為是你沒有了解他們的真實意圖。
6、 在缺少優化和過度優化之間找到平衡點
複雜的軟體永遠不會做到完美;總會有一些更好的方案。你完全可以沒完沒了的優化下去,這就是為什麼軟體項目從來都沒有提前完工的。
而另一面,“這樣就行了——我以後會優化它的”這種心态也是常見的。代碼今天好用,但你知道明天可能會出現麻煩或不能用。當然了,你是不需要去修改它的,它将會留給下一個倒黴蛋程式員。
7、 測試你的代碼
單元測試你也寫了,軟體也送出了測試組,但bug依舊存在…
- 軟體是複雜的,可能包含成千上萬行代碼。系統中可能存在百萬的各種互動和邏輯路徑;你不可能完全測試它們。
- 類似的,軟體會在不同的條件下跟不同的平台上的不同的軟體互動。你不可能所有的都測到。
- 寫出好的單元測試是一種枯燥且辛苦的工作。理想情況下,測試應該在着手開發前就已經寫好——但你如何向客戶解釋為什麼四個星期過去了仍然沒有可用的軟體?
- 單元測試并不能覆寫每個問題點。在理想的世界裡,應該有一個獨立的團隊來寫測試并積極的去發現問題。不幸的是,對大多數項目來說,這樣成本太高,時間不夠,于是用開發團隊來寫測試程式。而開發團隊潛意識的會避免很多極端的邊界情況。
- 程式員喜歡用符合邏輯的方式處理所有問題。但使用者很少是這樣的。他們會發現你永遠意想不到的問題。
8、寫軟體文檔
給代碼寫文檔是一項費力耗時的工作。很少有程式員擅長這個、喜歡這個的,并且很少有程式員會花時間去讀它們。
9、處理IT問題
你每天都在研究技術。你也許是一個HTML或PHP程式員,但你很可能會遇到一些例如硬碟損壞、驅動沖突或軟體崩潰的問題。解決這些事情不是你的主要責任,但是,除非你解決了這些問題,否者你将無法繼續你的開發工作。
不幸的是,對于IT圈外的人來說,程式員應該是軟硬體都精通的人。當他們遇到了問題,他們自己不花時間就解決,直接會找你。不論是遇到什麼問題:你是用計算機的,你一定知道如何将預算表導入Sage,如何配置Oracle,或為何在他們的黑莓手機上發不出郵件。
當然了,這些打攪絕對不能成為你完不成工作的理由,也沒有報酬,不是嗎?
10、 處理人的問題
上面的這些難題都可以總結為“人的問題”。很少有外行人會去建議一個飛行員如何開飛機或建議一個電器工程師如何布線。但很多人卻會興緻勃勃的勇敢的建議如何開發軟體。
我相信對于這些人沒有什麼好辦法。你需要接受這樣的事實:這世界上有一半的智力是低于平均水準的!

本文作者: Craig Buckler
英文原文:http://www.sitepoint.com/ten-toughest-tasks-development/
譯文位址:http://www.vaikan.com/the-ten-toughest-tasks-in-development/