搭好測試這個安全網(wǎng)
單元測試是最原始的工程概念之一。單元測試對于互聯(lián)網(wǎng)應(yīng)用來說，一般會有一個困難，就是需要大量的“腳手架”，比如為了測試數(shù)據(jù)庫操作，必須要有一段代碼 “重置”數(shù)據(jù)庫的狀態(tài);為了測試網(wǎng)絡(luò)打包解包，則需要用一個程序向某個網(wǎng)絡(luò)端口發(fā)數(shù)據(jù)。而準(zhǔn)備這些測試工具代碼的時間往往會比較長，需要有足夠的耐心去做，但一旦做好了，往往能讓開發(fā)風(fēng)險大大降低。
對于單元測試，我認(rèn)為最少應(yīng)該覆蓋所有正確的路徑，以及重點(diǎn)防御的錯誤路徑。覆蓋了這些重點(diǎn)關(guān)注的地方之后，放手重構(gòu)代碼就很方便了。
單元測試應(yīng)該是屬于代碼的一部分，和源代碼一起存放。自動構(gòu)建時也應(yīng)該進(jìn)行檢查輸出結(jié)果。提交代碼時都會自動運(yùn)行單元測試，當(dāng)“版本樹”需要合并“分支” 時，單元測試尤為重要，而最重要的是在分支上建立的單元測試。這些測試會大大加強(qiáng)系統(tǒng)的穩(wěn)定性，因?yàn)闄z驗(yàn)了“合并”功能產(chǎn)生的代碼—這些代碼是最容易出錯的。
自己掌控開發(fā)方向
開發(fā)工作往往被需求變化“牽著鼻子走”，需求往往會有很多來源：產(chǎn)品策劃的想法、老板的意見、用戶的反饋、數(shù)據(jù)統(tǒng)計的結(jié)論等。提出的各種需求，往往會對開發(fā)團(tuán)隊造成很大壓力。這些問題都需要我們對需求做出有效的管理。然而我們應(yīng)該如何去搜集、記錄、過濾、實(shí)現(xiàn)這些需求呢?
我們需要很好地搜集記錄需求。有的團(tuán)隊會設(shè)立兩面故事墻，任何方面的需求，都可以減縮成一個故事，寫到一張便簽紙上，貼到故事墻上，專人處理，而不會石沉大海。
有的公司會試圖把這個事情用電子化流程來做，但電子化流程有個顯著的缺點(diǎn)，就是為了更多地自動化處理，會加入大量的字段，對于故事這種還未謹(jǐn)慎定義過的東西，要認(rèn)真填寫太多的資料，無疑會給使用者造成額外的負(fù)擔(dān)。
告別救火隊員
在產(chǎn)品進(jìn)入運(yùn)營期間，最牛的程序員似乎總是在充當(dāng)救火員，各種各樣的突發(fā)事件、棘手問題中，我們的“高手”往往疲于奔命，永遠(yuǎn)都在做一些補(bǔ)救的措施。有經(jīng)驗(yàn)的人員一直沒空做開發(fā)，因此大量的代碼由那些水平較差的人來完成，反過來埋下了更多的問題。然而，如果不是忙著亡羊補(bǔ)牢，我們的資深程序員就可以把更多的精力放在開發(fā)上，這些有經(jīng)驗(yàn)的程序員所生產(chǎn)的代碼，又會進(jìn)一步降低出故障的概率，這才是走向良性循環(huán)的方法。
為了減少運(yùn)營期間的壓力，在系統(tǒng)設(shè)計時，就要特別注意關(guān)于可維護(hù)性的非功能需求。運(yùn)營事故當(dāng)中，因?yàn)椴渴疱e誤所導(dǎo)致的占很大一部分，因此降低部署錯誤需要做到：全代碼包發(fā)布，每個發(fā)布版本要包含所有的可執(zhí)行文件;所有的服務(wù)器上部署的配置文件和數(shù)據(jù)文件都必須做到完全一致，降低更新文件的復(fù)雜度。本機(jī)IP地址應(yīng)該用代碼從網(wǎng)卡上直接讀取，但應(yīng)該提供可以配置的選擇，預(yù)備多個IP的服務(wù)器使用;只使用命令行方式來啟動不同功能，如選擇配置文件路徑、輸入不同功能進(jìn)程或服務(wù)器的配置;程序支持關(guān)閉、重載配置這兩個信號。在處理這兩個信號時，都不應(yīng)該讓使用者感覺突然“掉線”;開發(fā)用于安全關(guān)閉程序、重載配置的腳本或功能;開發(fā)用戶自動重啟所部署進(jìn)程的腳本，以及配置開機(jī)自動啟動所部署的進(jìn)程;每個進(jìn)程都不應(yīng)該強(qiáng)行鎖定某資源，必須要能做到一份安裝復(fù)制多進(jìn)程并行運(yùn)行等。
每天發(fā)版
如果你想知道項(xiàng)目每一天的開發(fā)進(jìn)度，你就必須要做到每天發(fā)版，測試每天的工作進(jìn)度，如果要順利地每天發(fā)版，就必須建立一個持續(xù)集成的系統(tǒng)。一般來說持續(xù)集成系統(tǒng)會有以下的先后步驟：單元測試—自動構(gòu)建—自動部署—集成測試—自動發(fā)布。
單元測試關(guān)鍵是要能堅持覆蓋所有新加入的代碼;自動構(gòu)建是由構(gòu)建腳本、構(gòu)建服務(wù)器、持續(xù)集成系統(tǒng)幾部分組成。
對于美術(shù)、產(chǎn)品或者別的非技術(shù)人員，添加的數(shù)據(jù)往往也需要有自動部署的工具，而且因?yàn)橥ǔＫ麄儺a(chǎn)生的文件比較大，每次的全體打包然后覆蓋，可能會非常沒效率。雖然事情要做得完美不是很容易，但絕對是物有所值。
版本列車
我們時常只是對技術(shù)工作有版本管理的過程，而對于其他環(huán)節(jié)，常常停留在最原始的狀態(tài)。我們需要在整個項(xiàng)目開發(fā)的每個環(huán)節(jié)，都進(jìn)行合理的項(xiàng)目管理。在多個項(xiàng)目的經(jīng)驗(yàn)積累之后，提出了全過程的項(xiàng)目管理的概念：版本列車。
版本列車的含義是按照項(xiàng)目的工作流程，為每個有產(chǎn)出的環(huán)節(jié)都定義一個版本“車廂”，然后按照工作流程的先后依賴順序，形成一個完整的“版本列車”。第一個工作環(huán)節(jié)負(fù)責(zé)版本號，然后在這個版本號之下填充版本內(nèi)容。當(dāng)工作完成，此版本的工作內(nèi)容則帶著版本號進(jìn)入下一個“車廂”，依此類推。
這樣做的好處是，每個環(huán)節(jié)的每份產(chǎn)出都可以明確地知道其進(jìn)度位置，安排在什么時候做。對于需要提前準(zhǔn)備市場推廣或者別的工作部門，有一個非常明確的長期計劃。對于進(jìn)度管理來說，各個部門也能知道整個項(xiàng)目的當(dāng)前狀態(tài)。
論功行賞(績效評估)
不管是對被評的人，還是對評價別人的來說，績效評估都非常難做。因?yàn)楹芏喙ぷ鞑⒎悄芎軠?zhǔn)確地列舉出一二三來，工作任務(wù)也可能有大量臨時變更。太過主觀會讓人覺得草率;非要去依據(jù)可量化的數(shù)據(jù)，又過于死板和片面。但沒有一個公司敢不做考核，所以說績效評估是“明知山有虎，偏向虎山行”。
績效考核應(yīng)該重點(diǎn)關(guān)注的是做了什么事，而不是做得怎么樣。這個讓很多按“結(jié)果”管理的老板很不接受。績效考核應(yīng)該是推動別人去做某件事的工具。對于已經(jīng)明確的方法或者子目標(biāo)，通過這種細(xì)化的方式去指導(dǎo)下屬工作。因?yàn)槭切枰潞笏阗~的，而且是量化的，所以下屬會對這個事情很認(rèn)真，同時那些不好量化的事情，管理者也很難執(zhí)行績效考核。所以“去做某些事”，是績效考核最好的目標(biāo)。
通過考核結(jié)果提供正式的工作方法意見。績效考核本身有個反饋的過程，這個反饋的過程應(yīng)該提供給下屬針對每個具體事情的建議。這種具體地，單獨(dú)地，一對一地指導(dǎo)，會提高團(tuán)隊的穩(wěn)定性，而且也讓團(tuán)隊成員獲得“受關(guān)注”的感覺，這種感覺是形成高效團(tuán)隊的重要工具。
考核不能代替目標(biāo)，不能阻礙目標(biāo)，而應(yīng)該是一個溝通工具。目標(biāo)達(dá)成情況是考核的客觀指標(biāo)，但不應(yīng)該作為主要績效考核指標(biāo)。最簡單的績效考核指標(biāo)就是收入或者利潤率。但這種簡單指標(biāo)除了在動機(jī)上提高下屬的工作熱情外，并沒有從方法和經(jīng)驗(yàn)上幫助團(tuán)隊成員。有效的考核應(yīng)該是引導(dǎo)下屬按照更有經(jīng)驗(yàn)的方法去實(shí)現(xiàn)目標(biāo)。
想認(rèn)識全國各地的創(chuàng)業(yè)者、創(chuàng)業(yè)專家，快來加入“中國創(chuàng)業(yè)圈”
|
