摘要:这严重地影响了开发的效率。参数校验所以我们的公共方法既要写注释,让人能看懂,也要对每一个传入的参数表示怀疑。公共方法随手一条提示信息,节约程序员的万千时间。
公共方法
当我们写一些公共组件或方法时,我们可能需要接收外部的参数,但是,我们并不总能保证我们的注释是完全能让他人理解的。
/** * 获取所有考评员信息 * @param {district} 区域 * @param {department} 部门 * @param {discipline} 学科 */ self.getAllExaminerInfoByDistrictAndDepartmentAndDiscipline = function(district, department, discipline) { // 设置请求参数 var params = { districtId: district.id, departmentId: department.id, disciplineId: discipline.id }; // 请求后台接口,返回 return $http.get(baseUrl, { params: params }); };错误使用
就像上面的这段代码,属于在Service中的公共方法,乍一看,可能看不出什么错误,我们注释写得好好的,我要个什么什么对象,用的时候传给我就好了。
编码常有失误,如果他人不小心传了个undefined进来。
var params = { districtId: district.id, departmentId: department.id, disciplineId: discipline.id };
然后我们这段代码就是从undefined中获取属性,就会抛出错误。
当然,以软件工程师的骄傲,他不是先考虑自己哪里写错了,而是认为你这个公共的方法有问题,然后找写这个方法的人进行激烈地讨论,浪费了半个小时发现原来是参数传错了。这严重地影响了开发的效率。
参数校验所以我们的公共方法既要写注释,让人能看懂,也要对每一个传入的参数表示“怀疑”。
公共方法,可能会有很多人使用,为了减少参数传错造成的时间浪费,所以我们需要在我们的逻辑真正地执行之前,对传入的参数进行校验。
我们可以对这几个传入的区域、部门、学科对象进行校验。
if (!district) { throw "未接收到区域信息"; }
这样,如果我们没有传该参数或传入一个undefined,我们的控制台就会报错,提示开发者“未接收到区域信息”。
这样,开发者就能准确而快速地定位错误,自己这个方法用错了,并且根据提示,是自己的区域信息传错了,这就减少了互相争论与讲解的成本。
公共方法随手throw一条提示信息,节约程序员debug的万千时间。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/107794.html
摘要:是今年一定要学的东西这两年页面上用的三方组件多了,写的少了,的一些属性不太记得了,针对的学习计划有两个参照的样式进行学习参照的组件样式,学习如何处理样式与组件之间的关系,规范自己的写法。 磕磕绊绊工作有几年了,前端界几乎每天都有新名词,令人眼花缭乱,目瞪狗呆。这两年一直在外包工作,业务写的多些,对js的基础掌握的还不是很到位。最近深感技术嗅觉迟钝,虽然平时也有看书学习,更多的时候都是断...
摘要:笔者对微服务系统的观点是,我们从单体系统向微服务系统改造的过程中,需要认真思考什么阶段使用微服务。此外,为了解决服务部署,我们可以考虑通过滚动发布来实现服务的无中断。事实上,微服务保证其服务的整体可用性。 原文地址:梁桂钊的博客博客地址:http://blog.720ui.com 欢迎关注公众号:「服务端思维」。一群同频者,一起成长,一起精进,打破认知的局限性。 一、逃离单体系统,...
阅读 2447·2021-11-23 09:51
阅读 1869·2021-10-13 09:40
阅读 1376·2021-09-30 10:01
阅读 592·2021-09-26 09:46
阅读 2239·2021-09-23 11:55
阅读 1390·2021-09-10 10:51
阅读 2245·2021-09-09 09:33
阅读 2229·2019-08-29 17:25