《有效的单元测试》一2.1 可读的代码才是可维护的代码

2.1 可读的代码才是可维护的代码

昨天我从咨询工作现场回到办公室,与同事谈起他近期要参加的1K大赛。这种比赛是demo party的传统节目——demo party是一种极客聚会,黑客们会带着计算机、睡袋、能量饮料在巨大的舞台上待上整个周末。
从第一届开始,黑客们就互相较劲,在很多人认为过时的硬件上舞弄着疯狂的技巧来制作3D动画。
这种动画的一个典型约束是大小。在我同事要准备的比赛中,其名字1K意味着代码编译为二进制之后的大小不能超过1024字节。
对,你没听错——1024字节。为了把有用的程序装入这么小的空间,参赛者需要使用各种奇技淫巧。例如,一个使代码更紧凑的常见手段是让多个变量使用相同的名字——因为这样代码压缩得更好一些。太疯狂了。
生成的代码也同样疯狂。当他们将代码压缩到1024字节时,源代码已经面目全非了。你几乎认不出是使用了哪种编程语言!它基本上是一个只写(write-only)代码库——一旦开始压缩,你就无法再改变功能,因为你分辨不出要编辑什么,也不知在哪里编辑和如何编辑。
给你一个鲜活的例子体会一下,这是最近JS 1K比赛中实际提交的代码,选用的语言是JavaScript,而它需要装到1024字节内:

当然,这种情形比一般软件公司中的极端情况还要高几个量级。但我们都在工作中见过让人头大的代码。有时我们称这种代码为遗留代码,因为那是从别人那里继承下来并接手维护的——只是它太难维护了,每次试图去理解它都令人头疼。维护这种不可读的代码是一个苦差事,因为我们花了这么大精力去理解我们看到的代码。不仅如此。研究表明,较差的可读性与缺陷密度密切相关。
自动化测试是防止缺陷的有效保护。遗憾的是,自动化测试也是代码,其可读性也很容易变差。难以阅读的代码也就难以测试,导致更难为之编写测试。而且,我们编写的测试还远远达不到优秀的地步,因为我们需要围绕拙劣的结构、难懂的API调用及非测试友好的结构来组织代码。
我们建立的代码可读性(几乎令人咆哮)对代码可维护性具有可怕的影响。那么测试代码的可读性又如何呢?有多大差别,或者有差别吗?我们看个难读的测试代码的通俗示例,如代码清单2.1所示。

这个测试在检查什么?你敢说它很容易理解吗?想象自己是团队里的新人——你要花多久才能明白测试的意图?如果该测试突然失败,你要如何调查代码才能搞清状况?根据我对丑陋代码的感觉,我打赌你立即可以从这个烂测试中识别出一些可以改进的地方——可读性是一个常见的改进方面。

时间: 2024-10-27 02:04:00

《有效的单元测试》一2.1 可读的代码才是可维护的代码的相关文章

《有效的单元测试》一导读

前 言 过去10余年间,Java开发者显著地青睐开发者测试.如今,计算机科学专业的毕业生无人不知自动化单元测试及其在软件开发中的重要性.这个想法很简单--确保我们的代码能工作并且一直能工作--但是该技能需要花很大力气去学习. 编写测试.学习JUnit的测试框架,这些都不难.要真正地掌握编写自动化单元测试实践,需要花大量时间在阅读并改善测试代码上.这种持续的测试重构能够尝试用不同方式来表达意图.组织测试的不同行为.用测试构建各种用到的对象--这才是一种务实的方式,用来自我学习和培养对单元测试的感觉

深入浅出单元测试

一 单元测试概述 工厂在组装一台电视机之前,会对每个元件都进行测试,这,就是单元测试. 其实我们每天都在做单元测试.你写了一个函数,除了极简单的外,总是要执行一下,看看功能是否正常,有时还要想办法输出些数据,如弹出信息窗口什么的,这,也是单元测试,老纳把这种单元测试称为临时单元测试.只进行了临时单元测试的软件,针对代码的测试很不完整,代码覆盖率要超过70%都很困难,未覆盖的代码可能遗留大量的细小的错误,这些错误还会互相影响,当BUG暴露出来的时候难于调试,大幅度提高后期测试和维护成本,也降低了开

单元测试详解

一 单元测试概述 工厂在组装一台电视机之前,会对每个元件都进行测试,这,就是单元测试. 其实我们每天都在做单元测试.你写了一个函数,除了极简单的外,总是要执行一下,看看功能是否正常,有时还要想办法输出些数据,如弹出信息窗口什么的,这,也是单元测试,老纳把这种单元测试称为临时单元测试.只进行了临时单元测试的软件,针对代码的测试很不完整,代码覆盖率要超过70%都很困难,未覆盖的代码可能遗留大量的细小的错误,这些错误还会互相影响,当BUG暴露出来的时候难于调试,大幅度提高后期测试和维护成本,也降低了开

Android开发软件架构思考以及经验总结

一.萌芽 作为一只编程经验并不怎么丰富的程序猿来讲,我一直觉得架构师是一个比较神秘的职业,架构设计就更加的高大上了.经过今年的几个项目,之前曾发文叙述我的从MVC到MVP项目重构实战经验,也曾说过我准备对目前手底下的项目进行重构.但是,前段时间,我改变了我的想法.开发模式的重构,仅仅只是换了一个套路,也许在重构的过程中对业务的逻辑进行了一次梳理,也是在基于前人的代码设计上进行了一些优化.但是,这远远还不够,这不是我理想中的开发场景.在项目开发的过程中,也发现存在许多的问题,但是都是一些零散的问题

关于烂代码的那些事——什么是好代码

最近部门在组织bootcamp,正好我负责培训代码质量部分,在培训课程中让大家花了不少时间去讨论.改进.完善自己的代码.虽然刚毕业的同学对于代码质量都很用心,但最终呈现出来的质量仍然没能达到"十分优秀"的程度. 究其原因,主要是不了解好的代码"应该"是什么样的. 什么是好代码 写代码的第一步是理解什么是好代码.在准备bootcamp的课程的时候,我就为这个问题犯了难,我尝试着用一些精确的定义区分出"优等品"."良品".&quo

关于烂代码的那些事 —— 什么是好代码

最近部门在组织bootcamp,正好我负责培训代码质量部分,在培训课程中让大家花了不少时间去讨论.改进.完善自己的代码.虽然刚毕业的同学对于代码质量都很用心,但最终呈现出来的质量仍然没能达到"十分优秀"的程度. 究其原因,主要是不了解好的代码"应该"是什么样的. 什么是好代码 写代码的第一步是理解什么是好代码.在准备bootcamp的课程的时候,我就为这个问题犯了难,我尝试着用一些精确的定义区分出"优等品"."良品".&quo

TDD 的本质不是 TDD

在敏捷推进的过程中,一般认为有三大难点. 第一大难点就是故事拆分,我们的故事又要纵拆,又要拆小.纵拆就意味着横跨整个端到端的流程,拆小意味着尽量要短.而且纵拆和拆小本身相互就是矛盾的,所以觉得敏捷推进第一难点就是拆分. 第二大难点,就是我们平时说的团队建设.大家想一想,我们大部分都不是企业的股东,那我们有什么力量去组织团队呢? 第三大难点,就是我们经常说的TDD.要改变很多我们传统研发的思维方式和观念,同时又要牵涉到软件设计方面的问题本质复杂度而这又是系统工程层面的东西.所以说,它本身的难度也是

PHP 性能分析(三): 性能调优实战

在本系列的 第一篇 中,我们介绍了 XHProf .而在 第二篇 中,我们深入研究了 XHGui UI, 现在最后一篇,让我们把 XHProf /XHGui 的知识用到工作中! 性能调优 不用运行的代码才是绝好的代码.其他只是好的代码.所以,性能调优时,最好的选择是首先确保运行尽可能少的代码. OpCode 缓存 首先,最快且最简单的选择是启用 OpCode 缓存.OpCode 缓存的更多信息可以在 这里 找到. 在上图,我们看到启用 Zend OpCache 后发生的情况.最后一行是我们的基准

浅析分布式系统

WeTest导读 我们常常会听说,某个互联网应用的服务器端系统多么牛逼,比如QQ.微信.淘宝.那么,一个互联网应用的服务器端系统,到底牛逼在什么地方?为什么海量的用户访问,会让一个服务器端系统变得更复杂?本文就是想从最基本的地方开始,探寻服务器端系统技术的基础概念.  承载量是分布式系统存在的原因  当一个互联网业务获得大众欢迎的时候,最显著碰到的技术问题,就是服务器非常繁忙.当每天有1000万个用户访问你的网站时,无论你使用什么样的服务器硬件,都不可能只用一台机器就承载的了.因此,在互联网程序