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