博客地址：http://blog.csdn.net/hopestar2/archive/2010/08/11/5804941.aspx这个项目是属于上一个项目的二期优化，除了完善上一个项目中不足的地方，增加了两个较大的功能，一个是游戏的中途加入，一个是游戏野怪的设计与实现。 这个项目有两个人来完成，另一个同事是从百度跳槽过来的，经验还是相当的丰富,所以合作还是相当愉快的。我们知道游戏分为前台和后台，由于那个同事只熟悉后台的东西，所以他主要负责后台的野怪战斗逻辑，我主要负责前台所有的界面和一部分后台的处理逻辑。 这个项目的主要收获应该是一个小项目怎么从需求一直到上线这一套完整的参与流程，最难的是对进度的把握以及两个人之间的协作。通过这个项目学到下面这些东西吧： 1. 首先需要明确需求，对给出的需求文档进行评审和讨论，哪些是技术上可以实现的，哪些是不合理的，不合理的要和策划PK,然后直接的咔嚓掉。 2. 明确要做的东西，然后再程序员讨论需求的实现方案，确定各自的分工。虽然公司没有要求必须有严格的设计文档，但是我们在底下实现的时候，需要将自己的设计方案形成一份文档，将需要解决的重点，难点问题记录下来。譬如说前台和后台的接口如何设计，这点至关重要，因为是各自开发，最后才是联合调试，所以需要定义清楚的接口。游戏野怪为例，前台和后台的数据接口是相当重要的。 3. 只有有了清晰的设计和实现方案后才开始动手写程序。这个一个月的小项目真正花在写代码的时间只有一个星期多一点点。想清楚后在动手，是绝对的真理，边做边设计其实效率是相当低的，只有边做边完善设计的不足才能产生最大的效益。在写程序的时候也是分清楚重点，难点。对于难点，需要多花一点时间研究，对于重点的地方一定要仔细，要考虑到这种边界条件。 4. 关于联合调试，这是两人以上开发肯定会遇到的，联合调试这一块最重要的是沟通了，会遇到这各种各样的问题，对于这个我绝对关键是要有耐心，慢慢沟通，协调问题肯定会一个个解决的。 5. 联合调试完毕，整体的功能就算是开发完毕了。然后就是部署测试环境了，搭建好测试环境，交给测试进行测试，测试测试包括两部分，一部分是功能测试，功能测试完了还要回归测试，因为毕竟是上一个项目的优化，不能影响以前的正常功能。 6. 修改BUG，是重头戏，测试考虑问题都是，假设你这个系统有问题，程序则是假设这个系统已经是完好的了。所以测试总能发现我们程序开发时候没有注意到的地方。快速修复测试的BUG是一个程序员很重要的素质。 7. 测试组测试完后，就可以合并代码了，因为开发新功能的时候，都是拉了开发分支的，所以需要将代码合并到主干上去。合并代码绝对是个细致的活儿，我最讨厌在合并代码的时候被别人打搅了，所以合并的代码的时候，我通常将所有的通讯工具设置为忙碌状态，最烦的是坐在座位上还有人来找，这种时候，我通常都是会先记录一下合并到哪里，回来再接着干。合并完代码后，需要部署到测试机上进行一下回归测试。 8. 回归测试结束后，就准备安装包，正式部署到线上服务器上去。至此一个完整的开发周期就结束了。 关于沟通协作: 这个虽然是个小项目，但是需要用到的人员确很多，有策划，美术，测试程序四方人员。所以沟通是个比较大的问题，有双方沟通的，也有多方沟通的。沟通涉及到这么多人，扯皮的事情肯定会有，但对程序来讲，永远要记住，反正最重要的是获取自己实现系统所需要的资源。 合并代码的方法和比较好用的工具：合并代码纯粹是细致的体力活，精神需要高度的集中，合并代码通常都是根据SVN的修改记录，根据修改记录将一个个修改合并到主干上，提交的记录比较多的话，真是搞死人，比较好用的工具推荐BeyongCompare，这个工具用了好久了，是目前用的最顺心的文本比较工具，很好很强大。本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/hopestar2/archive/2010/08/11/5804941.aspx
最后我一个人合并.累死我了.
划分多个里程碑，代码合并会容易点，而且测试也方便
边做边设计其实效率是相当低的，只有边做边完善设计的不足才能产生最大的效益