写代码的人

Posts tagged ‘代码’

你真正需要的代码测试覆盖率是多少?

本文是从 How much code coverage do you really need? 这篇文章翻译而来。


我写这篇文章的起因是由于看了@unclebobmartin在微博上的一些看起来言之凿凿的话语。给那些不认识Uncle Bob的人介绍一下——他是我们软件产业里最著名的一个专家,是《 Clean Code(代码整洁之道)》这本著作的作者,是敏捷宣言(Agile Manifesto)的签署人之一。在上世纪九十年代,他对文献最佳面向对象实践方法贡献了很大的力量。所以,当他说话时,我们一定要关注一下。

他给我们日常的TDD和单元测试制订了一个最高纲领。我们可以从他的微博里清楚的看到这点:

“两件事。可重复性和成本。跟自动化测试比起来,手工测试的成本高的可怕。”

“手工测试不是测试;那是在做实验。只要有人的因素牵涉其中,那结果就必然可疑。”

“你们告诉我的实际意思就是让我大开方便之门、不去测试某些程序。哼 …”

“代码覆盖率100%并不是成绩,那是最低要求。即使只写了一行代码,你也要测试它。”

他接着把软件测试跟在其它领域里常见的但被认为很关键的活动进行了比较:

“战地外科医生也许没有最够的时间做严格的消毒,但这带来的风险可能是死亡或高昂的治疗代价。”

“会计难道只会把80%的数据表做双份备份吗?”

“有多少回你们都看到了那些严重的宕机事故都是因为一些愚蠢的程序员以为那些愚蠢的代码不许要经过测试而导致的?“

他的所有这些观点都很有价值,但他只向我们展示了问题的一面。现实中并不是所有的应用都需要如此谨小慎微的测试。并不是所有的应用都跟战地手术或巨额资金核算那么重要。(更不要说在很多情况下的为”合理避税“而做的帐务:))。

一个更重要的原因是,100%的测试覆盖率并不能保证bug的不出现。就连Uncle Bob自己也承认:

”测试并不能杜绝bug。但测试能保证程序的行为是符合预期的。“

这很显然指的是:同一个程序员在程序里埋下的概念性或逻辑性错误,由他自己测是绝对测不出来的。

最终,所有的问题归结于ROI(投资收回率)和实用主义。有些应用比其它应用需要更多的测试。有些bug需要比其它bug投入更多的精力去修复。 究竟是否需要在自动化测试是投入更多的时间和财力,或多少覆盖率是合适的还是过分了,这都需要人的主观判断。


本文原始地址:你真正需要的代码测试覆盖率是多少?

我所经手过的最差代码

导读:本文出自知名技术专家Jacques Mattheij(ww.com的创始人)最近发表的博客《The worst program I ever worked on》,译文来自36氪,原名《我破解了那位程序员“最饿”的阴谋》。

文章内容如下:

曾经听说有些程序员会在自己编写的程序里做手脚以保住自己的饭碗不被抢走,没想到我自己还真的碰上这样的事了。

那是我的一份小工,一家公司解雇了自己的程序员后,让我帮忙把他们产生了故障的一个软件修正过来。我接下了这份工作,可没想到接下来的那段时间我就天天泡在一堆“食物”里了。

你很难想象这个程序的作者是个什么样的人,我真怀疑他是不是成天想着吃,因为他将这个程序中所有的函数和变量全部用食物的名字命名,Pizza’s(披萨),tomatoes(西红柿),pickles(泡菜),fruits(水果),vegetable(蔬菜)等各种估计只要是他能想到的食物的名字都被他用了进来。

不过我还是蛮佩服这家伙的,加密的非常漂亮不是吗,一般人还是难以看出这些食物中蕴藏的玄机的。于是我开始一点一点的为这些函数和变量重新命名以将其转变成有意义的表达。

虽说这项工作也并不是无法完成或者极难完成的那种,但是将其从毫无意义的表达变成有意义的表达还是一项非常繁琐的工作。此外比这些无意义的食物名称更加要命的是那家伙在程序里还用了许多种面条的名字使得本已混乱的程序变得更加晦涩难懂。最后我一步一步的将重命名的工作完成后,还改写了很大一部分的代码使其变得更加容易被理解和有效的执行。

我一直在想这家伙是先写完了该程序的原始代码后再将其打乱成了现在的这副模样,还是他一开始就直接敲出了这一堆毫无意义却又能有序执行的食物代码,如果真是直接敲出来的,那好家伙,他太牛了。

不过,最后,我在此还是要奉劝各位敲代码的一句,不要企图在代码里做手脚来保住自己的工作或者要挟什么,你知道的,这没有好结果。毕竟,敲出这一堆食物来的那位哥们还是失败了,不是吗?

原文链接:The worst program I ever worked on

译文链接:我所经手过的最差代码


好代码不值钱

导读: 原文来自geekm.ag 上一篇《 Good code is cheap code》,由国内整理编译《好代码不值钱》。作者认为好的程序员和伟大的程序员之间的区别就在于伟大的程序员理解他们的模式。

以下是文章内容:

 

当我跟做开发的同事说出这话时,他们的第一反应是一种惊愕,然后是将近一个星期的嘲笑,把它当作一个笑话来讲。当他们走近看我的表情、知道我是认真的时,才收敛一点。

当最初的惊愕消退后,他们会用一些这样的话来反驳:“好代码不廉价,好代码是采用经过数十年计算机科学研究和积累得出的最佳实践设计模式和方法论建立起来的精心制作的程序代码。”

我只好继续解释为什么他们给出的好代码的定义有问题的原因是(这是很多开发人员都忽视了的一个原因):知晓各种设计模式,框架,技术技巧只是事情的一方面,而知道何时该、何时不该应用他们才是更重要的问题。在不知道一种技巧方式如何能对系统的开发有帮助的情况下,这种模式方法极有可能成为一种开发的阻碍,而不是一种有益的帮助。

我还要解释说,我所说的“廉价的代码”是指这些代码只需要很少的人/天数就能开发出来,并不是说是由没有经验的开发人员、在很少的工资报酬下、用6个月封闭式、只有烤白薯和豆腐汤可吃的环境中开发出来的东西。

但是 … 设计模式毕竟是个好东西 … 不是吗?当然,但它们好在哪里?它们能提供什么好处?

  • 容易维护
  • 产品更健壮
  • 容易理解
  • 易于日后的改进提高
  • 更好的可跟踪性

你会发现所有的这些最终都落到一点上:从长期的角度看,它们能让你更快的做事情。这事情有可能是系统迁移,或是增加一个新功能,不论是什么,通过运用这些方法模式,你会在时间效率上获得实实在在的好处。

这么说,我们观点一致吗?

怎么说呢,让我给你们说个例子,我们看看实现它的几种方式。

系统

用PHP创建一个发邮件的表单,表单里有几个表单项,用邮件把这些数据发送给某个人。除此之外,表单里的内容还要存入MySQL数据库里。

现在,用什么方式实现它们最好?按照传统的说法,采用最好的实践设计模式,你可能会想到这些:

  • MVC
  • N-层设计,包括数据库抽象层
  • 对象关系映射(ORM)
  • 可能用到的框架
  • XML配置和相关模型
  • 等等.

我可以说,这简直是疯了,客户的这些需求完全可以用10几行代码、一个小时里(包括测试时间)完成,而且所有的那些方法模式所希望达到的效果(诸如可读性,可移植性,稳定性)都有了。如果使用上面列出的那些,反而真正的会达不到这个目标,使代码复杂化,难于理解和维护修改。

那现在,假设客户又来了,要求做一些改动,比如要增加一个管理员的界面。这样的话,你就胜利了,你已经实现了很多很有用处的东西;然而这是因为你在第一次开发这个系统时付出了很大的代价。我要向你声明的是,即使我现在把这些简单的代码进行重构,增加一些简单的业务层,也仍然比按你要求的那种过度技术化的初始实现方案要简单的多。

再说了,如果客户要求的只是在表单里增加一个属性,那你的N-层设计方案会让你痛苦不堪,因为你需要改动各个层,包括那些CRUD代码。

SCRUM

我发现Scrum能吸引我的最大一个原因是它能迫使你敏捷开发;它能迫使你在每个Sprint结束的时候把东西都实现、发布。它不会让你做出目前用不到的多余的东西;它不会允许你在实现东西上有任何所谓“正确方式”的奢侈行为。

相反,在你需要的时候你才去重构。当然,这会有一定的风险,因为在实现某些功能上你会花去比当初已经做了一些基础工作的情况下要更长的时间。然而,产品开发就像是一个沙漠中四处漂移的沙丘,你永远不可能准确的知道一个产品在将来会做如何的改动。所有的你花在实现这些很有吸引力的各种模式上的时间很可能会成为一种完全的浪费。

复用性

有些人会指出,我所说的方式产生的代码不具有太多的复用性,不能在新开发的一些其它系统中使用。我对这个问题的回复就是,在根本不知道某些东西是否/如何/在哪将会被复用的情况下去设计一个可复用的东西,这就跟去实现一些你根本用不到的功能或你的应用里跟本用不到的功能一样愚蠢而糟糕。如果你有一个清楚的远见,知道什么地方会复用这些东西,这就不同了,因为你确实有一个内部的业务需求在指导你正确的开发方向。

我的最后的思考 …

  • 我想,如果
  • 了解你的设计模式,知道它们各自的好处(我一直认为,好的程序员和伟大的程序员之间的区别就在于伟大的程序员理解他们的模式);
  • 让你的代码廉价:
  • 当模式能够给你带来好处,而且为你省时时才去使用它们;
  • 如果不是这样就不要使用它们(例如:想想你最近的一次为什么要把系统迁移到一个不同的数据库上?);
  • 当框架能够帮你提高开发速度时才使用它们;
  • 在必要的时候重构,不要做一些超前性的开发;

你能按照这些指导原则做事,你会发现开发周期变短、实现的代码更简洁,易于调试,易于维护修改。

原文链接:Good code is cheap code

译文链接:好代码不值钱

来自:http://www.aqee.net/2011/03/16/good-code-is-cheap-code/