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