单元测试和个人技能成长

最近看到个对单元测试的看法:

单元测试是预防错误的主要手段。如果一个团队所在的领域对错误的容忍度高,而其市场需要 move fast,就 (暂时) 不用有单元测试;反之,若所在领域对错误容忍度低,那么重视实践单元测试的团队会取得优势。

然而,单元测试并不是「预防错误的主要手段」。首先单元测试并非全部测试。除了单元测试,还有组件测试,系统整体的人工测试,自动化的整体测试等等。团队资源应该在所有测试类型间合理分配,而不是预设单元测试最重要。其次,错误预防的关键点在于 escape to user 而不是 commit to repo。也就是说很多非测试技术,比如 Git 的合理 branching 策略和 back tracking 也可以更合理的成本降低错误。从最终结果的角度来看,若先不考虑 escape to user 造成的公开影响和修复 bug 的成本,系统整体的人工测试就可以发现所有错误。如果把软件开发的概念套用在流程设计上,整体人工测试是开发流程的基本功能,而其它方法都是开发流程的「优化」。那么可以想到关于优化的老话:「Premature optimization is the source of all evil.」 优化的前提是 profiling。制定流程应该把「只有整体人工测试」作为缺省情况,根据执行的实际结果谨慎加入其它技术。

说到这里谈谈这篇 blog 的真正重点。我之前涉及单元测试讨论的 blog 有好几篇,所以并不想再写一篇去扩展甚至重复以前的观点。这里我想到的不是分析的结论,而是分析这些看法的手段。最开始引用的看法把缺乏单元测试的视为一种「技术债务」而不是可以在团队中合理分析执行的长期策略。这是个错误的归类,而由这个错误可以想到技术人员如何思考自己的技能成长。

现今是「纯技术」有所贬值的时代。当年 Paul Graham 用 Lisp 作出网站卖得 5000 万美元而鼓吹了很久 Lisp。但回过头去看 Lisp 已没那么神奇。很多通用技术已经被成熟的模块甚至 AI 部分取代。技术人员需要思考的是有什么和技术密切相关但又不是「纯技术」的东西,可以帮助发展个人技能。对「技术债务」的理解和评估恰恰是技术人员可以体现不可替代性的重要项目。认清团队技术储备中哪些是资产,哪些是债务,如何合理的偿还或者重组技术债务,这些是和管理财务债务一样重要的技能。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

You are commenting using your WordPress.com account. Log Out /  更改 )

Google photo

You are commenting using your Google account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

Connecting to %s


%d 博主赞过: