[[91529]]

本文的作者： Craig Buckler

程序員最艱巨的任務(wù)跟編寫(xiě)代碼沒(méi)有多少關(guān)系。編碼是邏輯思路的一種實(shí)踐，這跟程序員日常工作中的其它任務(wù)比起來(lái)相對(duì)簡(jiǎn)單。如果你認(rèn)為自己還是一個(gè)水平一般的程序員，在你真正的能進(jìn)入到高手行列前，請(qǐng)確保你已經(jīng)克服了下列晉級(jí)的障礙。

1. 解釋你在干什么

解釋軟件開(kāi)發(fā)過(guò)程是一個(gè)很困難的事情。那些非程序員職業(yè)的人也許知道很多關(guān)于編程的事情，但很顯然，他們不會(huì)編程。對(duì)于他們來(lái)說(shuō)，我們的生活就是在一間黑暗的屋子里趴在鍵盤(pán)前消耗著咖啡。

你會(huì)在你的朋友、家人和同事中遇到這樣的人，他會(huì)認(rèn)為編碼不是一個(gè)正確的職業(yè)。

2. 形象的說(shuō)出軟件解決方案

根據(jù)一些簡(jiǎn)短的需求——通常是一知半解的，你需要設(shè)計(jì)出數(shù)據(jù)結(jié)構(gòu)，軟件架構(gòu)，代碼算法，通信協(xié)議，以及其它所有針對(duì)商業(yè)問(wèn)題的解決方案各種組成部分。然后你需要用一種外行人聽(tīng)的懂的術(shù)語(yǔ)將它們表達(dá)出來(lái)，并需要在規(guī)定的時(shí)間里提交給客戶(hù)。

很少有程序員能做好這些。

3. 評(píng)估工期

這是程序員痛苦的根源。在開(kāi)發(fā)任務(wù)沒(méi)有完成之前，你是絕對(duì)沒(méi)有可能確定完成這個(gè)任務(wù)需要的時(shí)間。也許程序跟以前寫(xiě)的很相似，但環(huán)境變了，問(wèn)題變了，限制條件變了。

經(jīng)驗(yàn)會(huì)提供一定的判斷力，但大部分的程序員都習(xí)慣于低估問(wèn)題難度。這其中的原因是他們只考慮編碼方面的因素，而忽略了這個(gè)任務(wù)清單上的其它事務(wù)。

4. 維護(hù)他人的代碼

針對(duì)一個(gè)問(wèn)題可能會(huì)有一萬(wàn)種解決方案，一萬(wàn)種寫(xiě)法。接手別人寫(xiě)的代碼，意味著你要花無(wú)數(shù)的時(shí)間在成千上萬(wàn)的代碼行里探索，理解當(dāng)初作者的思路。而且，如果是一個(gè)不相信注釋和文檔的程序員留下的半個(gè)項(xiàng)目，麻煩就更大了。

5. 軟件邊界的模糊蔓延和讓人吐血的奇怪功能需求

雖 然敏捷開(kāi)發(fā)方法給軟件范圍的膨脹提供了一定的預(yù)備空間，但這并沒(méi)有起到任何的作用——尤其是當(dāng)你遇到一些由一時(shí)興起的怪念頭產(chǎn)生的功能需求。你知道這樣做 必定會(huì)失敗。你的團(tuán)隊(duì)知道這樣做必定會(huì)失敗。但客戶(hù)覺(jué)得很好，而當(dāng)失敗不可避免的出現(xiàn)時(shí)，全是你的錯(cuò)，因?yàn)槭悄銢](méi)有理解他們的真實(shí)意圖。

6. 在缺少優(yōu)化和過(guò)度優(yōu)化之間找到平衡點(diǎn)

復(fù)雜的軟件永遠(yuǎn)不會(huì)做到完美；總會(huì)有一些更好的方案。你完全可以沒(méi)完沒(méi)了的優(yōu)化下去，這就是為什么軟件項(xiàng)目從來(lái)都沒(méi)有提前完工的。

而另一面，“這樣就行了——我以后會(huì)優(yōu)化它的”這種心態(tài)也是常見(jiàn)的。代碼今天好用，但你知道明天可能會(huì)出現(xiàn)麻煩或不能用。當(dāng)然了，你是不需要去修改它的，它將會(huì)留給下一個(gè)倒霉蛋程序員。

7. 測(cè)試你的代碼

單元測(cè)試你也寫(xiě)了，軟件也提交了測(cè)試組，但bug依舊存在…

• 軟件是復(fù)雜的，可能包含成千上萬(wàn)行代碼。系統(tǒng)中可能存在百萬(wàn)的各種交互和邏輯路徑；你不可能完全測(cè)試它們。
• 類(lèi)似的，軟件會(huì)在不同的條件下跟不同的平臺(tái)上的不同的軟件交互。你不可能所有的都測(cè)到。
• 寫(xiě)出好的單元測(cè)試是一種枯燥且辛苦的工作。理想情況下，測(cè)試應(yīng)該在著手開(kāi)發(fā)前就已經(jīng)寫(xiě)好——但你如何向客戶(hù)解釋為什么四個(gè)星期過(guò)去了仍然沒(méi)有可用的軟件？
• 單元測(cè)試并不能覆蓋每個(gè)問(wèn)題點(diǎn)。在理想的世界里，應(yīng)該有一個(gè)獨(dú)立的團(tuán)隊(duì)來(lái)寫(xiě)測(cè)試并積極的去發(fā)現(xiàn)問(wèn)題。不幸的是，對(duì)大多數(shù)項(xiàng)目來(lái)說(shuō)，這樣成本太高，時(shí)間不夠，于是用開(kāi)發(fā)團(tuán)隊(duì)來(lái)寫(xiě)測(cè)試程序。而開(kāi)發(fā)團(tuán)隊(duì)潛意識(shí)的會(huì)避免很多極端的邊界情況。
• 程序員喜歡用符合邏輯的方式處理所有問(wèn)題。但用戶(hù)很少是這樣的。他們會(huì)發(fā)現(xiàn)你永遠(yuǎn)意想不到的問(wèn)題。

8. 寫(xiě)軟件文檔

給代碼寫(xiě)文檔是一項(xiàng)費(fèi)力耗時(shí)的工作。很少有程序員擅長(zhǎng)這個(gè)、喜歡這個(gè)的，并且很少有程序員會(huì)花時(shí)間去讀它們。

9. 處理IT問(wèn)題

你每天都在研究技術(shù)。你也許是一個(gè)HTML或PHP程序員，但你很可能會(huì)遇到一些例如硬盤(pán)損壞、驅(qū)動(dòng)沖突或軟件崩潰的問(wèn)題。解決這些事情不是你的主要責(zé)任，但是，除非你解決了這些問(wèn)題，否者你將無(wú)法繼續(xù)你的開(kāi)發(fā)工作。

不幸的是，對(duì)于IT圈外的人來(lái)說(shuō)，程序員應(yīng)該是軟硬件都精通的人。當(dāng)他們遇到了問(wèn)題，他們自己不花時(shí)間就解決，直接會(huì)找你。不論是遇到什么問(wèn)題：你是用計(jì)算機(jī)的，你一定知道如何將預(yù)算表導(dǎo)入Sage，如何配置Oracle，或?yàn)楹卧谒麄兊暮谳謾C(jī)上發(fā)不出郵件。

當(dāng)然了，這些打攪絕對(duì)不能成為你完不成工作的理由，也沒(méi)有報(bào)酬，不是嗎？

10. 處理人的問(wèn)題

上面的這些難題都可以總結(jié)為“人的問(wèn)題”。很少有外行人會(huì)去建議一個(gè)飛行員如何開(kāi)飛機(jī)或建議一個(gè)電器工程師如何布線。但很多人卻會(huì)興致勃勃的勇敢的建議如何開(kāi)發(fā)軟件。

我相信對(duì)于這些人沒(méi)有什么好辦法。你需要接受這樣的事實(shí)：這世界上有一半的智力是低于平均水平的！

原文鏈接：http://www.sitepoint.com/ten-toughest-tasks-development/

譯文鏈接：http://www.aqee.net/the-ten-toughest-tasks-in-development/