如何提升程序員的生產率 (1)

版權聲明：本文由韓偉原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/251

來源：騰雲閣 https://www.qcloud.com/community

 

做者介紹：韓偉，1999年大學實習期加入初創期的網易，成爲第30號員工，8年間從程序員開始，歷任項目經理、產品總監。2007年後創業4年，開發過視頻直播社區，及多款頁遊產品。2011年後就任於騰訊遊戲研發部公共技術中心架構規劃組，專一於通用遊戲技術底層的研發。

一.硬件資源

辦公環境

大部分開發團隊都不把座椅傢俱視爲一個很是重要的問題。擁有寬敞的桌面的環境，能夠在桌上放置更多的東西：本子、筆、杯子、書本、打印的資料。更重要的是在和其餘人溝通的時候，咱們能夠一塊兒坐在同一個桌子前面，而沒必要去找個會議室。寬敞的桌面必定比窄小的桌面更有利於提升程序員的效率，並且費用一般不是想象中的高。

不知道你有沒經歷過整個開發團隊在一個會議室中作集中開發的時間，相信若是經歷過的人，都會對這段時間內的工做效率有深入印象。一個相對封閉的環境能隔絕外部的干擾；全部的溝通都是圍繞着工做目標，而不是微博上某個有趣的新聞，能加快團隊成員進入高專一狀態的速度；團隊成員之間能夠用語言和目光以及肢體來交流，節省了不少在IM軟件上打字的時間。若是讓我選擇設定一個軟件開發的辦公區，一個帶門的辦公室是首選，無論這個門能不能關上。在著名的《人件》中，對於辦公空間和安靜環境有詳細的論述。

對於項目開發中問題的溝通與討論，是讓程序員們脫離那種做爲「碼農」感受頗有用的一招。而掛在牆上的燃盡圖，或者是一疊完成了項目目標，以及一張正在開發的版本目標，又是一種無言的激勵。我建議在團隊都能方便看到的地方，最好是座位圈的中間，樹立一塊大大的看板：上面有空間來讓團隊成員不用把腦殼碰到一塊兒的在紙上討論；上面能夠標識出工做的進度，我打賭這會是項目經理的最愛；同時張貼這版本目標，如同一張張通緝令，而大多數是已經被「捉拿歸案」的。

最後一點，可能並非不少地方會碰到，可是卻很致命，就是「空調」。不少辦公樓在下班後會關閉中央空調，對於習慣於「過非本地時區」的程序員來講，簡直就是噩夢。我還記得曾經週末汗流浹背的趴在電腦前工做的煩躁感，要直到深夜，纔會稍微感受舒服些。必定要7x24的空調，不然辦公區機房也會出問題。

因此的這一切，可能對於開發進度的推進，並不是屬於「高科技」的行列，可是所謂成本也不高，就算抱着試一試的態度，也絕對值得實踐。黑網吧同樣的工做環境，並不表明艱苦奮鬥。

PC電腦

若是按程序員的工資，來算一算有多少時間是在等待工做電腦上作出的「響應」的話，一年以後，這些被浪費的金錢足夠再買十臺電腦。更重要的是，爲了打發等待電腦的時間，程序員們會跑去瀏覽網頁、聊天、吃東西……而專一的精力就這樣被消耗掉了。爲了恢復進入到專一的狀態，程序員須要10倍於剛纔浪費掉的時間。在這些神不守舍的時間內，若是還在寫代碼，更加是增長了留下大堆BUG的風險。買市場上最好的PC——對比你在項目延遲和BUG中消耗的金錢來講，簡直是九牛一毛。並且這些固定資產投資，自己也是公司的一部分，並非「白白消費掉」了的。購置牛逼的PC，看起來須要不少資金，可是這幾乎是最便宜的提高程序員開發效率的東西。

使用兩個以上的顯示器，能明顯減小使用者在窗口切換中的時間，更重要的是能快速恢復注意力。在開發過程當中，注意力每每須要集中在某一個窗口，而同時兼顧其餘窗口。而在諸多窗口中翻來翻去，是最容易分散注意力的事情。如今PC的集成顯卡每每有2個視頻端口輸出，若是還有多一個外置顯卡，則有4個端口。善加利用這些好的措施吧。固然也有一些人喜歡用一個比較巨大的顯示器，其實也是一樣的道理，他們會讓顯示器上同時顯示不一樣的內容。

防止木馬和病毒，特別是對非技術人員電腦的服務，是很是重要的工做，我不止一次的碰到過某些非技術崗位的電腦出現嚴重問題而影響整個開發進度。

網絡

幾乎在每家公司，我都能見到爬滿地面的網線，還有塵封在某個角落的8口交換機。「上網很慢」的呼聲經常從員工的口中聽到。等待網絡響應和等待電腦響應的意義是同樣的，都是在浪費公司的金錢。提供足夠的局域網帶寬和外網帶寬，是必需要作的事情。一個20人的開發團隊，應該在20M以上的互聯網帶寬環境下工做，局域網則毫無疑問的應該用能買到的最快的配置，如今已是千兆網了。並且應該配備優質的無線網絡，能有效下降網線爬滿辦公室地面的面積。

網絡的管理也是一個很是重要的部分，用技術手段限制每一個人的帶寬佔用是必要的，設置一個文件服務器專門存放那些被反覆下載的大型文件，如IDE，是一個很好的作法。IT標準化是一門很專業的學問，能在這個方面去努力，必定也是物有所值的。

服務器

若是一個銀行沒有本身的保險庫，而是把錢都放在各個職員腳下的小鐵皮盒子裏，這種狀況固然是匪夷所思的。可是不少公司的開發團隊，卻把開發的成果——代碼、圖片、文件放在每一個人的PC裏面，只在必要的時候才集合到一塊兒，而後放到老大的PC裏面。每一個團隊都應該有本身精心維護的「保險庫」，就是局域網中的服務器，應該有專人管理和維護這些服務器，而且設置自動備份和緊急恢復的機制。每一個開發人員都必需要有，「把完成的工做放到服務器上」纔算完成的觀念。我認可不少美術設計人員很不習慣，可是在承受過屢次文件丟失的教訓後，無論有多大的困難，都應該養成這個習慣。

總結

硬件是最直接顯示資金支出的東西，節省這些錢彷佛是爲公司着想，可是我以爲適當「揮霍」，也是一種對公司的負責。由於這些投入是最便宜的，能提升程序員開發效率——可謂世紀難題，的方法。

二.軟件工具

開發工具：

木匠們給我最深入的印象是，他們只要一開工，就馬上會搭起一張簡易的工做臺，雖然看起來很粗糙，可是堅固而平整。程序員是具備豐富電腦使用經驗的人員，可是並不是每一個人都意識到應該先給本身「搭個工做臺」。

1.文件系統
「這個文件到底在哪裏呢？」我相信每一個人都碰到過這個問題。所以有些人的桌面鋪滿了密密麻麻的圖標。節省找文件的時間，就是提升開發效率。對於WIN7來講，能夠自定義「庫」是個很好的功能。而TortoiseSVN也會自動創建「SVN庫」。爲你開發項目定義好一個「庫」，能大量節省翻文件的時間。把你天天都用的程序，固定到任務欄中，刪掉因此其餘的圖標，由於不少軟件都喜歡在你安裝它以後，就賴在任務欄上不走。

桌面是我最經常使用的「臨時」目錄，我甚至把下載目錄設置爲桌面。可是全部的臨時文件，一旦我決定不會常常打開，我就會絕不猶豫的刪掉，或者挪到別的目錄上。桌面上我更傾向去放那些我近期工做就要處理的文件，以及那些常常要打開的文件的快捷方式。這樣每次開機都會提醒我還有些什麼工做須要作。每隔一段時間我就會清理個人桌面，對於一些不多使用的快捷方式我會直接刪掉，而後把那些甚少打開的文件去歸類的放到文件目錄中去。你能夠看一眼個人桌面，就知道我平常的工做。
若是你經過命令行去使用LINUX這種系統，輸入長長的路徑，就算有TAB的自動補全，也是很是繁瑣的事情。創建一些軟鏈接(ln –s)，或者寫一些shell腳本，都能讓你從這些煩人的鍵盤敲打中解脫出來。

有另一些人會比較愛好使用搜索功能，並且如今WIN7的搜索也很好很強大。使用搜索也確實能快速找到你要的東西。可是我不認爲由於有這個功能，就應該把東西隨便亂丟，由於總有一天你須要歸類整理、備份這些文件。在沒有「關鍵詞」的狀況下，你只能依賴之前的目錄結構了。
也許精心安排文件路徑、放置快捷方式、設定軟鏈接和編寫只是節省了十來個敲鍵的簡單腳本，會被當作是小題大作。可是我確實在不一樣作法的程序員之間找到過明顯的效率差別。一個有趣的現象是，越是經驗少的程序員，他的桌面越顯混亂。

2.腳本
設置好你的PATH變量，這是第一步。
LINUX下大多數的程序，均可用管道串接組合起來實現一個更復雜的功能。這給與了使用者機器豐富的靈活些，來創造本身的工具。這些計算機界的先知們創造了這套機制，若是咱們不去享用，實在是罪過。我會把經常使用登陸命令變成一個腳本，減小去敲彆扭的IP地址；我會把登陸數據庫的命令也寫成一個腳本，這樣不用去記憶複雜的參數；我還會去把同步文件的命令作成腳本……把全部經常使用的，超過5個字的命令都變成腳本，就算這個腳本只有短短的一行或幾行，都會大大下降工做強度。雖然GUI看起來漂亮，很吸引人，可是手指能夠不碰鼠標，而一直在鍵盤上工做會高效許多。
WINDOWS下的BAT也是腳本，可是並很差用，由於WINDOWS自己是GUI類型的。可是不妨礙使用宏這種工具。
儘可能多的編寫一些本身用的腳本，你會發現很容易記住而且依賴他們。

3.IDE
到底程序員是否須要IDE，這個問題其實很值得商討。我曾經直接用EditPlus來寫過數千行PHP代碼。也曾直接用VI來作JAVA的開發工具。這些編輯器打開的速度能使我快速的投入到工做中去。而Eclipse和VC這種慢吞吞的IDE，卻浪費了我大量的時間和注意力。我更傾向於在項目初期的研究階段，儘可能少用IDE去寫代碼。而在全部的技術風險都解決以後，再啓動IDE做爲正式項目的開發工具。

IDE對比普通的文本編輯器來講，效率提升的實際上是各類快捷鍵。若是你用Eclipse，必定要懂得用Ctrl+Shift+r來打開文件，也必定要懂得用Ctrl+o來定位代碼，按着Ctrl來點擊代碼，以及使用Atl+/都是很好用的快捷鍵，有了這些功能，我不再會擔憂由於拼寫錯誤形成的BUG，並且變量方法的名字長一點也不是問題，由於電腦會幫我自動輸入。而多重剪貼板也幾乎是必備的工具。另外，IDE一般都有帶一些自動機制，如存盤就自動編譯，可讓你快速修正編譯錯誤，提升開發速度。還有如Aptana寫PHP和JS，能夠自動上傳到服務器。這些都是很實用的功能。

斷點單步調試也是IDE一個很是重要的功能，有不少程序員歷來沒有用過斷點調試這個功能，由於根本就沒在開發PC上搭建過運行環境。這個是必定要花功夫去弄好的，不然反覆在測試環境上修改代碼、增長日誌、嘗試運行的繁瑣步驟會把人逼瘋。
有些IDE還能夠把SVN結合起來，那就更方便了，絕對是值得推薦的用法。還有的IDE能夠和單元測試組件結合。每次編譯都自動運行單元測試，這個也是很值得推廣的實踐。

最後說說一個很重要的問題，就是開發團隊中，最好全部人都用一樣一個版本的IDE，而後共享全部的配置設定，這些配置設定最好直接做爲源代碼的一部分放到SVN上管理。如我喜歡把Eclipse的整個workspace放到SVN路徑上，這樣全部項目的.project文件均可以一塊兒管理，我若是有一天硬盤掛了，我能夠直接從SVN上checkout整個workspace，瞬間重建個人工做環境。不管什麼時候，不管在誰的機器上，都能輕易重建開發環境，對於團隊合做解決問題有很是重要的意義。這種作法也能推廣IDE的一些使用技巧。雖然程序員喜歡彰顯個性，可是對於取消一點個性而帶來的好處來看，是絕對值得的！——我一直對於設定一個「養眼」的底色有強烈的愛好，這個簡單的設定也常得不少同事的支持，用這種方法可讓全部人的得到這個好處。

4.Notepad
一個好用的文本編輯器，是程序員的瑞士軍刀，用來處理一切臨時的、複雜繁瑣的工做。每一個程序員都應該有一個優秀的文本編輯器，它要有飛快的打開速度，能夠同時打開多個文件，有優秀的查找替換功能，對於XML\SQL和大多數的腳本、編程語言都有語法上色功能，並且能夠存成不一樣編碼的文本。我認爲LINUX上的VI是最好的，如今WINDOWS上也有了。另外古老的UltraEdit能夠編輯二進制內容，EditPlus擁有很好的語法上色，Notepad++各方面都挺不錯，並且是免費的。這些都是值得考慮的。特別是文本內碼轉換功能，LIUNX和DOS的換行，都是很經常使用的需求。（在LINUX上有方便的dos2unix/unix2dos和iconv）

除了安裝一個這種軟件，還須要把全部可能編輯的文件類型的默認打開程序都設置成它。這個設置工做會大大減輕往後工做中的操做負擔！我甚至建議公司的IT人員應該對程序員的PC作標準安裝的時候，就設置好這個功能。

5.Excel
數據表格是程序員接觸到的主要業務數據格式，大部分非技術人員都會把「數據」類型的文件用excel來存儲。而Excel強大的篩選、統計圖功能也是程序員樂意輸出給其餘工種同事的緣由。所以程序員的PC上的OFFICE套件至少應該有一個Excel，或者免費版本的替代品如WPS或者OpenOffice.org。

並且程序員須要掌握直接用API來生成和解析EXCEL的技能，這個技能會讓跨工種溝通節省不少時間。特別是節省各類由於「格式錯誤」致使的問題。我就曾碰到過一個XML數據文件由於一個小小的語法問題，困住產品人員一成天的事情。若是你確實不想用微軟的這種封閉技術，那麼用更建議的CSV格式也是很好的，由於你一樣能夠用excel來打開，只是不能擁有合併單元格、字體、顏色這些外觀性功能。

6.Visio
程序員大部分的圖應該用筆畫在紙上，或者白板上。可是更重要的是，程序員應該多畫圖來記錄本身的思路。這種思路最後的定稿，最好是以電子文檔來記錄。我使用過數款畫圖軟件，如Dia，OpenOffice.org，甚至是WINDOWS的畫筆，Flash CS，可是最好用的仍是微軟的VISIO，特別是畫UML圖。雖然這個軟件價值不菲，但絕對值得使用。千行文字不如一個圖來的清楚。很遺憾我還沒找到開源的或者免費的軟件能媲美VISIO的。

7.MindMenager
思惟導圖軟件出現的時間並不長。這種軟件強迫你按樹狀來梳理你的思路。對於有條理性自覺的人，其實這個工具的意義不是太大，只是一個快速畫「樹」的軟件。可是若是對於問題思考還未能頗有條理的時候，這種軟件確實能幫助人理清思路。一般這種導圖文件並不能成爲真正的文檔產出物，更更像是一種草稿。可是仍是建議程序員嘗試使用它。除了收費的MindMenager之外，有多款開源的思惟導圖軟件可選，功能都不錯。爲了文件格式的兼容，團隊內應該肯定用其中一個。開源的FreeMind是個不錯的選擇

8.開發服務器

• 使用程序員的PC
  彷佛服務器程序開發都有一個傳統，就是使用專用的開發服務器，而後由程序員的PC上傳而且遠程控制這個服務器，來作開發和調試。可是在我開發JAVA服務的實踐中，讓客戶端直接鏈接到本身的PC上，利用IDE的調試器，確是能大大提升聯調的速度。根據很粗略的估計，使用直連PC聯調會比基於服務器聯調節省最少70%的時間。由於漫長的看日誌（或者是使用GDB，有不少初級程序員都不太能熟練的使用命令行的調試工具）、改代碼、上傳、編譯、而後召喚客戶端程序員從新發起請求……這些事情佔了不少時間和寶貴的注意力。若是客戶端和服務端都以IDE方式運行在同一個PC上，你能夠兩邊都作斷點單步調試，一切問題都變得異常簡單。
  得益於JAVA的跨平臺特性，在程序員PC上調試過的程序，幾乎不會在真正的服務器上有太多的BUG。實際上如PHP、PYTHON這些腳本語言，也是能作到相似的效果。而不少C++程序員也習慣用宏定義來讓LINUX上的程序在VC上編譯調試。可是始終不如JAVA那麼方便。
  在性能調整的工做中，若是讓壓測實際運行在程序員PC上，能夠調用不少漂亮的GUI性能分析工具，如JConsol。這也能性能改進工做有個很好的環境。
  儘可能在程序員的PC上搭建完整的開發調試環境，少依賴複雜的「開發服務器」環境，會讓開發速度有很大的提高。

• 使用虛擬機
  如今的PC性能廣泛很高，並且還有專門爲了支持虛擬機的硬件支持，從性能上來看，是支持大量使用虛擬機的可能性的。
  在WINDOWS上開發LINUX程序，若是用虛擬機裝一個LINUX，而後以GNOME界面的IDE開發，會是一種很便利的工具。由於和服務器一樣是LINUX，因此大部分的程序開發以後能夠直接放到服務器上運行，都不會有什麼不一樣。並且LINUX自己有不少好用的功能，如利用SSHD的遠程文件夾，能夠更好的和別的LINUX服務器作互動操做。同時一些WINDOWS的程序也能夠在虛擬機之外來運行。特別是如今還支持剪貼板和文件分區共享，用起來就更方便了。
  做爲開發服務器，實際上負載一般很低，因此在一個物理服務器上安裝多套虛擬機，可讓每一個項目都有本身完整的一套環境，是節省成本和管理費用的好方法。甚至不少工具服務器均可以是虛擬機，除了SVN。

• 文件同步技巧
  多個機器之間的文件同步，是很常見的一種需求。通常LINUX服務器採用sshd和scp功能來拷貝文件，這個命令行工具使用起來比較方便，缺點是必需要手工輸入密碼。做爲腳本就比較麻煩。因此通常有兩種方案，一種是用expect這個 shell來寫腳本，模擬輸入密碼。另一個就是使用rsync，這個軟件能夠對sshd服務器直接去同步文件，也是很方便的。能夠用推或者拉兩種不一樣的方案，更重要的是rsync能夠指定密碼文件，成爲腳本的好幫手。
  另一個就是用samba，直接從WINDOWS的共享目錄功能去拷貝文件，雖然也算好用，可是寫bat去運行總以爲不夠強大。也有用SVN來傳遞文件的，可是這並不符合SVN的「提交」含義，是一種很差的作法。最後還有一些經過裝一個WEB服務器，而後從另一邊用wget來下載，這種對於定時自動運行的程序來講不失爲一種方案，可是缺點是不夠靈活，只能限定是下載，並且限定了路徑。
  總結來講，rsync和httpd+wget是畢竟好的同步文件方法。

• 反思必要性
  如同本節第一點所說，不少時候在程序員本身的PC上處理開發工做，是效率最高的，因此是否必定要有「開發服務器」是一個值得思考的問題。在具體的實踐中，那些開發工做一般在PC上完成的團隊，其「開發服務器」每每是一個測試服務器，用來對最終聯通，展現臨時效果，內部QA之用。反而真正不多人在上面調試。可能取消「開發服務器」是最好的，可是這個須要更多的實踐來證實。

9.構建服務環境

• 構建腳本
  對於C/C++類項目來講，構建是一門至關複雜的工做；而JAVA項目則相對簡單一些，只是須要一些打包的腳本，用ANT徹底能夠搞定。無論如何，一個能夠自動從SVN上下載資源，而後在一個空白環境下生成「可安裝包」的腳本，是絕對必要的。並且應該是能全自動處理，天天都自動編譯一個安裝包出來。這個是如今最流行的所謂「持續集成」的基礎。
  這裏面還有一個小技巧就是關於「版本號」，通常來講構建腳本應該支持以命令行參數方式輸入版本號的功能。而版本號則應該能在構建過程當中，編譯到項目代碼中去，這樣在運行這些代碼的時候，就能夠編寫一些輸出「版本號」的語句，以便在測試過程當中肯定軟件的版本。C/C++項目能夠用環境變量配合宏定義來處理。JAVA和其餘一些項目，則須要寫一個version文件。

• 構建服務器
  構建服務器必須是單獨的，空白的環境，建議使用虛擬機。構建服務器自己應該和目標部署服務器的系統採用儘量一致，特別是對於C/C++項目來講，內核版本，64仍是32位的系統，都相當重要。若是編譯過程須要一些額外的庫和工具，首選從SVN上下載，做爲項目的一部分，若是實在沒法作到，則須要有清晰的「服務器構建軟件環境」的本身的安裝包SVN和安裝配置說明文檔（一樣放在SVN上）。我建議構建服務器、測試服務器、開發服務器、運營服務器都基於同一個系統環境的設定去安裝。如都安裝一樣版本的GCC或者JDK，安裝一樣版本的PYTHON和apache等等。

10.測試服務器（內測）
安排一臺服務器放在局域網，隨時在上面部署最新的代碼，是一個頗有必要的佈置。由於產品、美術或者其餘一些非技術人員，可能須要依賴最新的代碼對產品進行另一種「開發」——添加數據內容。有一個不受程序員頻繁修改調試的服務器，對於他們的工做效率是頗有益處的。一樣程序員也不用受制於別的工種進行開發。

爲了利用好測試服務器的功能，有一個很是重要的工做，就是讓代碼可以自動的部署到測試服務器上。若是仍是由程序員去部署，這個額外的體力勞動會消耗沒必要要的程序員的時間。而編寫自動部署的腳本和預先設定環境，雖然一開始會消耗很多時間，可是這些自動部署的工具，一樣能夠用於別的測試環境甚至是正式運營網絡上的服務器，是一個一舉兩得的好事情。
對於美術、產品或者別的非技術人員，添加的數據每每也須要有自動部署的工具，並且由於一般他們產生的文件比較大，每次的全體打包而後覆蓋，可能會很是沒效率。好比美術資源一共有10G，可是你只須要更新其中的2M的文件。這個時候就要設計好「增量」部署的腳本，或者你能夠當作是「補丁」型部署包。用rsync能夠只拷貝有變動的文件，而tar也能夠指定打包的文件，或者寫一個精巧的Python程序來處理，也能夠嘗試用make和ANT工具來實現。雖然這個事情不是太容易作的完美，可是絕對是物有所值。

11.體驗網環境（外測） 
不少時候，網絡環境會暴露出不少意想不到的問題，如網速變慢，有些交互會變得奇怪。在不一樣的服務器上，部署和配置可能會出現錯誤。並且對於測試人員來講，一個和真實運營環境高度類似的測試環境是很是重要的。最好還能讓不一樣的測試人員從各類不一樣的接入網絡（客戶端網絡）來測試。所以一個具備相似於正式運營網絡的環境，顯得尤爲有價值。

對於發佈和部署來講，也是一個真實考驗自動部署和發佈工具的最好測試環境。體驗網的環境，實際上應該拒絕開發人員直接訪問，而真正的給運維人員一個實戰的環境，看是否有一些遺漏的問題。只有通過了體驗網的測試，產品才真正能部署到外網運營環境中。

一個隔絕開發人員的體驗網環境，除了能提供更實際的測試條件外，還能提供很好的管理區域分界：開發和運營。經過這個環境，能區分出哪些問題是開發引入的，哪些是運維引入的。
有些有條件的團隊還能夠要求一些外界的人士參與對體驗網上產品的測試，這樣更加能提升測試的細緻程度。不過能提供這種支持資源的公司並很少，由於用戶也是須要資源去換取才會來測試的。若是有必定用戶來，還能夠錄製他們的測試行爲，而後爲壓力測試提供原始數據。

12.壓測環境 
壓力測試是一種比較講究技術的開發工做。除了本身模擬一些狀況外，錄製用戶的行爲而後按登陸會話併發請求，是一個很使用的壓力測試策略。爲了不壓力測試佔用開發網絡和服務器太多的資源。通常會專門配置發起壓力和承受壓力的服務器，而後讓他們接到獨自的一個交換機上。

13.單元測試工具
單元測試的概念是最原始的工程概念之一。早在單元測試工具出現以前，就有人提倡爲每一個類都寫一個main()函數，裏面專門放一些本身編寫的測試代碼。現代的xUint工具已經普及多重語言，如JUnit, CPPUnit, ASUnit等等。不斷追求自動化和邊界的測試工具，應該是每一個程序員的目標。完善的測試能解放程序員的巨大心理壓力——改了不少代碼後，會不會有BUG？用程序來自動檢查，是最好不過的了。實際上現代編譯器都提供不少規則，這些規則也是一種靜態檢查，好的代碼能經過靜態檢查後，大大減小BUG。單元測試則相似於這種檢查，可是是動態的，因此須要程序員本身用測試代碼去定義「規則」。在編寫準備去單元測試的代碼的時候，會讓這些代碼變得結構更良好，由於第一個使用這些代碼的客戶程序員就是本身。

單元測試對於互聯網應用來講，通常會有一個困難，就是須要大量的「腳手架」，好比爲了測試數據庫操做，必需要有一段代碼「重置」數據庫的狀態；爲了測試網絡打包解包，則須要用一個程序向某個網絡端口發數據。準備這些測試工具代碼的時間，每每會比較長，須要有足夠的耐心去作，可是一旦作好了，每每能讓開發風險大大下降。

合做工具：

有一門專門的知識叫：軟件配置管理。其實講的大多數就是如何利用合做工具來提升開發效率的。通常來講，編譯型語言的軟件配置管理會比較複雜，而解釋性語言的軟件配置管理則簡單的多。我認爲合做之中溝通、交換是2個主要主題。溝通方面面談是最有效的手段，而交換則應該多利用工具。

1. SVN 
SVN是優秀而免費的版本管理工具。採用檢出-提交-合併的模式處理文件，同事對於創建分支成本極低。因此應該合做工具中最重要的部分。

SVN的使用書籍汗牛充棟，我認爲最須要關注的2點：一是對於非文本文件的控制，由於SVN不會自動合併，因此應該多用「鎖」的功能，來提醒別的用戶不要覆蓋了本身的修改。二是善用分支的功能，標準的作法有trunk/branch/tag的這種分支方案。
服務端由於部署成本比較低，因此傾向於直接在trunk上開發，有遠期或者可能衝突的目標纔開branch，而測試也直接在trunk上作測試。客戶端由於部署成本高，通常不肯意代碼和資源在開發工程中打包發佈和測試，因此傾向開一個dev-branch專門用於開發，而trunk專門用於發佈測速。我我的的經驗是，若是程序結構足夠良好，能在trunk上作到直接開發發佈是最好的，由於合併操做畢竟是多一個步驟。而要作到這一點，就必須對功能按模塊修改作到很好，特別是客戶端代碼，由於涉及發佈包的大小問題，要作到還沒開發完的模塊就不打包生成安裝包，是須要必定的設計的。而關於branch，個人見解是應該根據功能點來生成，不少時候你們喜歡根據版本目標來作branch，可是根據經驗，版本延期和版本內容修改常常發生，這個時候就被迫作一些分支合併和提早都是很麻煩的事情。SVN新建分支異常低成本，因此tag分支能夠多作一些，每日一個雖然誇張了點，可是每週一個確定是問題不大的。對於測試人員來講，能有一個固定版本的源代碼來作測試，會減小不少沒必要要的BUG的檢測。

下面說說SVN不該該有的用法：第一個是拿SVN當文件傳輸工具，這樣會讓版本庫中帶有大量的無用的日誌，並且SVN並不是一個專用的文件同步工具，會產生一些額外的問題，好比生成大量佔用空間的.svn目錄。另外每次提交都應該具有自我包含的一個功能特性，不然對於作基線或者作分支會很混亂；第二個是SVN中存放目錄結構常常會變化的文件，有些如日誌文件，由於會不斷生成目錄，因此會致使.svn目錄變多，最後搞得很混亂。

SVN除了基本的功能，還有不少可擴展的功能，也是很優秀的。如你能夠在提交的註釋中按照某些規則來寫文字，觸發別的工具。如JIRA就能夠設定在註釋中寫「#bug-id」來自動更新對應bug的狀態。SVN由於擁有很好用的觸發器，因此作這些自動化功能垂手可得。若是針對代碼提交有一些管理工做，強烈建議整合到SVN的工具裏面去，如BUG的跟蹤、工做量統計、通知同組同事修改內容等等。

2. wiki/知識庫/IntraBBS
寫程序的同時會有大量的文檔，如何管理這些文檔，是一個重要課題。我認爲文檔主要分爲幾類：1、API使用手冊；2、架構設計文檔；3、經驗知識的積累。

關於「API使用手冊」這類文檔，有javadoc這類直接嵌入在源代碼中的文檔規範，而後有自然工具能夠自動導出。我認爲這類文檔在自動構建的時候同時自動輸出，而後跟隨發佈包發佈是最好的。使用者能夠跟隨同版本軟件一塊兒獲取。

關於「架構設計文檔」這類，最大的問題是版本更新，由於每每進入開發期以後就少有人再去更新，致使後來須要用的時候，已經有大量不一樣，而這個時候每每是有人離職須要交接的緊要關頭。這類文檔從開發角度，放在SVN仍是放到內部WIKI上其實都是好的，可是關鍵是怎樣維護。我的意見若是團隊較小，直接用SVN便可。若是團隊成員超過50人，文檔能夠由多我的一塊兒去寫，放到WIKI上能彰顯你們的努力，也方便你們查閱。
內部BBS不少時候最後變成灌水聖地，對於開發效率的推進其實不大，不過做爲一個「軟福利」，有些時候也有一點用，整體來講我不太承認這種東西的價值。

3. IM(QQ,RTX...)/E-MAIL座機/sms 
關掉IM！關掉E-MAIL！電腦上的即時通信工具被某些人認爲是「必備」的工具，而我則認爲郵件才真正是工做用的工具。考慮到程序員的注意力很容易被這些忽然闖入的信息所幹擾，我更傾向於直接關掉IM軟件。電子郵件也只在固定時候收取，如中午和下班前。不少人對IM和郵件反應很快，不少時候是由於他們根本沒在認真幹活，或者工做並不飽和。座機和短信是通常辦公的必備工具，座機能夠省了跑來跑去的溝通，但我認爲當面溝通仍是比座機要好。我理想的辦公室應該是通道寬敞，每4-6個座位中間均可以有個小型討論區，有白班和多於的幾把椅子和一張小桌子。

短信我認爲仍是很好用的一種工具，特別是某些須要記住的信息，好比日程提醒、電話號碼、或者一些IP地址之類的東西。用來做爲天天的業績提醒，發給團隊中全部人，也是很好的。另外用來做爲自動報警消息，是保證不在IM和郵件叨擾的狀況下最關鍵的實時通知工具。設置一個企業本身的短信網關，是頗有必要也頗有價值的。

4. 公共文件服務器 
公共文件服務器能夠是WINDOWS也能夠是LINUX+SAMBA。我認爲這個服務器是SVN的一種補充。主要用來存放兩種文件：1）開發工具和各類服務器軟件。這些軟件應該是標準化環境的一部分，因此應該共享使用。2）每日構建的發佈包以及各類版本的發佈包。發佈包自己在測試工做中是最基本的需求，因此應該有一個集中的地方存放。我建議同時這個服務器也具有HTTP下載功能，這樣不少LINUX腳本也能夠自動去抓數據了。

5. 持續集成服務hudson 
持續集成是現代軟件開發的重要目標。若是沒有自動化的持續集成工具，軟件的開發和測試將會效率很是低下。Hudson是一個很好的持續集成工具，能夠直接從SVN下載代碼，執行腳本而後運行。自己是JAVA的程序能夠同時處理WINDOWS和LINUX上的構建。

持續集成的基礎是SVN版本管理的標準化；而後是擁有自動化的構建腳本；最後是擁有自動的打包和部署腳本。持續集成系統只是把這些工做串起來的一個工具。

無論持續集成是多麼的繁瑣的工做，可是這些必定會物有所值。

6. 開發者微博
有些開發方微博其實是市場宣傳軟文，我暫時不討論這個。有一種實踐是把SVN的註釋自動提交到WIKI上，而後你們用RSS訂閱。其實這個就是一種SVN的註釋自動生成的微博。這種方法用來自動溝通代碼修改，實際上是很自動化和看起來可行的。實際上大部分人都只關係一部分代碼，只有管理者會比較關心大部份內容。因此用發送電子郵件可能比上微博要好。也有一些關閉了IM軟件的團隊用內部微博來公佈廣播消息，也比較受歡迎。不過我我的不同意爲了這單需求去搭個內部微博，仍是自動郵件好了。

7. 遠程桌面服務器、跳板機
不少時候爲了提供團隊成員能夠在辦公室外環境工做，都須要架設一個「跳板機「供直接遠程桌面到本身的辦公機上幹活。我認可這個作法確實能解決一些臨時事故修理的問題，可是實際上安全隱患很大，若是跳板機被攻破，整個公司的代碼可能就被拷貝走！

架設遠程桌面服務器、跳板機，必定要作到很是高的安全級別，起碼都要不被網絡上掃描掉。不然就不如不作。

管理工具：

1. 缺陷跟蹤管理工具JIRA 
其實這種工具也算一種溝通工具，有時候能夠代替Project這類軟件，聽說互聯網上不少開源項目都是用JIRA來作特性和缺陷管理。使用這類工具管理者比開發人員要積極，由於這個工具更多的是「任務分派」和「任務統計」的功能。而開發人員則須要不停的去查看本身的任務，而後作完以後還要手動上去提交或者寫意見。寫註釋這種事情有時候是比較蛋疼的，極可能沒有人會看，緣由是寫註釋的人不多寫的很清楚。因此使用這種工具，我認爲最重要的是要作好自動化插件，如SVN直接用註釋驅動JIRA去改進任務。

若是你同時在使用EXCEL或者PROJECT和JIRA同時來管理工做進度，這裏就會有一個很大的風險：JIRA上的問題和缺陷會難以歸入到你的工做整體任務列表中，由於這些缺陷可能測試人員在不斷的添加。

使用缺陷管理工具的最好實踐是，所有任務都用這個系統來管理；若是不能的話，就不要把BUG之外的任務歸入這個系統；若是仍是不能的話，就要作好人工的「分級」制度，或者爲每一個任務都嚴格加上一個「版本」的屬性，用來劃分出哪些是應該在如今就要完成。

2. 項目進度管理工具Project(Server)/ProjectManager.com 
Project是個好軟件，可是我一次都沒能成功安裝好Project Server，太悲劇了。ProjectManager.com就是一個不錯的項目進度管理工具，是徹底基於WEB的，惋惜是收費並且全英文的。Project的主要功能我認爲有2個，一個是關於資源的自動計算，一個是自動勾畫的甘特圖。可是軟件開發每每小任務、突發任務不少，碰到的延期和別的亂七八糟的事也多，因此嚴格描述開發流程，是一個很是困難的任務，就算你用Project也是同樣。因此通常來講Project適合描述一些比較大粒度的計劃，若是資源細到人，項目細到模塊，這個Project文件將會是維護的無底洞。

少花些時間在Project表的制訂上，而多一些花時間來經過面談和測試來掌握進度。

3. 版本任務列表/牆
如今流行的敏捷開發，都有提到「項目儀表板」「任務牆」這些東東。而後天天早上開會你們來彙報一下任務的進度狀況。對於這種實踐，我以爲沒有什麼突出的好處，也沒有什麼突出的壞處。

可是把版本任務都放到牆上，自己能提供必定的激勵做用，這個作法自己也是逼迫管理者必定要明確版本目標，篩選需求。與其說是給開發成員看的，不如說是給管理人員的限制。所以這種東東，仍是頗有必要的。

總結

本節列舉了大量軟件開發的「軟件工具」，可是確定還會有更多的軟件工具出現，我認爲使用某個工具，在某個工具投入精力和資源，是應該有明確的辨識原則的：這個工具，必定要能節省程序員的注意力，而不必定是節省時間或者現金開支。所以可以減小非編碼和寫文檔的操做，能自動化就自動化，就算爲了這個事須要耽誤一些開發時間，最後也是很補回來的。而有一些工具，看起來很帥，可是須要分散程序員的注意力去搞，就是不值得使用的。