来北京学习也一个多月了，三层项目也结束了快一个星期了，觉得还是有必要总结一下。整个三层班级三层项目的效果在这里.

     我们组做的三层项目是一个经销商的管理系统，说真的，到项目结束后我都不知道我们组到底做了什么。在项目答辩之前，一直觉得我们组的项目是最二的一个，但没想到结果挺意外的。因为我自己觉得，其它组的项目都是一个完整的成型的项目，而唯有我们组的项目是一个不能够用的半成品，也许是题目太大了，在短时间内根本就弄不出来。

    在本次项目中我作为我们组的组长，收获其实也蛮大的，大概的就总结一下收获和问题等。

1、明确项目需求

     一个项目开始之前一定要了解项目的需求，如果不了解需求，那么这个项目在一开始基本上就失败了一半了。我们这次项目，在确定需求的时候，整个组基本上是懵懵懂懂的，唯有提出需求的那个人比较清晰，但是他说的，我们也基本上不了解。最后导致的问题就是后面发现，整个系统的缺陷毛病不断。特别是作为一个项目的负责人，明确的确定整个需求是非常关键的。

2、数据库的设计

     在确定需求以后，就要考虑数据库的设计了。一个项目中合理的数据库设计可以让整个项目的进行事半功倍。本次项目参考的别人的数据库的设计，总体感觉还算是比较轻松。不过由于项目需求的考虑不是很周到，在整个开发的过程中也对数据库有些改变，这让整个组员的工作也挺费事的。同时在创建数据库的时候，最好是先规定好命名规则以及数据类型，然后让一个人去搭建整个数据表格。由于我们这次试用的是SQLite数据库，让每一个组员负责一两张表格的创建，然后拷贝DDL代码由我一人创建数据库，最后没想到还是一团糟，这也成了整个项目组后面出现数据库改动的一个比较大的原因。

3、项目框架的搭建

     在这次三层项目中，我作为整个组的项目负责人小组长，项目的搭建也就是我来完成的，一开始我设想的是用TabControl控件将多个模块整合到一个窗体里面，每一个组员操作一个TabPage页来开发自己的模块功能，没想到不到一上午的时间，整个项目组就瘫痪了再也不能继续下去。原因就是表面上是每一个人在不同的页面中，但是VS后台帮我们生成的代码还是在同一个cs文件中，导致的结果就是冲突不断，所以后来又不得不花时间重写搭建一个框架。所以在项目开始的时候，一定要设计好一个项目框架，应该避免多个人操作同一个创建的情况，否则基本上就是死路一条。

4、命名规范问题

     在这个问题上，还好一点，项目开始之前规定了数据库的设计采用的命名规则，在开发的时候也规定了每一个CS文件以及方法的命名规则，但是由于组员很多时候并没有按照这种规定的方式去写，所以有时还是比较麻烦。但由于项目总体不大，看着CS文件就基本上知道这个文件是谁写的，不过在后面维护整合的时候，由于组员对有些控件没有取名等维护起来还是比较困蓝的。

5、代码规范问题

     这个问题，其实也不好讲，整体来说，什么是代码规范也说不上。只是觉得有时在代码中缺少一些必要的注释导致后面维护以及别人来调用方法的时候比较困难。

6、任务分配

     作为一个项目的负责人，那么就要给每一个组成员去分配项目内容，在分配的时候描述清楚任务的各种需求等是至关重要的。由于这次项目开始的时候，对整个的项目需求我也不是很清楚，导致在有些功能模块功能的分配上就没有讲清楚这个功能具体要实现成什么样子，只是简单的告诉了他们要做什么，第一次出来的结果是惨不忍睹，有些模块由于做过相对来说就比较清楚，做的效果也还比较好。

7、合作开发

     这次项目中使用的是SVN来进行团队合作，应该来说这也是我们每一个项目组的成员最大的一个收获。团队合作中，不能够随便的改动别人的代码，真的要改，也最好是先给写这段代码的人说一下，让他来进行稍微的调整以满足自己的需求，如果实在是不能够改，那就可以重新写一个方法，由于三层中一般讲究的是一个表对应一个BLL和一个DAL那么这样重写写一个方法的事情就可以交给要调用这个方法应该出现的类中的这个人来写，这样就能够避免对同一张表格的访问出现在不同的地方。这次项目中，在后面整合的时候，我没有和组员商量的情况下改了一下代码，导致的结果就是后面的功能基本上是瘫痪了，这是因为按照数据库的设计中应该是通过联合查询来得到结果，但是没有想到的是，在他负责的数据表填数据的时候，却不是这样弄的。没办法由于时间的关系，后面也就只能将改过的代码又改回去，虽然代码的实现上很不合理。还有就是在后来项目结束的时候，一个组员说他晚上偷偷改过我们的代码，也不知道这到底是不是真的，因为每一次只要是他提交的代码那结果就是当我们更新的时候，冲突不断，在这次项目中可以说70%的冲突都是由于他提交上来的代码引起的，也花了不少的时间去调试错误，这也就说明了在整个的开发中沟通少了，还好每一个组员都还比较随和，没有过多的计较。

    另外就是当在使用SVN进行源代码管理，提交的代码当遇到冲突问题的时候，要先看看到底是什么地方引起的冲突，如果是两个人动了同一个文件而导致的冲突，在处理的时候，最好是两个人一起来商量问清楚，怎么回事，然后决定怎么解决这个冲突。如果都是别人的文件，可以覆盖掉自己已经存在的文件，但也最好问问是不是改过，当然如果是自己的，那就可以直接覆盖了。冲突以后，一般是引用别人的解决方法，然后手动把自己的代码给加进去，这样在自己本地就能够得到一个比较新的版本，当前在更新代码之前最好是别忘了备份自己写的代码。

8、沟通交流问题

     多人合作做一件事情的时候，一定要多多的沟通，多沟通能够解决很多不必要的问题。我作为组长，说真的和组成员的沟通之前也比较少，也因为这样导致了一些问题。上面说的我改了成员代码又改回去就是因为缺乏沟通，一开始没有了解组内成员做东西的时候，怎么实现的或者说自己没有把实现的一些基本的要求给传达过去，这是根本原因，后来在改代码的时候，没有通知组成员，最后还带了比较严重的情绪，最后考虑到时间的关系还有就是根本的错误在我，所以我妥协了改回去，虽然他写的很不合理，不合理也就只能够将就着用，但是我想以后不会再发生了。另外还有就是在把任务布置后也就没有关系他们的实现，有的成员提交上来的结果真的是一团糟，然后又打回去改。这一切的原因其实都是需求不确定以及沟通上出了问题。还有就是在窗体的相互调用上也出现过不少的问题，就是最后发现调用的窗体和自己想要实现的功能还是有一些不一样，最后又只能重新修改窗体或者自己再写一个窗体，其实这种问题，在之前就可以商量好，相互之间需要什么东西一次性弄好，避免二次修改浪费时间和精力。

9、权限问题

     多人合作的时候，操作很多的东西都是一样的，典型的例子就是数据库和Mode对象了，由于一开始给每一个成员都分配了读和写的权限。那么每一个人都有改写Mode对象的权限，导致了一个问题：联合查询后将数据绑定到一个 DataGridView 中，有些属性是一个对象，那么显示的就是这个对象的全称，而不是数据，于是每一个人能够想到的第一个办法就是重写这个类的ToString方法，这样导致的一个问题就是每一个人都可能会重写，后一个人重写的就把前一个人重写的给覆盖掉了。其实说到底也是沟通问题。但是在大项目中，这种类很多的时候，沟通也许就不一定能够解决办法了，后来就改了对Mode和数据库的读写权限只能够读不能够写，在显示数据的时候，不使用数据绑定，使用手动创建单元格的方式，或者自己重写单元格的显示方式，这样问题也就解决了。现在想这类问题应该是在项目搭建的时候就应该解决的问题，或者说是项目开始之前就应该有一个项目的规范或者规定子类的东西来进行约束。

10、项目整合

     其实这个方面，到没有多少问题，只要在开发的时候没有出现太大的冲突就可以了，最后在整合主界面的时候，也花了不少的时间，幸得室友指点，把主界面给倒腾出来了，这个问题的解决上也就体现了相互之间的交流有多重要了。

    总体来说这次项目的收获还是比较大，虽然我个人觉得项目做得不是一般的烂，没想到主讲人给力，结果还比较客观。通过这次项目让我收获到的不仅是知识，更多的是怎么更好的去和一个团队一起工作，还有就是怎么去搭建一个简单的项目框架，项目需求的明确和开发规范对一个项目的重要性，当然作为项目负责人也知道自己要担的责任不再是自己负责的功能不出现bug，而是要保证整个团队高效的完成任务。