关于团队开发的一点点想法
最近在干活中终于体会到了一点点团队开发的思想。但是我觉得我们的团队开发做的还不是很好，所以我想在这里谈一点点这些日子的感受，让自己也能记得清楚一些，在以后的工作中也能改正弥补一下现在的不足。
团队开发真的是一件很不容易的事情，而做大的项目，必须要由团队来完成，在这过程当中，会出现很多很多的问题，因为开发人员都是人，不可能像机器执行程序一样，只要有固定的代码，就不会出现代码以外的问题，更何况不是一个人而是一群人。所以如果想让一群人按照既定的规则来进行各自的活动的话，就要有一套合理的规则和方法，这些方法就是软件工程，但是那些大条大框我就不说了，我现在还没有特别多的体会，我只结合软件工程说一说我现在的小体会。
首先我要强调文档的重要性，从开发过程来讲，应该是首先有三个文档-需求文档、设计文档、数据库设计说明文档，然后把设计文档的内容意义传达给每个开发人员，所有开发人员都要对文档进行评审，评审的过程也是思想接近的过程，设计思路的传递也就在这儿。等到整体框架设计完毕，就需要分头来进行详细设计了，这时还有个关键点就是做框架设计的人员要把每个模块要完成的功能和接口明确给每个人，这样做出来的各个模块才能很好的配合在一起。详细设计的时候每个模块要完成的功能都要详细到每个方法，特别是公有方法，要对每个参数和返回值做出详细的说明，这样在后期的调用时就会有据可依了。
在一切设计及评审都结束后就可以开始整体编码了，我觉得这时候编码的效果是最好的。因为在详细设计之前编码，有很多时候会因为设计不充分而导致后期改了又改，相信程序员是最反感改程序的，特别是改别人的程序，更令人难以忍受的是改那些没有良好结构也没有设计文档的程序。所以在完成设计之前最好不要开始大批量的写程序，如果写，也要有相应的文档。
还有就是对于一些中间产品的文档，也要尽量详细的写出来，因为中间产品是模块之间互相调用的东西，所以如果不写出详细的文档就容易使两个模块之间的调用出现问题。
再有就是编码规范的问题了，这个问题其实也是比较好解决的，但是不好解决的一点在于，每个人可能都有自己的编码规范，但是如何做到一个团队有一个统一的编码规范就不是很容易了。
再想就是谈谈新人的问题，如果一个团队中有新人加入，那么先不用急着让他来为公司赚钱，应该做的首先是让他融入公司的环境，更重要的是让他做一个团队中符合统一规范的人，等到他完全融合进来了就可以为团队发挥更大的有效力量了。
此上只是一点点小小的想法，团队合作，说着容易，其实做起来也是可以做得很好的。
团队开发真的是一件很不容易的事情，而做大的项目，必须要由团队来完成，在这过程当中，会出现很多很多的问题，因为开发人员都是人，不可能像机器执行程序一样，只要有固定的代码，就不会出现代码以外的问题，更何况不是一个人而是一群人。所以如果想让一群人按照既定的规则来进行各自的活动的话，就要有一套合理的规则和方法，这些方法就是软件工程，但是那些大条大框我就不说了，我现在还没有特别多的体会，我只结合软件工程说一说我现在的小体会。
首先我要强调文档的重要性，从开发过程来讲，应该是首先有三个文档-需求文档、设计文档、数据库设计说明文档，然后把设计文档的内容意义传达给每个开发人员，所有开发人员都要对文档进行评审，评审的过程也是思想接近的过程，设计思路的传递也就在这儿。等到整体框架设计完毕，就需要分头来进行详细设计了，这时还有个关键点就是做框架设计的人员要把每个模块要完成的功能和接口明确给每个人，这样做出来的各个模块才能很好的配合在一起。详细设计的时候每个模块要完成的功能都要详细到每个方法，特别是公有方法，要对每个参数和返回值做出详细的说明，这样在后期的调用时就会有据可依了。
在一切设计及评审都结束后就可以开始整体编码了，我觉得这时候编码的效果是最好的。因为在详细设计之前编码，有很多时候会因为设计不充分而导致后期改了又改，相信程序员是最反感改程序的，特别是改别人的程序，更令人难以忍受的是改那些没有良好结构也没有设计文档的程序。所以在完成设计之前最好不要开始大批量的写程序，如果写，也要有相应的文档。
还有就是对于一些中间产品的文档，也要尽量详细的写出来，因为中间产品是模块之间互相调用的东西，所以如果不写出详细的文档就容易使两个模块之间的调用出现问题。
再有就是编码规范的问题了，这个问题其实也是比较好解决的，但是不好解决的一点在于，每个人可能都有自己的编码规范，但是如何做到一个团队有一个统一的编码规范就不是很容易了。
再想就是谈谈新人的问题，如果一个团队中有新人加入，那么先不用急着让他来为公司赚钱，应该做的首先是让他融入公司的环境，更重要的是让他做一个团队中符合统一规范的人，等到他完全融合进来了就可以为团队发挥更大的有效力量了。
此上只是一点点小小的想法，团队合作，说着容易，其实做起来也是可以做得很好的。
