NOVOTS KMS 词汇表 Glossary    联系我们 Contact Us
查询 Search  
   
按类别浏览 Browse by Category
NOVOTS KMS .: 其他 .: 转载:程序员修炼之道:敲打代码

转载:程序员修炼之道:敲打代码

将编程作为一种娱乐消遣,你会轻易忽略像边界情况处理、错误报告等这类事情,它们确实有点麻烦。可一旦你从事编程生产(更别提要养家糊口)你就不能走捷径。

编写生产质量级别的代码似乎是一个明摆着的目标,但计算机行业却费了不少时日才弄明白正确的实现之道。例如,Windows 95曾经有个Bug会让操作系统在连续运行49.7天之后挂起—但是该Bug花了4年时间才暴露,有Bug这件事本身并不特别让人觉得惊讶,时间之所以这么长是因为其他Bug在不到49.7天的时候就让Windows 95崩溃了。

通往高质量代码的道路有两条,你可以二选一:一开始就内置质量,或者事后再敲打它。前者需要你在日复一日的编码中遵循众多戒律;后者则要求大量测试,到头来,在自以为完工之后,你会发现还有很多工作要做。

事后敲打(beat-it-in-afterward)是常见的工作方式,行业占统治地位的瀑布开发方法就是这样:规格说明、设计、构建、测试。测试是最后的步骤。产品来到测试部门,很快就崩溃了。于是,又回到工程部门,修复Bug。接着,把另一版提交给测试部门,又由于其他原因崩溃。就这样,来来回回,许多月(甚至是数年)流逝。

本章大部分内容都聚焦于内置质量的技术,因为它是一种可以让你对自己的产品有信心、给产品添加新特性,并长年维护产品的构建方法。当然,构置生产质量级别的软件并不是一本书就可以完全覆盖的主题,而且它的范畴也要比测试大得多。不管怎样,本章仅限于讨论对改进代码质量可以起到立竿见影效果的那些事情:

深入具体实践之前,我们会从“技巧1:敲打代码”开始,帮你建立正确的思维方式。

接下来是“技巧2:坚持正确”,我们将关注验证代码正确性的方法。

你还可以用另一种方法;在“技巧3:测试驱动设计”中,我们尝试从测试出发,使用这些测试来驱动设计。

很快,你就会被巨大的代码库给弄得晕头转向。“技巧4:驯服复杂度”尤其适合外表吓人的生产规模的软件项目。

“技巧5:优雅地失败”会把我们带离愉悦之路,在那里,你的代码需要应对意想不到的问题。

在事情才真正变得棘手的时候,我们会小憩一会儿:“技巧6:确定风格”帮助你让代码保持美观,从长远来看,它对你的帮助超乎想象。

回到困难的部分。“技巧7:改善遗留代码”处理你从前辈那里继承而来的代码。

最后,在“技巧8:代码评审要早且多”中,你将和你的团队一起来保证你的代码随时可供部署。

关于这里没有谈及的内容

限于篇幅,还有其他一些对编程生产有促进的内容我并没有提及,而且在很多行业内都有你需要满足的领域相关的标准包括如下一些示例:

预防恶意代码、网络活动和其他安全性问题的防御性编程。

保护用户的数据不会因硬件和系统故障、软件Bug和安全破坏而受损。

部署并在面临巨大负载时软件性能的向外扩展。

……

向资深程序员求教:除了写出能工作的代码外—要一贯保持—还要做什么才能让你的代码合格?

技巧1 敲打代码(1)

[白带] 只要编写生产代码,你就要证明它经得起推敲。

你可能认为编写可靠代码是再明显不过的工作要求了。招工广告上不可能写:“急聘:具备良好工作态度、团队合作精神和桌上足球技巧的程序员。有则更佳:会编写可靠的代码。”可有问题的程序还是有这么多,怎么回事?

在深入探讨保证代码质量的日常实践之前,让我们先讨论“编写可靠代码”的含义。它不仅仅是一份实践清单,它还是一种思维方式。在把产品交到客户手中之前,你必须敲打自己的代码和整个产品。

客户终究敲打你的产品,以一种你不曾预料到的方式使用它。他们用它的时间会很长,而且会在你没有测试过的环境里用它。你必须考虑的问题是:打算让客户发现多少Bug?

你现在对代码敲打的次数越多,在交到客户手中之前,能清除掉的Bug就越多,留给客户的Bug就越少。

质量保证的形式

尽管本章大部分内容都关注于代码级的质量和单元测试,但品质保证却是一个要大得多的主题。让我们考虑一下产品需要经受的考验。

代码评审

保证代码质量最简单的方法就是让另一个程序员去读它。别出心裁的评审过程并没有必要,而且就连结对编程也算是一种形式的实时代码评审。团队将利用代码评审捕获Bug,贯彻编程风格和标准,同时在团队成员间传播知识。我们将在“技巧8:代码评审要早且多”中讨论代码评审。

单元测试

在你一个类接着一个类、一个方法接着一个方法地构建应用的业务逻辑时,验证代码的最佳方式就是单元测试。这种内部零件级的测试被设计用来对逻辑的各部分单独验证。我们将在“技巧2:坚持正确”和“技巧3:测试驱动设计”中讨论它们。技巧1 敲打代码(2)

接受测试

单元测试立足于由内而外地审视产品,接受测试则被设计成模拟真实世界的用户,代表他们与系统交互。理想状况下,它们是自动执行的,而且以某种叙述式的风格书写出来。例如,某银行自动柜员机应用会有类似这样的接受故事:若我的活期存款为0,当我在ATM的“活期存款”中选择“取款”时,那么我应该看到“对不起,今天的晚餐吃泡面吧。”

它不像莎翁著作那样文采飞扬,但这些测试操练了整个系统:从用户界面一直到业务逻辑。无论它们是自动执行的,还是人工执行的,你的公司需要知道—在任何客户使用它之前—所有系统组件正在像预期的那样协调工作。

负载测试

负载测试将产品置于真实的压力条件下,然后度量它的响应。例如,某网站可能需要在数据库有100万条记录的条件下在100毫秒内展示指定页面。这些测试将揭示正确但不恰当的行为,如需要线性伸缩但却以指数级别伸缩的代码。

定向探索测试

接受测试覆盖了产品的所有指定行为,它可能来自于产品需求文档或会议。但程序员通常还是有办法使之崩溃—总有些黑暗角落被规格说明疏忽掉。定向探索测试就是要将这些边界情况挖出来。

“全系统”测试的范围究竟有多大?

我曾耗费数年编写工业机器人的控制软件。由于单元测试会模拟电动机的运动,我得以能够在工作站上测试业务逻辑。全系统测试当然需要运行在真正的机器人上。

就机器人来讲,好的事情是你能看到自己的代码能工作,不太好的事情是你能看到(和听到,有时甚至闻到)代码的失败。但更重要的是,机器人不是一个完美的环境。每个机器人都不同—它是上千个机电零件的组合体,每个零件多少都有些差异。因而,在多个机器人上测试非常关键。

这条经验对于更传统的系统同样适用:供应商的软件可能崩溃,网络会有延迟,硬盘会取出坏数据。公司的测试实验室应该模拟这些非理想环境,因为产品最终将会在客户手中遇到这些状况。

这种测试通常是人工执行的,可能是程序员自己,用于探索和发现问题。但最初探索之后,任何有用的测试就会被加到接受测试套件之中。

该测试有一个专业化的变种,如安全审计。在这些情况下,专业测试人员会利用他们的领域知识(可能也包括代码评审)来指导他们的测试。

机构测试

硬件产品需要不同的机构认证:FCC度量电磁辐射,确保产品不会导致无线电干扰;美国保险商实验室(UL)检查当你将产品置于火上或舔电池电极时会发生什么。这些测试都在新产品发布之前进行,每次硬件变化都会影响认证。

环境测试

硬件产品的运行温度和湿度也需要在推至极限时测试。这些测试是用环境室来完成的,它可以同时控制这两个因素;当产品在其间运行时,它会经历所有四种极限条件。

白盒和黑盒

你会听到白盒测试和黑盒测试这两个术语。在白盒测试中,你能查看程序的内部结构,判断是否工作正常。单元测试就是这样的好例子。

黑盒测试则相反,它从客户角度审视产品,不关心内部状况,只关心产品的外部行为是否正确。

兼容性测试

一旦产品需要跟其他产品进行互操作(如某字处理程序需要跟其他字处理程序交换文档),这些兼容性的论断就需要定期验证。它们可能会访问一组已保存的文档,也可能会实时地将你的产品连接到其他产品上。

耐久性测试

你会注意到这里提到的大多数测试都是尽量频繁且快速地运行。可有些Bug只会在一段时间的使用之后现身。前面提到的49.7天的Bug很好说明了这一点—它源于每毫秒递增的32位计数器,在49.7天之后,它会从最大值反转成0。测试若不持续运行上一会儿,你就无法发现类似Bug。

Beta测试

产品在这一阶段被送到了真实客户手中—他们知道自己要参加测试,并同意发现问题时提交报告。Beta测试的目的就在于我们在本技巧一开始讨论的:Beta测试者将以你意想不到的方式使用产品,试用它一段时间,并在你没有测试过的环境中测试产品。

运行中测试

公司可能会在产品上市之后继续测试。尤其是硬件产品,如偶尔从制造线上拔掉一个单元并证明制造线能工作正常是一种很有用的方法。这些运行中测试的设计目的就是为了捕获因零件或装配过程中的变化而导致的问题。

实践 VS 思维方式

你的团队可能采用类似“所有代码都必须有单元测试”或“所有代码必须先评审后检入(check in)”的实践。但这些实践没有一个能保证代码坚若磐石。想想若公司根本就没有采用一个质量实践,这种状况下该怎么做,即你将如何敲打代码以保证它的可靠性?

这是在继续深入之前你需要建立的思维方式。提交可靠的代码。质量实践只是达到目的的一种手段—最终的裁判是客户手中产品的可靠性。你想让你的名字跟市面上满是Bug的垃圾产品挂钩吗?不,当然不想。

行动指南

在上述所有形式的测试中,你的公司采用了哪些?在源代码中寻找单元测试,向测试部门询问接受测试计划,问问Beta测试是如何进行的以及向哪个部门提交反馈。再问下资深工程师:这是否足以保证客户有一个平滑的体验?

在定向探索测试上多花些时间,哪怕你的“方向”有点儿模糊。实际用一下产品,看看你是否可以让它崩溃。如果可以,那就相应地记下Bug报告。



这篇文章对你多有用?

相关文章

article 程序员应知—循序渐进
...

(No rating)  6-23-2015    Views: 627   
article 转载:为什么中国的程序员总被称为码农?

(No rating)  10-24-2012    Views: 1058   
article 程序员需要谨记的九大安全编码规则
历史已经证明,软件设计的缺陷一直是导致其漏洞被...

  1-1-2013    Views: 1094   

用户评语

添加评语
当前还没有评语.


.: .: .: .: .:
[ 登陆 ]
北京护航科技有限公司 2006

Novots Technologies Limited