分享合作开发

事件背景：
雪茹，德鹏，零敏，我，合作开发机房收费系统。
雪茹负责整个系统架构的设计，零敏负责界面层，我负责业务逻辑层，德鹏负责数据访问层。
 
开发过程中，
 
我跟零敏争吵最多的是：“你给我传过来的是什么，我返回给你的是什么。”
“这个字段的值，你没有给我，我怎么知道”
 
业务逻辑方面，缺方法，或者参数问题，导致一些问题，“你不给这个，我显示什么”，“我也没有啊，我都不知道从哪获取”“怎么没有往这个表里写信息？”“根本就没有这个方法”
 
整个过程，我们都在不断摩擦中进行着，我们是一边在改UML图，一边在编码。每个人似乎都是设计师，每个人又似乎都是编码工人。
 
我们能完成这个系统，一方面是因为文档（主要是UML图）的帮助，一方面是因为我们对业务比较熟悉，当然也少不了大家的努力。
 
可以说，我们的配合是相当不默契的，幸好大家都在一个屋，可以商量着来，如果不在一个地方，估计这个系统的完工将会遥遥无期。
 
总结这次的过失：
 
1、组员应该收到的是部分文档，而不是全部，编码工人就是编码工人，责任分工要明确。
 
2、系统的整个架构没有太大问题，主要集中在Sqlhelper的位置上，在灵活性和可重用性上设计得不够完美。
 
3、细节方面问题不少，例如方法的参数和返回值方面，导致我们互相踢了皮球，认为这是上一层或者下一层的问题，好在最后都协商解决了。
 
4、有些地方并没有按照文档严格执行，并不是故意按自己的逻辑来，而是因为有些地方按照文档执行并不能满足需求，这和前期设计有关（如果是我设计，估计也会出现类似的问题），在系统设计完成后再去修改设计，这样风险性很大，因为如果突然改变某一方面的设计，很有可能会造成牵一发而动全身的结果
 
5、我和大家的沟通方式欠佳，出现了正面否定别人的情况，没有委婉一些。在我看来的就事论事，可能对我的同伴造成了伤害，在礼貌和沟通方式上，我还有待改善。
 
6、我过多地干涉的设计的的修改，把我的模式强加给别人，我应该适时的否定自己，去发现别人想法中值得借鉴的地方，而不是一味强调自己的想法。
 
7、我过多地干涉了组长的权力，可能是着急了吧，有督促的嫌疑。主要原因，没有摆正自己的位置，下不为例。
 
虽然我们成功架起了SVN，拉起了团队，一人负责一层，但仍然出了那么多问题，我不知道这次合作应该算成功，还是应该算失败，但可以确定的是，这次暴露了我们很多问题，我们需要学习的还有很多。