1 前端HTML及JS页面检查
1)、性能考虑
1.IE 中的CSS 选择器（selector）运行缓慢，针对相同对象重复进行CSS 查，建议将第一次查的结果保存到变量中，在以后需要的时候重用即可，不必再重复进行查。如var element = $(“.shoppingcart”)。
2.任何情况下，页面控件都要定义一个id。因为这样选择器会从一个相对末端的DOMNode开始，提高定位检索校验。
3.JavaScript 和XmlHttpRequest 是AJAX 技术的基础，很多JavaScript 框架都提供了非常方便的使用方法，Web 开发人员会充分利用其异步通信优势来实现诸如分页加载等效果，避免对整个页面的操作。通常这种方式被滥用了——过多的信息通过过多的调用来动态访问，例如，在一个显示10 种商品的页面中，开发人员可能想分别加载每种商品的详细信息。这意味着，你需要和服务器端进行10 次交流才能得到全部信息，也会对后台系统产生压力。建议，在这种情况下，把10 次调用合并成1 次来减少通信压力。
4.JavaScript 文件过多带来两个问题：一是浏览器在加载这些文件时需要通过JavaScript 引擎切换上下文运行环境，二是因为下载文件而带来额外的网络通信。解决方法，建议减少JavaScript 文件数量。
2)、js代码规范
1.js文件命名，每个js文件与一个Html页面对应，内容包括该页面上的处理。文件名与该Html页面名字相同，使用英文，首字母大写。如：页面为“View1.html”，
那么与之对应的js文件则为“View1.js”。这样方便查文件，使程序结构清晰，易于代码维护。
2.文件结构，文件夹名使用英文，字母小写。公用Js文件统一放到工程根目录的/js目录下，各模块/js子目录与之对应的html文件目录保持一致，即/js目录与html目录相对应。目的为了便于文件的管理，避免所有js文件都在一个目录下，造成混乱。
3.建议采用面向对象方式进行javascript编码，如下两种常见方式：
（构造函数方式），封装比较好，但开销比较大
（构造函数/原型方式），封装不好，但开销比较少
4.在Javascript中，变量不是全局范围的就是函数范围的，使用"var"关键词将是保持变量简洁明了的关键。当声明一个或者是全局或者是函数级（function-level）的变量，需总是前置"var"关键词。
5.采用Json方式，定义常量及各种词汇列表。如
3)、JQuery代码规范
1、等价、不等价的使用
尽量使用严格的等价判断符=== ，尽量不用== ；不等价判断符号!== , 不用!=
3、字符串定义
关于js中定义字符串时，统一使用双引号，而非单引号。
var name = “xiaoming”; // 正确
var name = ‘xiaoming’; // 错误
2 后端Java代码检查
1)、性能考虑
1、尽量减少查询数据库次数，不要在循环中打开数据库。
2、查询数据参数维护类的数据时，使用配置了缓存的方法，从内存中取数据。
3、字符串拼接的时候，杜绝使用String + String + …, 而是使用StringBuffer对象进行字符串对象拼接。
2)、设计考虑
1、设计六大原则，大家做设计是一定要经常对照一下，你的设计是否做了？（当然原则是死，我们要灵活运用）
OCP（开闭原则，对扩展开放，对修改关闭，总原则）
OCP原则就是在不修改源代码的情况下，设计方案能适应于各种扩展的需求（当然这是最理想的情况）。这是一个愿景性质的原则，如果系统能够达到OCP 原则描述的情形就比较理想了，对扩展开放、对修改关闭，即，不修改原有代码即可完成对系统的扩展
OCP原则还可表述为“对可变性的封装”原则。“到一个系统的可变因素，将它封装起来。”一个可变性因素，不应该被散落在各个角落，而应该被封装到一个对象中。一种可变性因素，不应该与另一种可变性因素混和在一起，而应各自独立开。
做到OCP有两点：抽象、对可变性封装。
json检查单一职责原则（SRP）
一个类，应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职
责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。我们可能只需要复用该类的某一个职责，但这个职责跟其它职责耦合在了一起，很难分离出来。
是接口一定要做到单一职责，类设计尽量只有一个原因引起变化
里氏代换原则（LSP）
任何基类可以出现的地方，子类一定可以出现（反过来不成立），用来指导我们如何去构建一个extends(继承、派生)结构。
子类与父类的关系必须是is-A，即，子类必须在任何场合都敢于大声宣称自己起码(至少)是一个父类。比如，假设某类结构，“男人”、“女人”从“人”派生出来，看起来就是满足里氏代换原则的，因为无论“男人”还是“女人”，在任何场合都是“人”。
依赖倒换原则（DIP）
要依赖于抽象，不要依赖于具体实现。DIP跟另一种说法含义相近：面向接口编程。
具体地指导我们对抽象类(接口)、实现类的使用，依赖于抽象的实体(interface/abstract class)，才能够
更具有可插入性(但凡实现既有接口的实现类实例都可以在依赖此接口的地方以此接口实例的角插入进来)，更容易满足OCP原则(抽象的层次不变化、实现的层次由于使用不同的类来封装不同的变化，于是可以在增加新类作为扩展的同时不需要修改已有实现类)。
接口隔离原则（ISP）
应当为客户端尽可能小的单独的接口，而不要提供大的总接口。要求类之间的接口更加狭窄，更加确切、更加合身地封装变化。比如，A/B接口可能在大多数情况下都由同一个实现类提供，但某些情况下，B接口都有些实现类是没有意义的，这时候就需要把A/B分开作为两个接口，某些类实现全部A/B接口、某些类仅实现A接口。A/B单独变化，于是把A/B单独封装，接口隔离
合成/聚合复用原则（CARP）
要尽量使用合成/聚合，而不是继承关系达到目的。复用角度来说：“合成/聚合复用”比“继承”复用灵活。前者是动态复用（因而具有可插入性）、后者是静态复用（编译时就固定了复用关系），而且后者的复用有“不支持多重继承”的限制
迪米特法则（LoD）
一个软件实体尽当尽可能少的与其他软件实体发生相互作用。通俗讲只与你直接的朋友通信、不要跟“陌
生人”说话，要求类之间的接口应该发生在哪些类之间，不应该发生在哪些类之间。帮助我们解开类之间的耦合。
2、一个表，尽量只有一个Dao进行操作，其他需要进行访问的类，都应通过这个Dao进行操作。
3、一个类只有一个职责，功能职责过多需要考虑折分，一个方法一般只实现一个功能，职责清晰也方便代码复用。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。