经验与教训

虽然我们平时说“成功的经验，失败的教训”，但是有时要区分两者并不容易，因为有些事情虽称不上成功，却也不至于失败。故请允许我暂时将其混成一谈。

#1 分而治之（divide and conquer），重构代码

在项目中当复杂业务逻辑变得复杂时，有的程序员没有胆量去重构旧代码，而取用保守方式，拼命地添加新的代码。这样做的后果就是会导致代码量激增，难于维护。“分而治之”可以帮助我们理清复杂的业务，提高代码可重用性。所以任何时候，都不要忘记这个程序基本的方法学。

#2 避免在程序中保存状态（State）

有的程序员偏爱全局类型变量，而忽略通过参数和返回值进行共享数据。状态对程序来说其实就是一种负担，在多线程和分布式的环境下更是如此。还有，编程的另一原则是尽量缩小变量有效范围（Scope），大家可以参考一下《Code Complete》中一些建议。

另外，要小心使用静态变量，切记要通过final关键字和Collections.unmodifiableXxxx方法（对于集合类型）使其不可变。如果需要在对象之间共享状态，可以考虑使用HttpSession或分布式的缓存如（JBoss Cache等）。

#3 设计好你的业务对象模型

我看过很多项目的代码中其大量存在所谓的PO（Persistent Object）用于ORM和VO（Value Object）或称为DTO（Data Transfer Object）用于程序之间传输数据，更有甚者，这两种对象只是相差一两个属性。这样的做法的弊端是代码中充斥大量林林总总的copyXxx的方法，导致程序出现一些不可预期的行为。

其实，通过对业务对象分析，尤其是对象之间的关系建立，上述问题中的大部分都是可以避免的。

 

项目的第一阶段进入到后期测试过程中，发现了很多bug，在修改bug 的过程中，感到很累，但同时觉得这段时期却是收获最多的时候，下面我将整理后的项目管理与技术经验做一下总结，愿大家多多指教！
项目运作方面：
1、在模块功能已经基本完成的情况下添加新的功能时，一定要考虑周全，因为这时前面已经写了很多代码，加入新的功能后，对先前代码造成的影响是不可预知的，必要时需要大家（特别是编码人员）进行开会讨论一下。
2、在项目的遇到的问题，应随时记录，以供整理后，作为自己的经验积累。
3、在项目组之间应多多加强交流，遇到的问题，解决的问题都是大家共同的经验积累。
4、需求文档与设计文档一定要与代码同步，为与程序员沟通与交流，提供一个依据。
5、在设计模块功能时，要考虑动作的整个流程，从开始到结束，注重“用户体验”。
6、注意不同浏览器之间的差别。
7、对显示的控制（包含极限）。

 

 


文档:
1,需求分析一定要透彻,不仅要了解所需的,还要有详尽的文档,包括需求文档,数据库文档(表名,字段名和它们的属性及表达意思),部署文档;
2,开发过程中,对一些常见到环节最好进行记录
3,对项目开发,测试中的错误要进行记录,包括错误提示,解决方法;
4,项目结束后,要用使用文档,包括安装,运行平台及环境,使用中常见问题解决方案,以及操作说明;

框架构造:
日期控件;验证方式;分页操作;加密机制;上传下载;树状菜单;级联菜单;权限管理;定时调度;远程调用;ajax框架;

项目测试:
测试时一定要准备好测试的数据,并整理成相应当sql文件,以便能随时测试以及测试数据的清除,这样在开发中就会避免一些不必要的因数据不完整而出现的问题;

要求:
开发中用到版本控制器,要求每次修改文件时先从服务器上更新一下才修改,提交时要有注释说明