程序的健壮性与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都要花费额外时间完成这项工作，所以排期方面要考虑