程序开发必备的六个信条
信条一：防火胜于救火
设计时充分考虑各种可能的出错场景，进行防御，设计文档一定要有引用，用于证明设计的可行性，如果没有引用必须给出科学的证明。
开发原则
review
代码/设计审核
单元测试审核
通用规则优先于特例
考虑极端情况
集合只增不删
循环次数过多
连接/内存过高
计算量过大
预设异常容错
外部依赖出错不会整体出错
考虑处理三方库异常
考虑外部 API 是否有阻塞 I/O 行为
新功能配置依赖
强依赖以文件存放
更改使数据不兼容的配置
弱依赖以 ZK 存放
无论配置有无,程序都可良好运行
灰度原则
强制军规
代码正式上线前，必须灰度一个高峰期；
评估功能灰度开关
前期发布默认开关关闭
后期发布默认开关打开
未来需持续跟踪该开关
兼容性
和老功能保持数据/接口兼容
其他提高警惕的行为
修改发布面板参数
发布扩容机器
信条二：可运维优先，不做不可运维的产品
可运维意味着：简单，可快速恢复，抽象，自动化，自助化
消除手工操作
脚本化
上下线
更改配置信息
熔断
开关端口
操作可追溯 ：变更历史可查看/检索
系统高可用
出错可恢复 ：敏感变更操作可回滚
容量可扩展
一键容量切换
一键新机器业务部署
系统可监控告警
异常流量监控
单点整体流量下降
多节点流量下降
单点大量请求出错
节点负载监控
集群容量检测告警
机器监控(运维)告警
业务异常监控
心跳失败
SQL 变慢，DB 异常
节点内部异常监控
ZK 异常；
端口绑定异常
不间断升级异常
信条三：做产品而不只是做技术
产品要有用户体验,要有文档,界面,要有 SLA，Work backward。
开发任何一个新功能时：以客户为出发点
首先为客户准备三个文档：press release,user manual,FAQ
每个不超过两页 A4 纸且不能有图片
产品输出
优先满足业务需求
多以使用场景考虑
少以技术实现考虑
以用户角度考虑使用场景
人性化界面
简化外部接口,把复杂留给自己
减少用户干扰
考虑接口兼容性
尽少暴露内部细节
尽量以惯例解释, 减少 surprise
避免用户误用
减少低级错误
预设用户误用场景并尽量避免之
信条四：效率优于速度
宁可延期做一个质量有保证的产品，也不要为了快速上线做一个质量差的产品。线上 bug，不好的体验会导致客户流失，造成更大的损失，得不偿失。
质量保证
质量优先于速度
工时评估
代码质量评估
迭代开发
测试保障
测试重要性不亚于代码
单元测试
功能测试
压力测试
稳定性测试
回归测试
信条五：简单而不简陋
简单：功能齐备，但是支持性的工作很少
简陋：用 hack,working around 的方式完成一项功能，产品文档,设计文档复杂,费解,自己都整不明白
对代码来说：
简陋级别: 可编译，可读（逻辑清晰）。
简单级别 :可测试(有单元测试,且不 mock 大多场景)
可维护: (加需求功能不改变框架)
可重用: (以 lib 库对方式对外输出)
自动化
脚本化代替手工操作
线上操作依赖脚本
人工负责决策是否操作
脚本负责实际操作
通用化
通用规则优于特殊规则
减少代码和功能上难以理解的 surprise
减少未经实践,只走捷径的奇技淫巧
避免重复造轮子
信条六：数字说话
用真实有效的数字来支持各种决策
数据支撑
服务等级协议
系统稳定性/可用性的高低
事故损失的大小
系统优化程度
节点性能(QPS,响应时间)
资源利用率(CPU/内存等)
数据预测
容量评估
根据业务流量增长预测未来
根据节点负载预测所需资源数目
推荐阅读：
版权声明: 本文为 InfoQ 作者【硬核编程】的原创文章。
原文链接:【http://xie.infoq.cn/article/a01e0e2fd92690c4f472b93de】。文章转载请联系作者。
还未添加个人签名 2017.10.20 加入
一线互联网公司技术专家，擅长架构，中间件开发等
评论