大部分開發團隊都不把座椅家具視為一個非常重要的問題。擁有寬敞的桌面的環境，可以在桌上放置更多的東西：本子、筆、杯子、書本、列印的資料。更重要的是在和其他人溝通的時候，我們可以一起坐在同一個桌子前面，而不必去找個會議室。寬敞的桌面一定比窄小的桌面更有利於提高程式設計師的效率，而且費用通常不是想像中的高。
不知道你有沒經歷過整個開發團隊在一個會議室中做集中開發的時間，相信如果經歷過的人，都會對這段時間內的工作效率有深刻印象。一個相對封閉的環境能隔絕外部的幹擾；所有的溝通都是圍繞著工作目標，而不是微博上某個有趣的新聞，能加快團隊成員進入高專注狀態的速度；團隊成員之間可以用語言和目光以及肢體來交流，節省了很多在IM軟體上打字的時間。如果讓我選擇設定一個軟體開發的辦公區，一個帶門的辦公室是首選，不管這個門能不能關上。在著名的《人件》中，對於辦公空間和安靜環境有詳細的論述。
對於項目開發中問題的溝通與討論，是讓程式設計師們脫離那種作為「碼農」感覺很有用的一招。而掛在牆上的燃盡圖，或者是一疊完成了項目目標，以及一張正在開發的版本目標，又是一種無言的激勵。我建議在團隊都能方便看到的地方，最好是座位圈的中間，樹立一塊大大的看板：上面有空間來讓團隊成員不用把腦袋碰到一起的在紙上討論；上面可以標識出工作的進度，我打賭這會是項目經理的最愛；同時張貼這版本目標，如同一張張通緝令，而大多數是已經被「捉拿歸案」的。
最後一點，可能並不是很多地方會碰到，但是卻很致命，就是「空調」。很多辦公樓在下班後會關閉中央空調，對於習慣於「過非本地時區」的程式設計師來說，簡直就是噩夢。我還記得曾經周末汗流浹背的趴在電腦前工作的煩躁感，要直到深夜，才會稍微感覺舒服些。一定要7x24的空調，否則辦公區機房也會出問題。
所以的這一切，可能對於開發進度的推動，並非屬於「高科技」的行列，但是所謂成本也不高，就算抱著試一試的態度，也絕對值得實踐。黑網吧一樣的工作環境，並不代表艱苦奮鬥。
2）PC電腦
如果按程式設計師的工資，來算一算有多少時間是在等待工作電腦上做出的「響應」的話，一年之後，這些被浪費的金錢足夠再買十臺電腦。更重要的是，為了打發等待電腦的時間，程式設計師們會跑去瀏覽網頁、聊天、吃東西……而專注的精力就這樣被消耗掉了。為了恢復進入到專注的狀態，程式設計師需要10倍於剛才浪費掉的時間。在這些神不守舍的時間內，如果還在寫代碼，更加是增加了留下大堆BUG的風險。買市場上最好的PC——對比你在項目延遲和BUG中消耗的金錢來說，簡直是九牛一毛。而且這些固定資產投資，本身也是公司的一部分，並不是「白白消費掉」了的。購置牛逼的PC，看起來需要很多資金，但是這幾乎是最便宜的提升程式設計師開發效率的東西。
使用兩個以上的顯示器，能明顯減少使用者在窗口切換中的時間，更重要的是能快速恢復注意力。在開發過程中，注意力往往需要集中在某一個窗口，而同時兼顧其他窗口。而在諸多窗口中翻來翻去，是最容易分散注意力的事情。現在PC的集成顯卡往往有2個視頻埠輸出，如果還有多一個外置顯卡，則有4個埠。善加利用這些好的措施吧。當然也有一些人喜歡用一個比較巨大的顯示器，其實也是同樣的道理，他們會讓顯示器上同時顯示不同的內容。
防止木馬和病毒，特別是對非技術人員電腦的服務，是非常重要的工作，我不止一次的碰到過某些非技術崗位的電腦出現嚴重問題而影響整個開發進度。
3）網絡
幾乎在每家公司，我都能見到爬滿地面的網線，還有塵封在某個角落的8口交換機。「上網很慢」的呼聲常常從員工的口中聽到。等待網絡響應和等待電腦響應的意義是一樣的，都是在浪費公司的金錢。提供足夠的區域網帶寬和外網帶寬，是必須要做的事情。一個20人的開發團隊，應該在20M以上的網際網路帶寬環境下工作，區域網則毫無疑問的應該用能買到的最快的配置，現在已經是千兆網了。而且應該配備優質的無線網絡，能有效降低網線爬滿辦公室地面的面積。
網絡的管理也是一個非常重要的部分，用技術手段限制每個人的帶寬佔用是必要的，設置一個文件伺服器專門存放那些被反覆下載的大型文件，如IDE，是一個很好的做法。IT標準化是一門很專業的學問，能在這個方面去努力，一定也是物有所值的。
4）伺服器
如果一個銀行沒有自己的保險庫，而是把錢都放在各個職員腳下的小鐵皮盒子裡，這種情況當然是匪夷所思的。但是很多公司的開發團隊，卻把開發的成果——代碼、圖片、文件放在每個人的PC裡面，只在必要的時候才集合到一起，然後放到老大的PC裡面。每個團隊都應該有自己精心維護的「保險庫」，就是區域網中的伺服器，應該有專人管理和維護這些伺服器，並且設置自動備份和緊急恢復的機制。每個開發人員都必須要有，「把完成的工作放到伺服器上」才算完成的觀念。我承認很多美術設計人員很不習慣，但是在承受過多次文件丟失的教訓後，不管有多大的困難，都應該養成這個習慣。
5）總結：
硬體是最直接顯示資金支出的東西，節省這些錢似乎是為公司著想，但是我覺得適當「揮霍」，也是一種對公司的負責。因為這些投入是最便宜的，能提高程式設計師開發效率——可謂世紀難題的方法。
二、軟體工具1）開發工具：
木匠們給我最深刻的印象是，他們只要一開工，就立刻會搭起一張簡易的工作檯，雖然看起來很粗糙，但是堅固而平整。程式設計師是具有豐富電腦使用經驗的人員，但是並非每個人都意識到應該先給自己「搭個工作檯」。
1.1 文件系統
「這個文件到底在哪裡呢？」我相信每個人都碰到過這個問題。因此有些人的桌面鋪滿了密密麻麻的圖標。節省找文件的時間，就是提高開發效率。對於WIN7來說，可以自定義「庫」是個很好的功能。而TortoiseSVN也會自動建立「SVN庫」。為你開發項目定義好一個「庫」，能大量節省翻文件的時間。把你每天都用的程序，固定到任務欄中，刪掉所以其他的圖標，因為很多軟體都喜歡在你安裝它之後，就賴在任務欄上不走。
桌面是我最常用的「臨時」目錄，我甚至把下載目錄設置為桌面。但是所有的臨時文件，一旦我決定不會經常打開，我就會毫不猶豫的刪掉，或者挪到別的目錄上。桌面上我更傾向去放那些我近期工作就要處理的文件，以及那些經常要打開的文件的快捷方式。這樣每次開機都會提醒我還有些什麼工作需要做。每隔一段時間我就會清理我的桌面，對於一些很少使用的快捷方式我會直接刪掉，然後把那些甚少打開的文件去歸類的放到文件目錄中去。你可以看一眼我的桌面，就知道我日常的工作。
如果你通過命令行去使用LINUX這種系統，輸入長長的路徑，就算有TAB的自動補全，也是非常繁瑣的事情。建立一些軟連接(ln –s)，或者寫一些shell腳本，都能讓你從這些煩人的鍵盤敲打中解脫出來。
有另外一些人會比較愛好使用搜索功能，而且現在WIN7的搜索也很好很強大。使用搜索也確實能快速找到你要的東西。但是我不認為因為有這個功能，就應該把東西隨便亂丟，因為總有一天你需要歸類整理、備份這些文件。在沒有「關鍵詞」的情況下，你只能依賴以前的目錄結構了。
也許精心安排文件路徑、放置快捷方式、設定軟連接和編寫只是節省了十來個敲鍵的簡單腳本，會被看成是小題大做。但是我確實在不同做法的程式設計師之間找到過明顯的效率差異。一個有趣的現象是，越是經驗少的程式設計師，他的桌面越顯混亂。
1.2 腳本
設置好你的PATH變量，這是第一步。
LINUX下大多數的程序，都可用管道串接組合起來實現一個更複雜的功能。這給與了使用者機器豐富的靈活些，來創造自己的工具。這些計算機界的先知們創造了這套機制，如果我們不去享用，實在是罪過。我會把常用登錄命令變成一個腳本，減少去敲彆扭的IP位址；我會把登錄資料庫的命令也寫成一個腳本，這樣不用去記憶複雜的參數；我還會去把同步文件的命令做成腳本……把所有常用的，超過5個字的命令都變成腳本，就算這個腳本只有短短的一行或幾行，都會大大降低工作強度。雖然GUI看起來漂亮，很吸引人，但是手指可以不碰滑鼠，而一直在鍵盤上工作會高效許多。
WINDOWS下的BAT也是腳本，但是並不好用，因為WINDOWS本身是GUI類型的。但是不妨礙使用宏這種工具。
儘量多的編寫一些自己用的腳本，你會發現很容易記住並且依賴他們。
1.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的一些使用技巧。雖然程式設計師喜歡彰顯個性，但是對於取消一點個性而帶來的好處來看，是絕對值得的！——我一直對於設定一個「養眼」的底色有強烈的愛好，這個簡單的設定也常得很多同事的支持，用這種方法可以讓所有人的獲得這個好處。
1.4 Notepad
一個好用的文本編輯器，是程式設計師的瑞士軍刀，用來處理一切臨時的、複雜繁瑣的工作。每個程式設計師都應該有一個優秀的文本編輯器，它要有飛快的打開速度，可以同時打開多個文件，有優秀的查找替換功能，對於XML\SQL和大多數的腳本、程式語言都有語法上色功能，而且可以存成不同編碼的文本。我認為LINUX上的VI是最好的，現在WINDOWS上也有了。另外古老的UltraEdit可以編輯二進位內容，EditPlus擁有很好的語法上色，Notepad++各方面都挺不錯，而且是免費的。這些都是值得考慮的。特別是文本內碼轉換功能，LIUNX和DOS的換行，都是很常用的需求。（在LINUX上有方便的dos2unix/unix2dos和iconv）
除了安裝一個這種軟體，還需要把所有可能編輯的文件類型的默認打開程序都設置成它。這個設置工作會大大減輕日後工作中的操作負擔！我甚至建議公司的IT人員應該對程式設計師的PC做標準安裝的時候，就設置好這個功能。
1.5 Excel
數據表格是程式設計師接觸到的主要業務數據格式，大部分非技術人員都會把「數據」類型的文件用excel來存儲。而Excel強大的篩選、統計圖功能也是程式設計師樂意輸出給其他工種同事的原因。因此程式設計師的PC上的OFFICE套件至少應該有一個Excel，或者免費版本的替代品如WPS或者OpenOffice.org。
而且程式設計師需要掌握直接用API來生成和解析EXCEL的技能，這個技能會讓跨工種溝通節省很多時間。特別是節省各種因為「格式錯誤」導致的問題。我就曾碰到過一個XML數據文件因為一個小小的語法問題，困住產品人員一整天的事情。如果你確實不想用微軟的這種封閉技術，那麼用更建議的CSV格式也是很好的，因為你同樣可以用excel來打開，只是不能擁有合併單元格、字體、顏色這些外觀性功能。
1.6 Visio
程式設計師大部分的圖應該用筆畫在紙上，或者白板上。但是更重要的是，程式設計師應該多畫圖來記錄自己的思路。這種思路最後的定稿，最好是以電子文檔來記錄。我使用過數款畫圖軟體，如Dia，OpenOffice.org，甚至是WINDOWS的畫筆，Flash CS，但是最好用的還是微軟的VISIO，特別是畫UML圖。雖然這個軟體價值不菲，但絕對值得使用。千行文字不如一個圖來的清楚。很遺憾我還沒找到開源的或者免費的軟體能媲美VISIO的。
1.7 MindMenager
思維導圖軟體出現的時間並不長。這種軟體強迫你按樹狀來梳理你的思路。對於有條理性自覺的人，其實這個工具的意義不是太大，只是一個快速畫「樹」的軟體。但是如果對於問題思考還未能很有條理的時候，這種軟體確實能幫助人理清思路。通常這種導圖文件並不能成為真正的文檔產出物，更更像是一種草稿。但是還是建議程式設計師嘗試使用它。除了收費的MindMenager以外，有多款開源的思維導圖軟體可選，功能都不錯。為了文件格式的兼容，團隊內應該確定用其中一個。開源的FreeMind是個不錯的選擇
1.8 開發伺服器
A. 使用程式設計師的PC
似乎伺服器程序開發都有一個傳統，就是使用專用的開發伺服器，然後由程式設計師的PC上傳並且遠程控制這個伺服器，來做開發和調試。但是在我開發JAVA服務的實踐中，讓客戶端直接連接到自己的PC上，利用IDE的調試器，確是能大大提高聯調的速度。根據很粗略的估計，使用直連PC聯調會比基於伺服器聯調節省最少70%的時間。因為漫長的看日誌（或者是使用GDB，有很多初級程式設計師都不太能熟練的使用命令行的調試工具）、改代碼、上傳、編譯、然後召喚客戶端程式設計師重新發起請求……這些事情佔了很多時間和寶貴的注意力。如果客戶端和服務端都以IDE方式運行在同一個PC上，你可以兩邊都做斷點單步調試，一切問題都變得異常簡單。
得益於JAVA的跨平臺特性，在程式設計師PC上調試過的程序，幾乎不會在真正的伺服器上有太多的BUG。實際上如PHP、PYTHON這些腳本語言，也是能做到類似的效果。而很多C++程式設計師也習慣用宏定義來讓LINUX上的程序在VC上編譯調試。但是始終不如JAVA那麼方便。
在性能調整的工作中，如果讓壓測實際運行在程式設計師PC上，可以調用很多漂亮的GUI性能分析工具，如JConsol。這也能性能改進工作有個很好的環境。
儘量在程式設計師的PC上搭建完整的開發調試環境，少依賴複雜的「開發伺服器」環境，會讓開發速度有很大的提升。
B. 使用虛擬機
現在的PC性能普遍很高，而且還有專門為了支持虛擬機的硬體支持，從性能上來看，是支持大量使用虛擬機的可能性的。
在WINDOWS上開發LINUX程序，如果用虛擬機裝一個LINUX，然後以GNOME界面的IDE開發，會是一種很便利的工具。因為和伺服器同樣是LINUX，所以大部分的程序開發之後可以直接放到伺服器上運行，都不會有什麼不同。而且LINUX本身有很多好用的功能，如利用SSHD的遠程文件夾，可以更好的和別的LINUX伺服器做互動操作。同時一些WINDOWS的程序也可以在虛擬機以外來運行。特別是現在還支持剪貼板和文件分區共享，用起來就更方便了。
作為開發伺服器，實際上負載通常很低，所以在一個物理伺服器上安裝多套虛擬機，可以讓每個項目都有自己完整的一套環境，是節省成本和管理費用的好方法。甚至很多工具伺服器都可以是虛擬機，除了SVN。
C. 文件同步技巧
多個機器之間的文件同步，是很常見的一種需求。一般LINUX伺服器採用sshd和scp功能來拷貝文件，這個命令行工具使用起來比較方便，缺點是必須要手工輸入密碼。作為腳本就比較麻煩。所以一般有兩種方案，一種是用expect這個 shell來寫腳本，模擬輸入密碼。另外一個就是使用rsync，這個軟體可以對sshd伺服器直接去同步文件，也是很方便的。可以用推或者拉兩種不同的方案，更重要的是rsync可以指定密碼文件，成為腳本的好幫手。
另外一個就是用samba，直接從WINDOWS的共享目錄功能去拷貝文件，雖然也算好用，但是寫bat去運行總覺得不夠強大。也有用SVN來傳遞文件的，但是這並不符合SVN的「提交」含義，是一種不好的做法。最後還有一些通過裝一個WEB伺服器，然後從另外一邊用wget來下載，這種對於定時自動運行的程序來說不失為一種方案，但是缺點是不夠靈活，只能限定是下載，而且限定了路徑。
總結來說，rsync和httpd+wget是畢竟好的同步文件方法。
D. 反思必要性
如同本節第一點所說，很多時候在程式設計師自己的PC上處理開發工作，是效率最高的，所以是否一定要有「開發伺服器」是一個值得思考的問題。在具體的實踐中，那些開發工作通常在PC上完成的團隊，其「開發伺服器」往往是一個測試伺服器，用來對最終聯通，展示臨時效果，內部QA之用。反而真正很少人在上面調試。可能取消「開發伺服器」是最好的，但是這個需要更多的實踐來證明。
1.9 構建服務環境
A. 構建腳本
對於C/C++類項目來說，構建是一門相當複雜的工作；而JAVA項目則相對簡單一些，只是需要一些打包的腳本，用ANT完全可以搞定。不管如何，一個可以自動從SVN上下載資源，然後在一個空白環境下生成「可安裝包」的腳本，是絕對必要的。而且應該是能全自動處理，每天都自動編譯一個安裝包出來。這個是現在最流行的所謂「持續集成」的基礎。
這裡面還有一個小技巧就是關於「版本號」，一般來說構建腳本應該支持以命令行參數方式輸入版本號的功能。而版本號則應該能在構建過程中，編譯到項目代碼中去，這樣在運行這些代碼的時候，就可以編寫一些輸出「版本號」的語句，以便在測試過程中確定軟體的版本。C/C++項目可以用環境變量配合宏定義來處理。JAVA和其他一些項目，則需要寫一個version文件。
B. 構建伺服器
構建伺服器必須是單獨的，空白的環境，建議使用虛擬機。構建伺服器本身應該和目標部署伺服器的系統採用儘可能一致，特別是對於C/C++項目來說，內核版本，64還是32位的系統，都至關重要。如果編譯過程需要一些額外的庫和工具，首選從SVN上下載，作為項目的一部分，如果實在無法做到，則需要有清晰的「伺服器構建軟體環境」的自己的安裝包SVN和安裝配置說明文檔（同樣放在SVN上）。我建議構建伺服器、測試伺服器、開發伺服器、運營伺服器都基於同一個系統環境的設定去安裝。如都安裝同樣版本的GCC或者JDK，安裝同樣版本的PYTHON和apache等等。
1.10 測試伺服器（內測）
安排一臺伺服器放在區域網，隨時在上面部署最新的代碼，是一個很有必要的布置。因為產品、美術或者其他一些非技術人員，可能需要依賴最新的代碼對產品進行另外一種「開發」——添加數據內容。有一個不受程式設計師頻繁修改調試的伺服器，對於他們的工作效率是很有益處的。同樣程式設計師也不用受制於別的工種進行開發。
為了利用好測試伺服器的功能，有一個非常重要的工作，就是讓代碼能夠自動的部署到測試伺服器上。如果還是由程式設計師去部署，這個額外的體力勞動會消耗不必要的程式設計師的時間。而編寫自動部署的腳本和預先設定環境，雖然一開始會消耗不少時間，但是這些自動部署的工具，同樣可以用於別的測試環境甚至是正式運營網絡上的伺服器，是一個一箭雙鵰的好事情。
對於美術、產品或者別的非技術人員，添加的數據往往也需要有自動部署的工具，而且因為通常他們產生的文件比較大，每次的全體打包然後覆蓋，可能會非常沒效率。比如美術資源一共有10G，但是你只需要更新其中的2M的文件。這個時候就要設計好「增量」部署的腳本，或者你可以看成是「補丁」型部署包。用rsync可以只拷貝有變更的文件，而tar也可以指定打包的文件，或者寫一個精巧的Python程序來處理，也可以嘗試用make和ANT工具來實現。雖然這個事情不是太容易做的完美，但是絕對是物有所值。
1.11 體驗網環境（外測）
很多時候，網絡環境會暴露出很多意想不到的問題，如網速變慢，有些交互會變得奇怪。在不同的伺服器上，部署和配置可能會出現錯誤。而且對於測試人員來說，一個和真實運營環境高度相似的測試環境是非常重要的。最好還能讓不同的測試人員從各種不同的接入網絡（客戶端網絡）來測試。因此一個具有類似於正式運營網絡的環境，顯得尤其有價值。
對於發布和部署來說，也是一個真實考驗自動部署和發布工具的最好測試環境。體驗網的環境，實際上應該拒絕開發人員直接訪問，而真正的給運維人員一個實戰的環境，看是否有一些遺漏的問題。只有經過了體驗網的測試，產品才真正能部署到外網運營環境中。
一個隔絕開發人員的體驗網環境，除了能提供更實際的測試條件外，還能提供很好的管理區域分界：開發和運營。通過這個環境，能區分出哪些問題是開發引入的，哪些是運維引入的。
有些有條件的團隊還可以要求一些外界的人士參與對體驗網上產品的測試，這樣更加能提高測試的細緻程度。不過能提供這種支持資源的公司並不多，因為用戶也是需要資源去換取才會來測試的。如果有一定用戶來，還可以錄製他們的測試行為，然後為壓力測試提供原始數據。
1.12 壓測環境
壓力測試是一種比較講究技術的開發工作。除了自己模擬一些情況外，錄製用戶的行為然後按登錄會話並發請求，是一個很使用的壓力測試策略。為了避免壓力測試佔用開發網絡和伺服器太多的資源。一般會專門配置發起壓力和承受壓力的伺服器，然後讓他們接到獨自的一個交換機上。
1.13 單元測試工具
單元測試的概念是最原始的工程概念之一。早在單元測試工具出現之前，就有人提倡為每個類都寫一個main()函數，裡面專門放一些自己編寫的測試代碼。現代的xUint工具已經普及多重語言，如JUnit, CPPUnit, ASUnit等等。不斷追求自動化和邊界的測試工具，應該是每個程式設計師的目標。完善的測試能解放程式設計師的巨大心理壓力——改了很多代碼後，會不會有BUG？用程序來自動檢查，是最好不過的了。實際上現代編譯器都提供很多規則，這些規則也是一種靜態檢查，好的代碼能通過靜態檢查後，大大減少BUG。單元測試則類似於這種檢查，但是是動態的，所以需要程式設計師自己用測試代碼去定義「規則」。在編寫準備去單元測試的代碼的時候，會讓這些代碼變得結構更良好，因為第一個使用這些代碼的客戶程式設計師就是自己。
單元測試對於網際網路應用來說，一般會有一個困難，就是需要大量的「腳手架」，比如為了測試資料庫操作，必須要有一段代碼「重置」資料庫的狀態；為了測試網絡打包解包，則需要用一個程序向某個網絡埠發數據。準備這些測試工具代碼的時間，往往會比較長，需要有足夠的耐心去做，但是一旦做好了，往往能讓開發風險大大降低。
2.合作工具：
有一門專門的知識叫：軟體配置管理。其實講的大多數就是如何利用合作工具來提高開發效率的。一般來說，編譯型語言的軟體配置管理會比較複雜，而解釋性語言的軟體配置管理則簡單的多。我認為合作之中溝通、交換是2個主要主題。溝通方面面談是最有效的手段，而交換則應該多利用工具。
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.2wiki/知識庫/IntraBBS
寫程序的同時會有大量的文檔，如何管理這些文檔，是一個重要課題。我認為文檔主要分為幾類：一、API使用手冊；二、架構設計文檔；三、經驗知識的積累。
關於「API使用手冊」這類文檔，有javadoc這類直接嵌入在原始碼中的文檔規範，然後有天然工具可以自動導出。我認為這類文檔在自動構建的時候同時自動輸出，然後跟隨發布包發布是最好的。使用者可以跟隨同版本軟體一起獲取。
關於「架構設計文檔」這類，最大的問題是版本更新，因為往往進入開發期之後就少有人再去更新，導致後來需要用的時候，已經有大量不同，而這個時候往往是有人離職需要交接的緊要關頭。這類文檔從開發角度，放在SVN還是放到內部WIKI上其實都是好的，但是關鍵是怎樣維護。個人意見如果團隊較小，直接用SVN即可。如果團隊成員超過50人，文檔可以由多個人一起去寫，放到WIKI上能彰顯大家的努力，也方便大家查閱。
內部BBS很多時候最後變成灌水聖地，對於開發效率的推動其實不大，不過作為一個「軟福利」，有些時候也有一點用，總體來說我不太認可這種東西的價值。
2.3 IM(QQ,RTX...)/E-MAIL座機/sms
關掉IM！關掉E-MAIL！電腦上的即時通訊工具被某些人認為是「必備」的工具，而我則認為郵件才真正是工作用的工具。考慮到程式設計師的注意力很容易被這些突然闖入的信息所幹擾，我更傾向於直接關掉IM軟體。電子郵件也只在固定時候收取，如中午和下班前。很多人對IM和郵件反應很快，很多時候是因為他們根本沒在認真幹活，或者工作並不飽和。座機和簡訊是一般辦公的必備工具，座機可以省了跑來跑去的溝通，但我認為當面溝通還是比座機要好。我理想的辦公室應該是通道寬敞，每4-6個座位中間都可以有個小型討論區，有白班和多於的幾把椅子和一張小桌子。
簡訊我認為還是很好用的一種工具，特別是某些需要記住的信息，比如日程提醒、電話號碼、或者一些IP位址之類的東西。用來作為每天的業績提醒，發給團隊中所有人，也是很好的。另外用來作為自動報警消息，是保證不在IM和郵件叨擾的情況下最關鍵的實時通知工具。設置一個企業自己的簡訊網關，是很有必要也很有價值的。
2.4 公共文件伺服器
公共文件伺服器可以是WINDOWS也可以是LINUX+SAMBA。我認為這個伺服器是SVN的一種補充。主要用來存放兩種文件：1）開發工具和各種伺服器軟體。這些軟體應該是標準化環境的一部分，所以應該共享使用。2）每日構建的發布包以及各種版本的發布包。發布包本身在測試工作中是最基本的需求，所以應該有一個集中的地方存放。我建議同時這個伺服器也具備HTTP下載功能，這樣很多LINUX腳本也可以自動去抓數據了。
2.5 持續集成服務hudson
持續集成是現代軟體開發的重要目標。如果沒有自動化的持續集成工具，軟體的開發和測試將會效率非常低下。Hudson是一個很好的持續集成工具，可以直接從SVN下載代碼，執行腳本然後運行。本身是JAVA的程序可以同時處理WINDOWS和LINUX上的構建。
持續集成的基礎是SVN版本管理的標準化；然後是擁有自動化的構建腳本；最後是擁有自動的打包和部署腳本。持續集成系統只是把這些工作串起來的一個工具。
不管持續集成是多麼的繁瑣的工作，但是這些一定會物有所值。
2.6 開發者微博
有些開發方微博實際上是市場宣傳軟文，我暫時不討論這個。有一種實踐是把SVN的注釋自動提交到WIKI上，然後大家用RSS訂閱。其實這個就是一種SVN的注釋自動生成的微博。這種方法用來自動溝通代碼修改，其實是很自動化和看起來可行的。實際上大部分人都只關係一部分代碼，只有管理者會比較關心大部分內容。所以用發送電子郵件可能比上微博要好。也有一些關閉了IM軟體的團隊用內部微博來公布廣播消息，也比較受歡迎。不過我個人不贊成為了這單需求去搭個內部微博，還是自動郵件好了。
2.7 遠程桌面伺服器、跳板機
很多時候為了提供團隊成員可以在辦公室外環境工作，都需要架設一個「跳板機「供直接遠程桌面到自己的辦公機上幹活。我承認這個做法確實能解決一些臨時事故修理的問題，但是實際上安全隱患很大，如果跳板機被攻破，整個公司的代碼可能就被拷貝走！
架設遠程桌面伺服器、跳板機，一定要做到非常高的安全級別，起碼都要不被網絡上掃描掉。否則就不如不做。
3. 管理工具：
3.1 缺陷跟蹤管理工具JIRA
其實這種工具也算一種溝通工具，有時候可以代替Project這類軟體，據說網際網路上很多開源項目都是用JIRA來做特性和缺陷管理。使用這類工具管理者比開發人員要積極，因為這個工具更多的是「任務分派」和「任務統計」的功能。而開發人員則需要不停的去查看自己的任務，然後做完之後還要手動上去提交或者寫意見。寫注釋這種事情有時候是比較蛋疼的，很可能沒有人會看，原因是寫注釋的人很少寫的很清楚。所以使用這種工具，我認為最重要的是要做好自動化插件，如SVN直接用注釋驅動JIRA去改進任務。
如果你同時在使用EXCEL或者PROJECT和JIRA同時來管理工作進度，這裡就會有一個很大的風險：JIRA上的問題和缺陷會難以納入到你的工作總體任務列表中，因為這些缺陷可能測試人員在不斷的添加。
使用缺陷管理工具的最好實踐是，全部任務都用這個系統來管理；如果不能的話，就不要把BUG以外的任務納入這個系統；如果還是不能的話，就要做好人工的「分級」制度，或者為每個任務都嚴格加上一個「版本」的屬性，用來劃分出哪些是應該在現在就要完成。
3.2 項目進度管理工具Project(Server)/ProjectManager.com
Project是個好軟體，但是我一次都沒能成功安裝好Project Server，太悲劇了。ProjectManager.com就是一個不錯的項目進度管理工具，是完全基於WEB的，可惜是收費而且全英文的。Project的主要功能我認為有2個，一個是關於資源的自動計算，一個是自動勾畫的甘特圖。但是軟體開發往往小任務、突發任務很多，碰到的延期和別的亂七八糟的事也多，所以嚴格描述開發流程，是一個非常困難的任務，就算你用Project也是一樣。所以一般來說Project適合描述一些比較大粒度的計劃，如果資源細到人，項目細到模塊，這個Project文件將會是維護的無底洞。
少花些時間在Project表的制訂上，而多一些花時間來通過面談和測試來掌握進度。
3.3 版本任務列表/牆
現在流行的敏捷開發，都有提到「項目儀錶板」「任務牆」這些東東。然後每天早上開會大家來匯報一下任務的進度情況。對於這種實踐，我覺得沒有什麼突出的好處，也沒有什麼突出的壞處。
但是把版本任務都放到牆上，本身能提供一定的激勵作用，這個做法本身也是逼迫管理者一定要明確版本目標，篩選需求。與其說是給開發成員看的，不如說是給管理人員的限制。因此這種東東，還是很有必要的。
4. 總結：
本節列舉了大量軟體開發的「軟體工具」，但是肯定還會有更多的軟體工具出現，我認為使用某個工具，在某個工具投入精力和資源，是應該有明確的辨識原則的：這個工具，一定要能節省程式設計師的注意力，而不一定是節省時間或者現金開支。因此能夠減少非編碼和寫文檔的操作，能自動化就自動化，就算為了這個事需要耽誤一些開發時間，最後也是很補回來的。而有一些工具，看起來很帥，但是需要分散程式設計師的注意力去搞，就是不值得使用的。
感謝大家的閱讀，如覺得此文對你有那麼一丁點的作用，麻煩動動手指轉發或分享至朋友圈。
PS.今天的圖片全部來源於網絡，如有侵權，請聯繫我刪除。
本文轉自：開發者頭條
微信號：IdeaofSE