让每一个项目都能给我们点什么

        每一个项目，不论成功还是失败，都将是一笔宝贵的财富，我们都可以从中学到很多的东西。成功给我们的是成功的经验，失败给我们的是避免同样失败的教训。不管怎么样，关键是进行项目总结，让每一个项目都能给我们点什么。  

       我就业后参加了一些项目，从小到大，从无序到有序。但每一个项目，不论大小，都会在项目结束进行总结，主要是限于设计和技术，找出在开发过程中的问题，每一次总结都感觉是一次收获。（自我感觉）

       刚开始的项目，因为并不是很大，而且参与项目的人通常就是一两个，谈不上设计，谈不上评审，引用大师的话就是“代码就是设计”。所以，项目的目标就是实现功能。再加上刚开始做项目，时间催的紧，没有经验，信心不足，导致畏首畏尾，所以从系统的设计到代码的实现都是惨不忍睹。所学的面向对象的知识，基本上只使用了封装和继承，面向对象的开发最后成了面向过程的开发。更可怕的是，因为没有抽象，很多功能类似又稍有不同的代码在项目中大量地存在着，有时候为了修改相同的部分，不得不找到所有出现的地方，一个个的修改，而且有时候这个地方修改后不清楚会不会影响其他地方。当时也考虑不了那么多，代码的可重用性及可维护性极差。幸好，项目相对比较小，功能需求相对稳定，所以改动的地方也不是很多，改动量也不大。最后，项目提交通过了。虽说项目改动比较少，但每次改动后都会涉及到主要流程控制的修改和调试，也是很烦的。

       经过这些小项目后，以及看了一些大师们设计方面的文章，开始有了软件设计的想法，最直接的感觉大量的重复代码造成了维护的困难，同时系统设计的好坏也影响着项目的重用和维护。那么，对这部分的代码需要进行重构，同一功能的实现项目中只能出现一个实现体，而不能出现多个类似的实现；还有就是需要将项目中通用的功能进行封装，比如加密、信件格式的转换等完全以进行封装成组件，以后所有的项目只要使用到这些功能都可以调用这些组件， 而不是每个项目都要去实现。这样不仅减小了维护的工作量，也提高了开发和维护的效率。

      于是，我将很多模块中都调用的功能模块封装起来，既包括了基础功能（如Socket通信）的封装，也包括了业务中常用的功能（如信件的转换）的封装。以后不论是项目，还是维护的项目，我都会使用这些封装的模块。当然，也只是最基础的代码复用。并且，项目中类似功能的方法尽量只出现在一个地方，就算有不同，也会抽象出共有部分的代码，减少维护的代码和降低出错的可能性。

      后来，开始接触相对较大的项目，不过还是一个人负责我那块的东西。根据以前积累的一些经验，实现基本的代码重用。好了，项目功能并没有花多长时间实现了，自我感觉还可以吧，至少功能实现了，而且功能也进行了封装。（呵呵，目光短浅啊。） 但是，随着项目的增加，需求的变化和新增几率也随着增大。修改功能还好说，只是修改功能方法，不会涉及到其他地方。但是如果是新增功能，那就要从界面控制、配置文件修改，到主要业务控制，到功能函数的实现，都需要新增，改动涉及的地方也是很多啊。刚开始感觉这样维护无所谓，后来发现很麻烦，老是这么改，一改就改了个遍，何时才算结束啊。就算需求变动没完没了，那能不能每次的改动不这么大呢。在公司，没有人带，更没有人指方向，全都靠自己去摸索，想了一些方法，都不怎么爽，这个过程花了很长时间。

     工作一年后，在一次与一个刚进公司的同事的交谈中，我提出了我的困惑，同事给我介绍了设计模式。于是，从网上查了一些资料，因为设计层次和理解水平没有到一定的高度，读完后都没能理解。最后，因为读的很费劲，而且一个更大的项目来了，所以，只能暂时搁置了。后来的两年，也就是设计模式的学习过程了，学习的精力在项目的压力中一点点的消磨，学的那是个苦啊。不过还好，从刚开始接触设计模式的痛苦，到现在设计中都尝试着使用设计模式，感受着设计模式在设计中带来的震撼。（不过还是菜鸟）

     我要感谢那位同事，是他让我了解了设计模式。同时，也要感谢所经历过的每一个项目。是它们给了我经验和教训，让我慢慢地成长。还是那句话：让每一个项目都能给我们点什么！

      时间仓促，文笔又差，写的比较短浅，见谅。