開發(fā)
1.從小事做起蓬戚，然后再擴(kuò)展
無(wú)論是創(chuàng)建一個(gè)新的系統(tǒng)，還是添加功能到現(xiàn)有的系統(tǒng)中箫攀，我總是從一個(gè)簡(jiǎn)單到幾乎沒有任何所需功能的版本啟動(dòng)，然后再一步一步地解決問(wèn)題幼衰，直到滿意為止靴跛。我從來(lái)沒有妄想過(guò)能夠一步登天。相反塑顺，我一邊開發(fā)一邊學(xué)習(xí)汤求，同時(shí)新掌握的信息還可以用于解決方案中俏险。
我很喜歡John Gall的這句話：“復(fù)雜系統(tǒng)總是源于簡(jiǎn)單系統(tǒng)的演化严拒。”
small-things.jpg
2.一次只改變一件事
當(dāng)我們?cè)陂_發(fā)時(shí)竖独，碰到測(cè)試失敗和功能無(wú)效的情況裤唠，如果你一次只研究一個(gè)問(wèn)題，那將會(huì)更容易找到問(wèn)題的關(guān)鍵莹痢。換言之种蘸，就是使用短迭代。必須確保這個(gè)問(wèn)題解決之后竞膳，再轉(zhuǎn)移到另一個(gè)問(wèn)題上航瞭。這適用于向下提交。如果在你添加新功能之前需要先重構(gòu)代碼坦辟，那么先提交重構(gòu)刊侯，然后再添加新的功能。
3.盡早地添加日志記錄和錯(cuò)誤處理
在開發(fā)新系統(tǒng)時(shí)锉走，我做的第一件事就是添加日志和錯(cuò)誤處理滨彻，因?yàn)檫@兩者從一開始就非常有用。如果系統(tǒng)不能照常工作挪蹭，那么你就需要知道程序中發(fā)生了什么——這是日志的作用亭饵。錯(cuò)誤處理也是如此——錯(cuò)誤和異常越早處理越好。
4.每一行新代碼必須至少執(zhí)行一次
在你真正完成一個(gè)功能之前梁厉，你必須對(duì)它進(jìn)行測(cè)試辜羊。不然，你怎么知道它是不是按照你的想法在執(zhí)行呢词顾？通常情況下八秃，最好的方法是通過(guò)自動(dòng)測(cè)試，但并非總是如此计技。不過(guò)喜德，不管怎么說(shuō)，每一行新代碼必須至少執(zhí)行一次垮媒。
5.在整體測(cè)試之前先進(jìn)行模塊測(cè)試
先進(jìn)行部分模塊測(cè)試可以節(jié)省時(shí)間舍悯。通常說(shuō)來(lái)航棱，我們?cè)谡喜煌哪K時(shí)也會(huì)出現(xiàn)問(wèn)題，例如模塊之間的接口不匹配萌衬。但是如果我們能夠信任各個(gè)組件的話饮醇，那么跟蹤集成問(wèn)題就會(huì)變得簡(jiǎn)單得多。
6.所有事情所花費(fèi)的時(shí)間總是比你預(yù)期的要長(zhǎng)
特別是在編程中秕豫，即使一切進(jìn)展順利朴艰，我們也很難對(duì)功能所需的時(shí)間做出正確的預(yù)算。并且混移，開發(fā)軟件時(shí)碰到各種意想不到的問(wèn)題是非常常見的祠墅。
侯世達(dá)定律其實(shí)道出了真諦：做事所花費(fèi)的時(shí)間總是比你預(yù)期的要長(zhǎng)，即使你在預(yù)期中已經(jīng)考慮了侯世達(dá)定律歌径。
7.先了解現(xiàn)有的代碼
大多數(shù)的編碼都需要以某種方式改變現(xiàn)有的代碼毁嗦。即使是新功能，也需要適應(yīng)現(xiàn)有的程序回铛。所以狗准，在你加進(jìn)去新的內(nèi)容前，首先需要了解當(dāng)前的解決方案茵肃。否則腔长，你一不小心就很有可能會(huì)打破現(xiàn)有的功能。這意味著验残，閱讀代碼和編寫代碼都是必要的技能捞附。這也是為什么看似微小的變化仍可能需要很長(zhǎng)時(shí)間才能解決的原因之一——你首先必須了解上下文。
8.閱讀和運(yùn)行
幸運(yùn)的是胚膊，對(duì)于理解代碼故俐，我們有兩種互補(bǔ)的方法肃弟。你可以閱讀代碼窖剑，也可以運(yùn)行代碼。運(yùn)行代碼的確是個(gè)非常棒的好方法白魂。所以喻犁，請(qǐng)確保充分利用這兩種方法槽片。
故障排除
9.bug總是難免的
我不喜歡那些宣稱軟件開發(fā)可以“一蹴而就”的高談闊論。不論你再怎么費(fèi)盡心機(jī)肢础，bug總是難免的还栓。最好能夠做成可以快速故障排除、修復(fù)bug和部署修復(fù)的系統(tǒng)传轰。
10.解決故障報(bào)告
每個(gè)開發(fā)人員都應(yīng)該花時(shí)間去處理來(lái)自客戶的故障報(bào)告剩盒，并修復(fù)bug。這能讓你更好地理解客戶的意圖慨蛙，明白如何使用系統(tǒng)辽聊，知道排除故障的難易程度纪挎，了解系統(tǒng)的設(shè)計(jì)情況。這也是為自己的開發(fā)成果負(fù)責(zé)的好方法跟匆。
11.重現(xiàn)問(wèn)題
修復(fù)bug的第一步就是重現(xiàn)問(wèn)題异袄。然后你得確保修復(fù)之后，問(wèn)題能夠徹徹底底地消失玛臂。這樣一個(gè)簡(jiǎn)單的規(guī)則可以確保你不會(huì)誤將非問(wèn)題當(dāng)作是問(wèn)題烤蜕，并確保解決方案真的能夠奏效。
12.修復(fù)已知錯(cuò)誤迹冤，然后再看看有沒有遺漏的地方
有時(shí)候讽营，可能同時(shí)存在著幾個(gè)不同的問(wèn)題。它們之間的互相作用叁巨，可能會(huì)讓你毫無(wú)頭緒斑匪，束手無(wú)策。不要糾結(jié)于搞清楚發(fā)生了什么锋勺，先去解決所有已知的問(wèn)題，然后再看看還有什么不對(duì)的地方狡蝶。
13.沒有巧合
在測(cè)試和故障排除時(shí)庶橱，不要相信會(huì)出現(xiàn)什么巧合。就像你改變了定時(shí)器的值贪惹，那么就會(huì)改變系統(tǒng)重啟的頻率苏章。所以一切都并非是巧合。添加新功能奏瞬，另一個(gè)不相干的功能變慢了枫绅？這絕對(duì)不是巧合。相反硼端，是你應(yīng)該仔細(xì)調(diào)查的內(nèi)容并淋。
14.關(guān)聯(lián)時(shí)間戳
在故障排除時(shí)，事件的時(shí)間戳可以作為你的好幫手珍昨。尋找偶數(shù)增量县耽。例如，如果系統(tǒng)重啟了镣典，并且剛剛發(fā)出過(guò)一個(gè)3000毫秒左右的請(qǐng)求兔毙，那么可能是觸發(fā)了某個(gè)定時(shí)器，才導(dǎo)致出現(xiàn)重啟的動(dòng)作兄春。
團(tuán)隊(duì)合作
coperation-one.jpg
15.面對(duì)面的交流最有效
當(dāng)我們需要討論如何解決問(wèn)題時(shí)澎剥，那么面對(duì)面的交流比視頻、打電話和電子郵件都要好赶舆。
16.橡皮鴨法
遇到你絞盡腦汁也解決不了的問(wèn)題時(shí)哑姚，不妨找一個(gè)同事趾唱，然后將問(wèn)題解釋給他們聽。很多時(shí)候蜻懦，當(dāng)你在敘述時(shí)甜癞，即使你的同事一言不發(fā)，你可能也會(huì)突然靈光乍現(xiàn)找到問(wèn)題的關(guān)鍵宛乃。
17.問(wèn)問(wèn)題
閱讀和運(yùn)行代碼往往非常有助于指出代碼的目的和它的工作原理悠咱。但是如果你有機(jī)會(huì)咨詢那些更為了解的人（例如原來(lái)的程序員），那么千萬(wàn)不要錯(cuò)過(guò)征炼。
18.共享榮譽(yù)
不要貪圖榮譽(yù)析既，該是誰(shuí)的就是誰(shuí)的。例如：“Marcus想出了這個(gè)主意……”（如果真是他想的話）谆奥，而不要說(shuō)“我們想出的……”眼坏。
其他
19.嘗試
如果你不知道某種編程語(yǔ)言功能的工作原理，那么不妨寫一個(gè)小程序來(lái)理解它是如何工作的酸些。這同樣適用于測(cè)試你正在開發(fā)的系統(tǒng)宰译。如果我將參數(shù)設(shè)置為-1，會(huì)發(fā)生什么魄懂？當(dāng)我在重啟系統(tǒng)時(shí)沿侈，如果服務(wù)當(dāng)?shù)簦瑫?huì)發(fā)生什么市栗？以此來(lái)研究它的工作原理缀拭。
20.帶著問(wèn)題睡覺
如果你正在解決一個(gè)很難的問(wèn)題，那么不妨帶著問(wèn)題睡覺填帽。有科學(xué)研究表明蛛淋，這樣做雖然你表明上并沒有在主動(dòng)思考，但你的潛意思卻這么做了篡腌。其結(jié)果就是褐荷，第二天再去研究問(wèn)題，解決方案已經(jīng)呼之欲出了哀蘑。
21.跳槽
不要害怕跳槽诚卸。和不同的人共事，開發(fā)不同的產(chǎn)品绘迁，感受不同的公司文化是非常有意思的合溺。
job-change.jpg
22.不斷學(xué)習(xí)
我們需要不斷地學(xué)習(xí)和了解軟件開發(fā)。你可以嘗試不同的編程語(yǔ)言和工具缀台，閱讀軟件開發(fā)的書籍棠赛，接受MOOC課程。相信我，量變才能達(dá)到質(zhì)的飛躍睛约，這些小小的學(xué)習(xí)積累鼎俘，終有一天會(huì)大大地提高你的知識(shí)和能力。
希望這些經(jīng)驗(yàn)?zāi)軐?duì)大家有用辩涝。如有不當(dāng)之處贸伐，敬請(qǐng)指正。
英文原文：Lessons Learned in Software Development
