系统设计规范化解决了什么问题@H_301_6@(一@H_301_6@)

大家好@H_301_6@,今天总结下我从事开发工作这几年里@H_301_6@,对于项目规范化的一点想法和感触@H_301_6@.

在笔者心里@H_301_6@,规范是为了解决问题而存在的@H_301_6@,某些规范都是为了对应问题而存在的@H_301_6@.所以只要是能解决问题的文档@H_301_6@,声明都是规范@H_301_6@.

@H_301_6@在某时开始设计系统@H_301_6@,带人做系统的时候@H_301_6@.笔者考虑到了如下几个问题@H_301_6@:

1. 需要将系统设计成模块化流程化.

2. 需要将系统具有共性的操作抽离成统一的接口

3. 需要为系统设计一套代码规范

4. 需要将系统设计的更能满足未来的需求

@H_301_6@

问题@H_301_6@1解决了哪些问题：

• 对于系统目录:笔者之前遇到过一些项目，再熟悉系统时吃了些苦头，花费了很多时间去研究,最糟糕的是在系统环境搭建启动的时候都有很多困难。10个工程可能有10种的搭建方式，所以如果你的项目构建比较另类，请提供一份系统目录搭建描述。如果你不想花时间去写文档，可以使用很多人都在用的MAVEN构建工程,这样每个开发人员都能快速熟悉工程，搭建工程环境。

• 对于系统层级:如果需要你去维护一个系统,jsp中掺杂了代码,又一个类有一千行,一个函数有几百行,马上就感到眩晕感觉天要塌下来了.划分好各个层级的职能可以有效的减少这种情况的发生,actin/web只负责请求转发,service只负责业务处理,dao只负责数据库操作,jsp只负责页面展示,domain只负责对象关系映射,util只负责提供工具类,constant只负责提供常量,model只负责页面信息对象的传递.这样各层只负责指定的功能,一个流程化的开发模式就形成了.减少维护难度,降低出错的概率.

问题@H_301_6@2解决了哪些问题：

• 减少开发人员工作量:在一个系统中有很可以封装的东西,比如对数据库的操作,笔者将所有的对数据的操作方法全封装到一个接口类里,并提供了一个抽象类实现该接口.又或者对于jsp页面中提供统一的前端校验js文件,为service层提供默认的事务隔离级别与传播机制.这样就减少各开发人员的工作量.

• 减少开发人员重复性工作:如上.

@H_301_6@

问题@H_301_6@3解决了哪些问题

• 便于系统的全局控制:比如方法名是按照规范来的,那在事务控制中,由于要对不同的方法名设置不同的控制级别,那就会非常方便.又比如将来要实现读写分离,需要根据方法名选择不同的数据源,方法名规范就非常方便,否则就需要大量的改动.

• 节省时间:看到一个变量名就知道类型,看到方法名就能知道功能,看到类名就知道代表的事务,这样可以节省大量的时间.

• 笔者在2012年总结的一份规范文档博客:http://www.jb51.cc/article/p-mgljxado-ht.html.本人的联系方式cuiyaonan2000@163.com

@H_301_6@

问题@H_301_6@4解决了哪些问题

• 技术上的需求:做系统设计需要提前想到开发人员,将来在开发过程中可能遇到的问题,需要提前想到解决方案,比如需要webservice,可以提供cxf实现方案.又或者需要进行前台/后台的数据校验证,可以提前提供jquery validate实现方式.需要进行系统间的系统交互可以使用jsm实现方案.

• 性能上的需求:随着项目经验的增加,笔者发现如果需要提升项目性能,比如加入页面缓存,数据缓存,读写分离,全文检索,业务拆分,集群化,都会改动系统的框架.如果前期设计的不好,就需要相当于重做.所以建议项目在开始设计的时候就需要考虑到项目将来的性能问题.

@H_301_6@

总体来说笔者想到这些问题的原因有@H_301_6@3方面@H_301_6@.

1. 让开发人员用最少的时间熟悉系统,了解系统.

2. 增强系统的可维护性,扩展性.

3. 增加系统的性能.