公众号|松花皮蛋的黑板报|一周的闪念胶囊,总有一个能帮助到你
松花皮蛋的黑板报
  • 分享在京东工作的技术感悟,还有JAVA技术和业内最佳实践,大部分都是务实的、能看懂的、可复现的

扫一扫
关注公众号

一周的闪念胶囊,总有一个能帮助到你

博客首页文章列表 松花皮蛋me 2019-12-19 22:58

1、不管是做需求还是测试,都应该考虑整个链路,确保兼容性或者其他模块不受影响。比如内容创作改动,应该考虑到审核侧、内容分发侧是否正常。


2、需求一定要经过测试。不要站在自己的角度,以为测试人员无法测试某种场景。因为方法总比困难多,比如可以把链路当中修改的点单独拎出来进行对比测试。还要多提一点的是,尽量在代码修改处添加日记,确保测试能覆盖到。


3、输出日记时也要避免空指针异常。如果在业务逻辑中不会出现空指针异常,却在输出日记时抛异常,那真的是冤大头了。


4、批量回刷或者删数据有风险,特别是无法恢复的物理硬删除。所以此类场景应该由用户主动触发,而不是借助定时任务批量执行。


5、数据和操作行为应该足够方便溯源。比如图片上传、批量删除数据。


6、代码上线时间也应该当成需求时间。当团队严格控制代码上线流程,比如技术方案评审、代码评审、提测、灰度发布、线上监控,你就会发现上线成本还是很高的。所以,管理好开发队列变得很重要。而秘决在于,质量优先,效率第二。


7、上游依赖接口检查。不只是要检查可用,还要检查准确度和质量。比如每页返回的数据量是否正常、返回的数据是否满足合规性和可用性。


8、避免过度设计。某些历史的实体POJO类的字段类型千奇百怪,可能是包装类Integer,也可能是基本类型Int,那么在MyBatis框架中使用xml定义一个大而全的SQL,比如使用<if test=”picNum !=null”>来拼接Update方法,很容易将不需要处理的数据清空。当然根本原因是POJO定义的问题,不过这是历史原因了,此时再修改它里面的字段类型,成本很高。所以,此时最好的方式是,新增的方法只更新它需要的,不要过度设计,不要急着考虑通用性。


9、开闭原则。它的意思是对扩展开放,对修改关闭。这个设计原则其实我们每天都在接触,比如方法入参定义为实体对象,当需要新增一个参数时无需修改参数列表,只需要在实体类中新增一个字体即可。这个原则的作用是应对变化的时候,还能够保证系统的稳定性。


10、依赖倒置原则。上游依赖属于原子类,具体细节不应该混杂在业务代码中。那样代码复用性差,而且当该业务方法出问题时,不能直接判断是否是业务代码的缺陷还是某个上游依赖的缺陷。甚至上游接口需要升级切换时,使用到它的都需要进行翻新,得不偿失。所以上游接口尽量抽象出来并且添加相应监控。


11、增强系统健壮性。主动检测不支持的情况并抛出异常,避免系统产生不可预期的结果,比如首先进行参数校验再处理业务。很简单的操作,但是可以有效增强系统的健壮性。