程序的健壮性与codereview

程序的健壮性与codereview

功能分类:操作类,查询类
健壮性:尽量少的产生自己预料之外的结果(并发导致订单重复发放)
codereview:代码评审

一、正确性

程序按照规定流程加以执行的能力

影响程序正确性的因素

1、 没有前置状态判定

2、 没有遵守“受理—处理—关闭”模型

3、 没有遵守“申请—审批—善后—完成”模型

4、 数据库复制造成数据延迟(补储管理从slave取数据)

前置状态判定

未被审核的订单不能发放

“受理—处理—关闭”模型

“受理—处理—关闭”模型
Accept/Handling/Close
可以避免任务被多次执行!

1.加锁,加锁成功的进程进行处理,其余返回错误 update status = 'locked'
2.进行处理
3.解锁
注意:加完锁后任意一步出异常应回滚数据并解锁
也可通过定时脚本处理错误数据,如当前状态是locked且最后更新时间在半个小时前(认为超过半个小时还没有处理完成的为错误数据)

“申请—审批—善后—完成”模型

Request/Approval/Handling/Close

二、健壮性

健壮性(robustness),这是衡量一个系统从各种出错条件下恢复能力的一种测度。

两个角度:
    1.系统对错误的输入数据的承受能力
    2.系统内部出现问题,能否最大限度的自主恢复

错误数据

数据类型出错:前后端对接出错或者恶意伪造请求
数据值出错:程序内编写验证代码
误操作:产品需要考虑操作流程,支持修复误操作

系统内部出现问题

队列停止,解封脚本
脚本的断点续传,有错即中断,下次从中断的地方继续,或是从上次的开始的地方重新开始(需要对应的去重处理)

涉及文件上传之类 使用try catch 防止无用文件占据磁盘空间
涉及数据库状态改变使用数据库事务

程序健壮性注意点

即使终止执行,也要准确/无歧义的向用户展示全面的错误信息
错误信息有助于进行debug
例如:多个请求操作同一笔订单,没有抢到锁的请求应该返回 该订单正在被其他用户操作

健壮性原则:
    总是假定用户恶意、假定自己的代码可能失败
    返回给用户的错误提示信息要详细、准确、无歧义
    对别人宽容点,对自己狠一点(对自己的代码要保守,对用户的行为要开放)
面向健壮性编程的原则:
    封闭实现细节,限定用户的恶意行为
    考虑极端情况,没有“不可能”

三、方法总结

1. 前置状态判定
2. “受理—处理—关闭”模型来防止并发
3. 脚本是否能自主恢复数据
4. 必要情况下的Try…Catch…处理   越无法挽回的操作放在越后面
5. 异常数据检验    超过解封时间且未解封
6. codereview 被review了的代码在一定程度上会有更高的准确性和执行效率。从长远角度看,后期维护和优化的时间也会少很多。

四、code review

1.代码规范:明确Coding规则

建个规范文档,能明确定下来的规范就写上去,大家遵守
    功能优化/修改 排期的时候应该考虑到将旧代码修改得符合规范,开发主动提出
建个文档,较为重要的坑写上,要有筛选性,避免文档过长
    什么写法可能导致性能低下?
    哪个接口要慎用?
    哪些设计方式需要规避?

2.功能文档编写

开发写一个功能要做两件事:代码及文档
文档包含:功能流程说明,坑点注意点,前后端对接,心得
要求:代码评审者能直接通过文档和代码,了解整个功能的情况
好处:规避单人想不到的BUG点,有多人了解功能全貌,有详细文档作为后续参考

3.review的范围与reviewer职能

重要的功能进行review  重要性: 核心功能(基础设施,数据源)> 操作类功能 > 查询类功能
reviewer:更多的是建议提出者,不强制,建议是否采用看产品与实际开发人员。要求:了解功能全貌,且已认真阅读代码并提出意见
实际开发者与reviewer都要花费额外时间完成这项工作,所以排期方面要考虑
发布了2 篇原创文章 · 获赞 0 · 访问量 39
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 数字20 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览