一、硬件资源
1） 办公环境
大部分开发团队都不把座椅家具视为一个非常重要的问题。拥有宽敞的桌面的环境，可以在桌上放置更多的东西：本子、笔、杯子、书本、打印的资料。更重要的是在和其他人沟通的时候，我们可以一起坐在同一个桌子前面，而不必去找个会议室。宽敞的桌面一定比窄小的桌面更有利于提高程序员的效率，而且费用通常不是想象中的高。
不知道你有没经历过整个开发团队在一个会议室中做集中开发的时间，相信如果经历过的人，都会对这段时间内的工作效率有深刻印象。一个相对封闭的环境能隔绝外部的干扰；所有的沟通都是围绕着工作目标，而不是微博上某个有趣的新闻，能加快团队成员进入高专注状态的速度；团队成员之间可以用语言和目光以及肢体来交流，节省了很多在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
一个好用的文本编辑器，是程序员的瑞士军刀，用来处理一切临时的、复杂繁琐的工作。每个程序员都应该有一个优秀的文本编辑器，它要有飞快的打开速度，可以同时打开多个文件，有优秀的查找替换功能，对于XMLSQL和大多数的脚本、编程语言都有语法上色功能，而且可以存成不同编码的文本。我认为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.今天的图片全部来源于网络，如有侵权，请联系我删除。
