记录一下工做半年以后发现的现象和对应的思考。前端
大学毕业以前就知道程序员最头疼的事是维护老项目,尤为是代码质量不好的”屎山”。很幸运的是,工做后遇到的第一个项目就是维护一个屎山,这个项目是庞大复杂系统中的一个模块,因为大版本的更新迭代致使现有功能已没法使用,必须进行从新适配。更幸运的是,领导给了我极大的自由度和很长时间自由发挥。程序员
刚接手时,整个项目真是一团乱麻,定义最主要业务逻辑的类文件有四千行、其中还有一个九百多行的 run 函数,另外还有一半的类在迭代过程当中已经再也不使用可是没有删除。截止到第三轮系统测试、整个项目持续了两个月,全程由我一我的完成,经历了从日志文件和主要代码中倒推出业务逻辑状态机、通读全部源码删除无用部分、调整混杂在一块儿的各层代码、优化代码等过程。下方两张图分别是刚接手是代码扫描结果和目前的代码扫描结果,能够看出来改进了不少。数据库
和没法违背的热力学第二定律同样,我认为只要一个项目还有维护的价值、还在迭代中,它的代码质量就必定会愈来愈差。有如下两个主要缘由:后端
理想状况下,用户会用最主流的浏览器、把正确帐号密码填在正确的位置而后登录。实际状况中,用户可能会用 IE 浏览器、可能会把用户米密码填反中,甚至访问应用的都不是活生生的用户。浏览器
因而,前端须要作表单验证以验证用户的输入,作多浏览器适配以方便用户;然后端须要作入参校验防止后台程序被前端同事和爬虫搞崩。下面是做为一个 Java 语言后端开发者对于一些可能的异常状况的总结。安全
{
、}
、"
、,
等特殊符号进行转义;若是使用 XML 格式须要对用户输入的 <
、>
、"
等特殊符号进行转义。在维护前文提到的项目时,有一个后端接口查询常常超时,致使前端老是弹出“链接超时“的弹窗警告。这是一个统计服务器资源使用量的功能,前端调用接口查询到结果后会将数据渲染为一个折线图,展现过去一段时间内相关资源的占用状况。通过分析,发现该接口调用最耗时的过程是和主控节点进行 MQ 通信进行参数校验。与产品经理沟通后认为这个接口具备调用频繁、入参固定、须要快速返回的特色,而用户使用时关心的是某一时间段的资源占用的变化状况、非特定时间点的瞬时数据。后来解决方案是删除了一大段的条件判断,使用 try-catch 捕获了一个通用异常,发生异常时直接返回上一次的统计结果。服务器
因而可知,参数校验也是一把双刃剑,提升程序可靠性的代价就是执行效率变慢,不少时候须要根据实际状况在性能和安全性之间作出取舍。下面关于参数校验的规范摘自《阿里巴巴 Java 开发手册》。架构
【参考】下列情形,须要进行参数校验:函数
- 调用频次低的方法。
- 执行时间开销很大的方法。此情形中,参数校验时间几乎能够忽略不计,但若是由于参数错误致使中间执行回退、或者错误,那得不偿失。
- 须要极高稳定性和可用性的方法。
- 对外提供的开放接口,不论是RPC/API/HTTP接口。
- 敏感权限入口。
【参考】下列情形,不须要进行参数校验:性能
- 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。
- 底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道,参数错误不太可能到底层才会暴露问题。通常 DAO 层与 Service 层都在同一个应用中,部署在同一台服务器中,因此 DAO 的参数校验,能够省略。
- 被声明成private只会被本身代码所调用的方法,若是可以肯定调用方法的代码传入参数已经作过检查或者确定不会有问题,此时能够不校验参数。