谈谈个人代码对团队合作影响

　　这几天正接手一个项目，属于后期功能拓展，要拓展这个项目，一定程度上要看到源码的部分，然后烦心的事情就来了，这代码写的真是让人挺无语的，原先写完整个项目的是已有多年工作经验的开发者，但是整个代码下来，逻辑性不强，单看完整个流程，各个模块的作用，就花了一两天的时间，这还没涉及到代码部分，缺乏相应的注释。这也给了我很深的印象和感悟，不管是个人写代码，还是团队合作，对于框架要明确，有结构图，有相应的注释，命名规范相当重要，尽管项目不大，也要逻辑分明，这是对于日后拓展和维护都是有好处的，所谓在实战中学习，真的是学到了好多，写自己的代码改动日志，将任务，思路，想法，原先基础上改动地方全部记录下来，这对于自己来说真的是很有用的事情，或许写着日志的时候，项目中不足的地方也会一并解决。

 

具体谈谈这次项目中看到的哪些不足之处：

     首先，在整个框架设计上，就完全是依据要有功能就实现功能的思路来，结果如何呢，造成了很多代码上的冗余，比如说，在访问数据库上，由于这是一个WPF的窗体应用程序，在窗体后台，直接用上了访问数据库的语句，不是单单的SQL语句，而是实在的数据库访问，连接数据库，CRUD操作，一并封装到了所要的功能中，这里造成了代码的太多冗余，从框架的角度考虑，本应该是SQLHelper的活，却被一个人承包了，UI,BLL,DAL,SQLHelper全部集中在一个里面，真的是不敢想象。代码看完，就在那想，以后的自己真的是不要这样，毕竟现在就有了仇恨，哈哈。

    其次，代码部分的注释是相当少，没有明确的解释，就连命名上也是大打折扣，使用中文拼英的缩写作为部分命名，看着这些东西，唉，心累，代码部分也只是看了我要拓展部分的相关代码，既然出自同一人之手，并且我看的还是整个项目的主干线，想也知道，其它部分的风格应该如出一辙，不管如何，这一次的拓展工程，真的是学到了太多太多，团队合作时，需提前进行规范，框架规范，命名规范，这些真的是很重要，想要一个可以日后维护，拓展轻松的项目，那么开始制定计划的时候就要提前规划好需要的东西，宁可费点时间，也是值得的。

    最后，最想吐槽的一部分就是在于我的拓展需要用到已经搭建好的数据库，但是当我编写访问数据库的方法时，竟然发现，连数据库名字都是中文的，这就尴尬了，一个下午找着解决方案，我天呐，最后的办法居然还是利用原先项目中已经存在的连接数据库语句搞定的，代码也没深究了。