团队开发过程中的一点感想

头疼。

我只愿面朝大海，春暖花开。

↓↓↓

【Action】

以前还不觉得单人开发和团队开发的区别有多大，以为顶多就是把一个人的任务分给了多个人而已，但是其实不然。

我也是在经历过团队开发之后，才感觉到了单人开发与团队开发之间的重大区别（大致情况在后面说明），并不仅仅是将任务划分一下就完了。

而在之前我之所以任务他们之间的区别不大，只要是因为我忽略了一个问题，在团队中中的每一个人都是一个独立的个体，每一个独立的个体都会拥有一种不一样的思想。

一个独立的人思想是可以根据自己本身的需求和意向而改变的，但是如果是一个团队，团队里面同时存在着多种独立的思想，思想与思想之间是会发生碰撞的，有了碰撞之后就极有可能产生争议，一旦产生争议，就是问题的开始。

如果没有一个能够拍板的人，那么整个团队将会伴随着越来越多的争议而走向消亡。

特别是如果在一个团队中，存在着那种非常固执任性的，不服从指挥，坚持我行我素的人，那么这个团队消亡的速度就会愈发的快了。

算了，不叨叨这多了，开始正题！

首先先了解一下开发的大致步骤。

▍开发步骤

1、需求分析

2、页面原型设计

3、数据库建模

4、架构

5、类设计

6、编码

7、测试与调试

8、部署

▍项目前期

第一个也是最重要的：找好领头羊，不是每个人都适合作为领导者，这个领头人一定要在团队中有威信，有公信力和领导力。

另外如果自己自身在团队中没有威信，领导力不够，那么最好不要当这个领头人，乖乖的当个小组员，做好自己的本职工作就好。

当一个无法让众人信服的组长是一件很头疼的事情（这个我刚刚吃过亏！！！原以为当个领头人是个很简单的事情，结果发现，自己很难在组长中建立威信，布置的任务总是拖延或是敷衍了事，根本达不到要求，很多时候都想自己把全部的事情给做了算了。弄得我现在头疼得很）。

团队互补是很重要的，好的搭配才是精彩的开始，糟糕的人员搭配只会让事情变得很糟。

组队的时候不能只看个人能力，还要看个人的沟通表达能力，有时候个人的性格脾气也会对整个项目的进度产生影响。

人员分工一定要合理，包含两点：第一好钢要用在刀刃上（不要让不熟悉相关工作的人做相关的事情），第二每个人的工作量尽量做到最好的“均分”。

▍需求分析

单人完成！

主要分析这个系统是干什么的，需要哪些功能，用户主要是哪一类人群。

在需求中需要有完整的用例图和用例表，不只是做到“差不多”，而是要做到用例全覆盖。以下为单个用例表实例：

在需求中要指出变量、函数、类等的命名规范。

确定页面缓存方式，哪些表格是按照整个表格缓存，哪些表格是按照单个字段缓存。

需求文档一定要完整清晰，发现其中有欠缺的地方要及时完善补充。

▍页面原型设计

单人完成！多人同时提供设计思想会导致页面始终难以确定。

如果其他人有任何意见，可以在设计完成后提出，如果最后关于某个问题争执不下，那么就团队投票表决或者是组长做决策，不要在一个小问题上纠结太久。

▍数据库建模

单人完成！

在数据库表的设计上要保证科学合理，数据表的构建一定要符合3NF范式。

每张表必须有一个自增id作为主键，不做其他用处，只是用来标识数据的数量。

▍架构

架构构建的时候，尽量使用当前流行且成熟的框架，保证架构的实用性与牢固性。

▍类设计

类设计就是要设计出有哪些类，这些类中又分别有哪些方法， 每个方法是做什么用的，然后这些方法之间又是怎么连接在一起的。

▍编码

我个人认为编码应该分为两个小的阶段：

第一阶段前后台独立编码，前台完成页面的制作，后台根据页面原型图敲定大体上会用到的函数以及函数以及所涉及到的变量，这段时间内前后台是互不影响的，可以独立同时进行的；

然后前后台独立工作完成之后，就可以进行整合了，第二阶段前后台整合，前台在后台中找到所要请求的函数，如果有并且正确，那么就直接调用这个函数，如果后台没有考虑到这个函数，或者函数的参数与返回值不满足前台的请求方式，那么就需要对后台进行微调，这个时候前后台人员的交流就要多一些了。

不要想着能一次性写好，这是不可能的事情，或者说是做梦。。。

如果是前后等后台完成之后再动工，或者是后台等前台完成之后再动工，那样的话中间等待的时间就会被浪费掉。

我的队员就犯了这样一个错误，我做前台，他做后台，我把前台页面做好之后，问他后台的编码工作完成没有，结果他说他在等我前台的变量名定好之后再动工，我简直要气死了。

离提交时间就只有这么短了，他竟然告诉他还没有动工！！！

不过要说怪的话，也怪我没有事先说好编程阶段的时候怎么做，没有把我的看法拿出来跟他们交流（我以为他们应该跟我想的一样）。

团队中的每个个体都需要有良好的编程规范，多写注释。

▍测试与调试

这一步骤是为了保证程序能够正常跑起来。测试是为了找出Bug，而调试是为了找出出现Bug的原因，然后修改程序修复Bug。

团队之间肯定会存在方式思路不同的时候，调试过程中，当我们觉得队友的代码或者处理逻辑有所欠缺或不足时，在没有与原始编码人员商讨的情况下，不得擅自修改，防止出现“交叉版本”。

▍部署

运用不同工具开发的项目，其发布的方式也可能会有相应的区别。

比如如果是普通的web项目，有两种方式：第一种在编辑工具中配置服务器（例如在eclipse中配置tomcat），然后启动配置在编辑工具中的服务器，项目就可以跑了；第二种是将web项目打包成war包，然后放在放到服务器中运行。

▍项目后期

项目完成之后，要看到这些文档：

需求分析文档

项目总体设计报告

项目详细设计报告

项目进度报告

项目测试报告

项目使用说明书

项目风险评估报告

▍注意事项

项目过程中要有定期会议，每次会议要有会议记录。

▍我是尾巴

这篇总结本来应该昨天就搞定的，但是本来做了一天的事，人就有点昏沉，再加上组员有没有按照我的要求做事情，所以更加头疼。

实在是坚持不下去了，就去睡觉了，然后早上也醒得早，就起来赶工咯。

这篇总结肯定还有一些不足之处，在后面积累更多的团队项目经验后，应该对整个流程会有更深的理解。

↓↓↓