背景
最近一年多在一家toB业务的公司,部门主要做的是建筑行业的招投标业务信息化,希望借助软件来达到“阳光、降本、提效”的目的,我刚入职时大概30多家客户,截止现在已经超过100家,发展势头迅猛,随之而来也暴露出来一个很严重的问题:“质量差,线上反馈多。”
大伙每天疲于处理线上反馈,需求响应缓慢,交付速度跟不上市场节奏,长此下去对团队士气是一种打击也会激化研发和业务的矛盾,鉴于此我们对线上反馈进行了逐个分析、打标,最终的结论是:“大部分反馈是由于客户一些个性化需求导致逻辑冲突,太多的开关充斥在代码中有时会顾此失彼,还有一部分完全是编码层面的低级问题,空指针、跨类型的equals等”,对于需求问题由产品经理和研发经理把控,不接稀里糊涂的需求,对于低级别的编码问题由我牵头出具一些优化方案。
研发流程现状
“开发-》测试-》上线-》线上环境复测”,很简洁的一个流程吧,在当初业务量小、团队小的时候确实没什么问题,响应也快,但是现在人员规模30+的团队还是用这种简单的流程,已然是不合适了,必须增加一些手段来保证开发质量,让一些低级错误扼杀在摇篮中,首当其要的是改善现有的研发流程,增加一些必要的自检和code review,初步改善以后为:“拉取私有分支-》开发-》自测-》提交 Pull Request合流-》组内同事code review-》测试-》上线-》线上环境复测”,在初期确实是收到了一些收益,一些低级别的问题通过“人肉”确实能发现不少,但是到了大家都赶进度的时候就完全靠不住,原因你懂得。
上工具
引用我之前公司CTO的一句话:“靠人终归是靠不住的,最好靠遵循规则的机器。“
人都是有惰性的,靠管理制度来提高研发质量这种精神值得鼓励但是不提倡,找到顺手的工具才是我们的解决之道,将工具和管理制度结合起来,接下来就是我们本篇的重点SpotBugs,一个静态代码扫描工具。
静态代码扫描概念
静态源代码扫描是近年被人提及较多的软件应用安全解决方案之一。它是指在软件工程中,程序员在写好源代码后,无需经过编译器编译,而直接使用一些扫描工具对其进行扫描,找出代码当中存在的一些语义缺陷、安全漏洞的解决方案。静态扫描技术已经从90年代时候的,编码规则匹配这种由编译技术拓展过来的分析技术向程序模拟全路径执行的方向发展,由此,这种模拟执行相对的执行路径比动态执行更多,能够发现很多动态测试难以发现的缺陷。