架构的PK

经典的软件开发生命周期
分析——设计——编码——测试
将产品质量的责任全部推给了测试人员。后来有人统计bug是如何产生的时候惊讶的发现，真正是编码者的原因产生的bug占的比例还不超过10%，大部分是在需求和设计阶段产生的。

于是有聪明的公司做了过程上的调整，叫做 架构优先原则
分析——需求评审——设计—— 设计评审——编码——测试
需求评审我们不管，那是产品经理或者客户的事情，就谈一谈设计评审

首先是成立了一个 架构组，架构组的成员都是自己部门或者其他部门公认的专家，曾经有过相当多的实际业绩。
评审的内容有固定的模板，主要包括以下一些

• 系统的拓扑结构（webapp，service，存储，合作方服务等等）
• 系统的主要流程（是否合理，如果与合作方有交互是否行业通用标准，是否有安全漏洞）
• 主要数据结构（DB，缓存等等）
• 接口设计（协议，与合作方的接口）
• 性能考虑（吞吐量，支持在线量，支持PV量等等）
• 高可用性考虑（即使到机房拔掉半数机器的电源，业务还能正常运行）
• 可平行扩展性考虑（程序可以扩展，存储可以扩展）
• 安全性考虑（系统安全，业务安全，中国特色的内容安全）
• 方便运维的考虑（产品的开发和运维最终是分离的）
• 管理后台的易用性
• 日志设计
• 统计的指标
• 可能出现的问题和应急措施

评审过程就是一个PK的过程，提交者不要怕权威，架构师也不是意见一致，都是摆事实，讲道理，一般经过这样一轮PK，开发的风险是可以大大降低，很少会出现后期推倒重来的。最后的结果大家都不要加班救火～～