Debug点滴

对于大多数团队来说，第一需要的不是架构师，而是一个debug大师。

一个产品的高性能，高扩展性，确实是产品结构(不是代码结构)决定的，但架构这种东西不是设计出来的，是维护和优化出来的。所有架构先行框架先行的研发团队最后都要和业务需求打架。如果此次项目和上一个项目相同，先行的不是架构和框架而是重构。第一需要不是架构师还有一个拿不上台面的原因是，90%的团队聘不起架构师。

大多数研发团队面临的问题是反复修改的功能点，低水平程序员留下的无文档代码，仅仅出现在生产环境中的bug和无从下手的性能问题。面对这些问题，聘一个架构师是不灵的。

debug第一前提是熟悉产品。客户端和服务器是CS/BS，通信协议是阻塞的还是非阻塞的，计算数据是来自客户端的输入，还是来自其他入口，计算是被用户驱动的还是有其他驱动方式，有没有数据共享等等。

bug产生：0数据不对，导致计算结果错误；1路径分支覆盖不全，导致逻辑丢失或错误；2竞争条件下的数据被多次写，导致计算错误；3基于状态的逻辑，常常发生状态跳转错误。

一个常用的技巧是输出stackdump能够很明确的展示程序路径，选择当前程序路径的原因一般就这个bug的原因。

对于仅仅出现的生产环境中的bug，首先查看error日志的stackdump，找到bug的起点。这要求研发团队要有生产环境的代码副本，否则statckdump没有意义。有时候stackdump也无法提供有效信息，要依靠经验和回头再读代码了。

对于性能的优化不是猜的，是牢牢建立的测试基础上的。但性能测试测什么，怎么测才能准确反映程序的负载，这就要看计数老大的功力了。