[[121311]]

軟件開(kāi)發(fā)中最艱巨的任務(wù)其實(shí)并不是代碼。寫(xiě)代碼是一種鍛煉，一種邏輯思維上的鍛煉，相比于開(kāi)發(fā)人員在日常工作中要執(zhí)行的其他任務(wù)，它可顯得可愛(ài)多了。如果你覺(jué)得自己才剛剛跨入這個(gè)行業(yè)，只能算個(gè)業(yè)余程序員，那么為了確保能躋身專業(yè)領(lǐng)域，有些障礙你必須得克服……

1. 解釋做了什么

解釋軟件開(kāi)發(fā)過(guò)程是很讓人崩潰的一件事。那些不會(huì)寫(xiě)代碼的家伙可能在這一行有所了解，但是正如定義所說(shuō)的，他們不會(huì)寫(xiě)代碼。在他們眼中，我們就是一群待在昏暗的房間中弓著背噼里啪啦敲鍵盤(pán)的程序猿。

搞不好你的朋友家人還有同事，甚至有可能會(huì)有編碼“不是正當(dāng)職業(yè)”的想法呢，呵呵。

2. 可視化解決方案

假設(shè)給定一組簡(jiǎn)單的——難聽(tīng)點(diǎn)說(shuō)就是考慮不周的——需求，你需要制定數(shù)據(jù)存儲(chǔ)庫(kù)、代碼結(jié)構(gòu)、算法、通信協(xié)議，以及只要能解決業(yè)務(wù)問(wèn)題就得去完成的各種技術(shù)內(nèi)容。然后，還需要用一種通俗易懂，哪怕是外行人也能明白的方式解釋出來(lái)，并在規(guī)定期限內(nèi)交付給客戶。

很少有開(kāi)發(fā)人員能真正做好這一點(diǎn)。

3. 預(yù)估交付時(shí)間

這是每個(gè)開(kāi)發(fā)人員的噩夢(mèng)。試想一下，以前一點(diǎn)也沒(méi)有接觸過(guò)的任務(wù)，突然要你確定完成它所需要的時(shí)間，是不是有點(diǎn)天方夜譚呢？可能曾經(jīng)也寫(xiě)過(guò)類似的代碼，但是卻并不是在有著相同問(wèn)題和限制的同一個(gè)系統(tǒng)中，好吧！

這個(gè)時(shí)候，那真的只能靠經(jīng)驗(yàn)了。但是大多數(shù)程序員會(huì)低估時(shí)間，原因可能是因?yàn)樗麄冎豢紤]了編碼這部分而忽略了其他。

4. 借鑒別人的代碼

條條大路通羅馬，解決方案也是。借鑒別人的代碼可能意味著要花上很多時(shí)間去研究上千行代碼以了解整個(gè)的思路。而且，要是恰巧原先的開(kāi)發(fā)人員一點(diǎn)也不留注釋和文檔的話——甚至只是個(gè)半途而廢的半成品項(xiàng)目——那就更加令人頭大了！

5. 范圍蠕變和你自認(rèn)為神奇的功能

敏捷開(kāi)發(fā)會(huì)造成范圍蠕變，這讓人既沮喪又無(wú)奈——特別是當(dāng)你突然心血來(lái)潮要加點(diǎn)什么愚不可及的功能的話，更甚。結(jié)果如何你自己心知肚明，你的團(tuán)隊(duì)也明白失敗沒(méi)商量。但是客戶其實(shí)知道得更清楚，所以要是失敗不可避免地降臨時(shí)，那么就全都是你的責(zé)任，因?yàn)槟憔尤徊幌嘈趴蛻舻难酃狻?/p>

6. 優(yōu)化不足和過(guò)度優(yōu)化之間的平衡

復(fù)雜的軟件永遠(yuǎn)達(dá)不到完美的境界。我們不可能無(wú)限制地優(yōu)化，這也是為什么軟件項(xiàng)目從不在規(guī)定日期到來(lái)之前發(fā)布的原因。

另一方面，很多人都會(huì)抱有“先就這樣吧——以后再來(lái)改進(jìn)”的心態(tài)。現(xiàn)在這些代碼是可以好好工作，但是這些人也明白這會(huì)成為明日的煩惱和失敗。當(dāng)然，你不會(huì)再來(lái)修復(fù)和調(diào)試了，它們會(huì)被留給下一個(gè)可憐的開(kāi)發(fā)人員。

7. 測(cè)試代碼

既可以自己編寫(xiě)單元測(cè)試，也可以組團(tuán)通過(guò)軟件來(lái)測(cè)試，不過(guò)不要妄想能發(fā)現(xiàn)所有 bug……

• 復(fù)雜的軟件可能會(huì)包含成千上萬(wàn)行代碼。系統(tǒng)可能有著數(shù)十億種可能的相互作用和路徑，想要全部測(cè)試是不可能的。
• 同樣的，一個(gè)軟件在不同的條件下，不同的系統(tǒng)里碰到的軟件不同，其交互的結(jié)果也不盡相同。我們沒(méi)辦法測(cè)試所有可能的情況。
• 想要編寫(xiě)出好的單元測(cè)試是一件既繁瑣又艱難的工作。在理想情況下，測(cè)試應(yīng)該在軟件開(kāi)發(fā)項(xiàng)目開(kāi)工之前就寫(xiě)好——但是要是我們先寫(xiě)這個(gè)的話，我們?cè)趺聪蚩蛻艚忉屗膫€(gè)星期過(guò)去了為什么一點(diǎn)進(jìn)程都沒(méi)有？
• 單元測(cè)試不會(huì)突出顯示每一個(gè) bug。雖然我們都希望能有一個(gè)專門的小組來(lái)編寫(xiě)測(cè)試然后積極去發(fā)現(xiàn)問(wèn)題，但是由于現(xiàn)實(shí)條件的限制——成本控制和時(shí)間限制，這對(duì)于很多項(xiàng)目而言都是奢望，所以大都需要開(kāi)發(fā)團(tuán)隊(duì)自己來(lái)編寫(xiě)測(cè)試。而他們?cè)诰帉?xiě)時(shí)總是會(huì)無(wú)意識(shí)地避免任何不妥當(dāng)?shù)倪吔缜闆r。
• 程序員會(huì)用一種邏輯方式去解決問(wèn)題，但是用戶很少會(huì)這樣做；所以有時(shí)候用戶會(huì)幫我們找到一些我們自己察覺(jué)不出來(lái)或者根本想不到的問(wèn)題。

8. 寫(xiě)代碼文檔

寫(xiě)文檔的確是費(fèi)時(shí)又費(fèi)力。很少有開(kāi)發(fā)人員擅長(zhǎng)并愿意花時(shí)間去寫(xiě)/閱讀文檔。

9. 處理硬件問(wèn)題

我們每天都需要處理各種技術(shù)問(wèn)題，例如硬盤(pán)崩潰、驅(qū)動(dòng)沖突、軟件故障等等。雖然這并非是我們軟件開(kāi)發(fā)人員的工作，但是要是不解決這些的話，我們是沒(méi)法繼續(xù)工作的。

然而很多人卻會(huì)莫名其妙地認(rèn)為，搞 IT 的就應(yīng)該懂所有關(guān)于電腦的東西。當(dāng)他們碰到問(wèn)題，他們第一時(shí)間想的就是聯(lián)系我們來(lái)解決，而且不管什么問(wèn)題都這樣，真心是讓人無(wú)語(yǔ)又崩潰。

當(dāng)然這些中斷時(shí)間不應(yīng)該對(duì)交付進(jìn)度產(chǎn)生影響或者增加成本，但是這可能嗎？

10. 和人打交道

上述任務(wù)通通可以總結(jié)為“如何與人打交道”。令人奇怪的是，非專業(yè)人士不會(huì)去指點(diǎn)飛行員應(yīng)該如何駕駛飛機(jī)，也不會(huì)跑去和電工說(shuō)我的房子需要重新布線等等，但是他們卻非常喜歡在軟件開(kāi)發(fā)上面指手畫(huà)腳，提供各種異想天開(kāi)的點(diǎn)子。

關(guān)于這一點(diǎn)，我還真提不出什么好的解決方法，所以，唉，各位，我們還是接受有一半的地球人他們的 IQ 低于平均值的事實(shí)吧！

英文原文：The Ten Toughest Tasks in Development

譯文鏈接：http://www.codeceo.com/article/10-toughest-task-in-programming.html