代码整洁之道--读书笔记(7)

代码整洁之道

简介:

本书是编程大师“Bob 大叔”40余年编程生涯的心得体会的总结,讲解要成为真正专业的程序员需要具备什么样的态度,需要遵循什么样的原则,需要采取什么样的行动。作者以自己以及身边的同事走过的弯路、犯过的错误为例,意在为后来者引路,助其职业生涯迈上更高台阶。

本书适合所有程序员阅读,也可供所有想成为具备职业素养的职场人士参考。

第七章 验收测试

专业开发人员既要做好开发,也要做好沟通。“输入糟糕,输出也会糟糕”对程序员同样适用,所以职业程序员会重视与团队及业务部门的沟通,确保这种沟通的准确、流畅。

7.1 需求的沟通

过早精细化

做业务的人和写程序的人都容易陷入一个陷阱,即过早进行精细化。业务方还没有启动项目,就要精确知道最后能得到什么;开发方还没有评估整个项目,就希望精确知道要交付什么。双方都贪求不现实的精确性,而且经常愿意花大价钱来追求这种精确。

不确定性:

在工作中,有一种现象叫观察者效应,或者不确定原则。每次你向业务方展示一项功能,他们就获得了比之前更多的信息,这些新信息反过来又会影响他们对整个系统的看法。

预估焦虑:需求是一定会变化的,所以追求那种精确性是徒劳的。

迟来的模糊性:

避免过早精细化的办法是尽可能地推迟精细化。专业开发人员直到着手开发的前一刻才会把需求具体化。但是,这可能造成另一个问题:迟来的模糊性。

需求文档中的每一点模糊之处,都对应着业务方的一点分歧。当然,模糊不只来自于分歧或争论。有时候,业务方会想当然地认为看文档的人懂得自己的意思

7.2 验收测试

在本章,我们把验收测试定义为业务方与开发方合作编写的测试,其目的在于确定需求已经完成。

”完成“的定义

完成意味着所有的代码都写完了,所有的测试都通过了,QA和需求方已经认可。这,才是完成。

那么,怎样能达到这种程度的完成,同时不影响迭代的速度呢?你应该编写整套的自动化测试,它们全都通过,就意味着满足了所有的要求。如果对功能的验收测试全部通过,就算真正完成了。专业开发人员会根据自动化的验收测试来定义需求。他们与业务方和QA一起工作,确保自动化测试能够真正覆盖完成所需的各项指标。

沟通:

验收测试的目的是沟通、澄清、精确化。开发方、业务方、测试方对验收测试达成共识,大家都能明白系统的行为将会是怎样。各方都应当记录这种准确的共识。在专业开发人员看来,与业务方、测试方协同工作,确保大家都明白要做的是什么,是自己的责任。

自动化:专业程序员会避免这种情况。相比手动测试,自动化测试的成本非常低,让人手工执行测试脚本不划算。专业开发人员认为,实现验收测试的自动化是自己的责任。

专业开发人员对待自动化这种额外工作的态度:

写这么多测试,看起来的确是大量额外工作。这根本不是什么额外工作。

写这些测试是为了确定系统的各项指标符合要求。确定这些细节指标的目的,是为了确定系统的指标;只有确定这些细节指标,我们这些程序员才能确知“完成”;只有确定这些细节指标,业务方才能确认他们花钱开发的系统确实满足了需求;只有确认这些指标,才可以真正做到自动化测试。

所以,不要把它们看作额外的工作,而应当看成节省时间和金钱的办法。这些测试可以避免你的开发误入歧途,也可以帮你确认自己已经完工。

验收测试什么时候写,由谁来写:

通常会把测试交给业务分析员、QA甚至是开发人员。如果只能由开发人员来写测试,应当确保写测试的程序员与开发所测试功能的程序员不是同一个人。

通常,业务分析员测试“正确路径”,以证明功能的业务价值;QA则测试“错误路径”、边界条件、异常、例外情况,因为QA的职责是考虑哪些部分可能出问题。

遵循“推迟精细化”的原则,验收测试应该越晚越好,通常是功能执行完成的前几天。在敏捷项目中,只有在选定了下一轮迭代(Iteration)或当前冲刺(Sprint)所需要的功能之后,才编写测试。

开发人员的角色:开发人员有责任把验收测试与系统联系起来,然后让这些测试通过。

  • 身为专业开发人员,与编写测试的人协商并改进测试是你的职责。绝不能被动接受测试,更不能对自己说:“噢,测试是这么要求的,我就得这么办。
  • ”请记住,身为专业开发人员,你的职责是协助团队开发出最棒的软件。也就是说,每个人都需要关心错误和疏忽,并协力改正。

验收测试和单元测试区别:

首先,尽管两者测试的可能是同一个对象,其机制和路径却是不同的。单元测试是深入系统内部进行,调用特定类的方法;验收测试则是在系统外部,通常是在API或者是UI级别进行。所以两者的执行路径是截然不同的。

它们的主要功能其实不是测试,测试只是它们的附属职能。单元测试和验收测试首先是文档,然后才是测试。它们的主要目的是如实描述系统的设计、结构、行为。它们当然可以验证设计、结构、行为是否达到了具体指标,但是,它们的真正价值不在测试上,而在具体指标上。

图形界面:

  • 更好的办法是,测试系统功能时,应当调用真实的API,而不是GUI。
  • 几十年来,设计专家一直在教导我们,要把GUI和业务逻辑分开。

持续集成:

请务必确保在持续集成系统中,单元测试和验收测试每天都能运行好几次。整套持续集成系统应该由源代码管理系统来触发。只要有人提交了代码,持续集成系统就会开始构建,并运行所有的测试,测试结果会用电子邮件发送给团队所有人。

持续集成不应该失败,如果失败了,团队里的所有人都应该停下手里的活,看看如何让测试通过。在持续集成系统里,失败的集成应该视为紧急情况,也就是“立刻中止”型事件。

结论

交流细节信息是件麻烦事。尤其是开发方和业务方交流关于程序的细节时,更是如此。通常,各方握手言欢,以为其他人都明白自己的意思。双方以为取得了共识,然后带着截然不同的想法离开,这种事太平常不过了。

要解决开发方和业务方沟通问题,我所知道的唯一有效的办法就是编写自动化的验收测试。这些测试足够正式,所以其结果有权威性。这些测试不会造成模糊,也不可能与真实系统脱节。它们,就是无可挑剔的需求文档。