Ronnie's Blog

Bob文集之1——Tools are not the Answer

软件工程#软件工程 #工具

作者：程序员罗尼 ｜ 发布：2020-01-24 ｜ 原文：https://mp.weixin.qq.com/s/WolR3rAleNpCn1mpzuc84A

I just finished reading an extremely depressing article in The Atlantic entitled: The Coming Software Apocalypse. The article does a good job, at first, of describing several terrible software bugs that have harmed, maimed, and killed people. But then the article veers off in a direction that I found disheartening.

我刚读完一篇刊登在 The Atlantic 网站上的十分令人压抑的文章，名叫 The Coming Software Apocalypse。刚开始写的还不错，描述了一些软件中出现的可怕的 bug，这些 bug 伤害，致残甚至害死过人。但是之后就偏离到了一个令人沮丧的方向。

The author of the article interviewed many thought leaders in the industry, but chose only those thought leaders who were inventing new technologies. Those technologies were things like Light Table, Model Driven Engineering, and TLA+.

文章作者采访了许多业界的意见领袖，但是仅仅选择了一些发明了新技术的人。这些技术包括像 Light Table、 Model Driven Engineering 和 TLA+ 等。

I have nothing against tools like this. I’ve even contributed money to the Light Table project. I think that good software tools make it easier to write good software. However, tools are not the answer to the “Apocalypse”.

我并不反对这些工具，我也为 Light Table 贡献了很多钱，我认为好的软件工具可以使软件开发变得更容易，然而，工具并不是软件 Apocalypse 的答案。

Nowhere in the article did the author examine the possibility that programmers are generally undisciplined. The author did not interview software experts like Kent Beck, or Ward Cunningham, or Martin Fowler. The author completely avoided the notion that the software apocalypse might be avoided if programmers just did a better job. Instead, the author seemed convinced that the solution to the software apocalypse – the solution to bad code – is more code.

作者在文章中没有任何地方研究程序员不遵守几率的可能性，作者没有访问过诸如 Kent Beck、Ward Cunningham、Martin Fowler 的软件开发专家，作者完全忽视了这样一个概念，即如果程序员能做的更好，apocalypse 是可以被避免的，相反，作者似乎认定解决软件 apocalypse（也就是解决烂代码）的方式是写更多的代码。

I disagree. Tools are fine; but the solution to the software apocalypse is not more tools. The solution is better programming discipline.

我无法认同，工具是好的，但是解决软件 apocalypse 的方法不是更多的工具，而是更好的编程纪律。

Last night I watched the pilot episode of The Wisdom of the Crowd. It’s a fun new series on CBS. The hero of the story is the inventor of a huge social network platform whose daughter is murdered. He leaves everything to invent a new social network called Sophie which uses crowd sourcing to solve crimes.

昨晚我看了《The Wisdom of the Crowd》的试播集，这是 CBS 的一部新的系列剧，故事的主角是一个巨大社交网络平台的发明者，他的女儿被谋杀了，他不遗余力的去研发叫做 Sophie 的社交网络，通过网络采用众包的方式解决犯罪问题。

They must have a few programmers consulting on the show because there was one scene that made me hang my head in shame. Someone posts a video of a crime scene on the platform. It leads the investigators in a certain direction that doesn’t pan out. Later they find that the video was actually much longer and contained clear evidence; but that the Sophie platform had truncated it to 30 seconds causing the investiators to miss that evidence.

我觉得他们一定得找一些程序员咨询一下，因为其中有一幕令我羞愧不已，用户在平台上上传了罪案的相关视频，这个视频会给调查人员提供正确的方向，但是之后发现包含关键证据的视频过长，在 Sophie 平台上传时被截到了 30s，导致关键证据丢失。

The hero was furious. Murderers might have escaped. More people might have died. So he confronted the lead developer and demanded to know how this could have happened. He was told that one of the programmers had reused some code from a different platform and had not realized that it had a built-in 30 second truncation. The hero was livid. He demanded to know which programmer had been so sloppy. The lead developer refused to say. She told him that if he wanted to fire someone, he should fire her. So the hero backed down.

主角暴怒，杀人犯可能已经跑了，更多的人可能被杀，他来到技术主管面前要求他解释这一切怎么发生的，技术主管说一个程序员重用了一段不同平台的代码，没有意识到其中有 30s 截断的限制，主角脸色铁青，想知道是哪个人如此马虎，技术主管决绝回答，并告诉他如果想解雇别人的话，就先解雇她吧，主角退缩了。

Later, the guilty programmer thanked the lead developer for protecting him. He said: “I knew I shouldn’t have reused that code, but we were in a rush.” She smiled at him and told him not to worry about it.

后来，肇事者感谢主管对自己的保护，他说“我不应该重用那段代码，但是我们很着急”，她笑着说不要太担心这个。

And right there, ladies and gentlemen, you can see both the cause of the apocalypse, and the obvious solution.

同志们，我给你们看看导致 apocalypse 的原因和解决方案。

The cause:

  1. Too many programmer take sloppy short-cuts under schedule pressure.
  2. Too many other programmers think it’s fine, and provide cover.

原因：

  1. 太多程序员在时间表的压力下寻找捷径
  2. 太多其他程序员认可这件事，还提供掩护

The obvious solution:

  1. Raise the level of software discipline and professionalism.
  2. Never make excuses for sloppy work.

明显的解决方案：

  1. 提高软件纪律和专业化水准
  2. 不要为马虎的工作找借口

This is the point that the author of the Atlantic article missed entirely. The one thing he failed to consider was that the reason we are facing bugs that kill people and lose fortunes, the reason that we are facing a software apocalypse, is that too many programmers think that schedule pressure makes it OK to do a half-assed job.

作者忽略了关键的一点，我们所面临的种种 bug 和软件 apocalypse，是太多的程序员在时间的压力下做了个半成品。

I found it astounding that in that entire long article, the notion of testing was never examined as a solution – it was only presented as a forlorn and foolish hope.

令人震惊的是，整篇文章都没有提到测试，他只被看作是一种愚蠢的希冀。

At one point he said of bugs:

You could do all the testing you wanted and you’d never find them all.

关于 bug 他提到一点：你可以测试你所有想测试的，但你不可能把他们都找出来

True as this may be, it is not a reason to discard, or reduce, or fail to increase testing as a discipline.

他可能是对的，但是这不是不写或者减少测试的理由。

Several of the tools that the author presented were simply glorified REPLs. They allow the programmers to immediately visualize the results of their code.

作者提到的一些工具只是美化了 REPL，他们允许程序员立即能看到代码的结果。

I think that such rapid feedback is wonderful. I think that rapid feedback of that kind is extraordinarily valuable. But REPLs don’t replace tests.

我认同快速反馈是有用的，我认为快速反馈是很好的，但是 REPL 并不能代替测试。

Whenever I hear that a programmer “tested it in the REPL” I cringe. You don’t test things in the REPL; you try things in the REPL. A test is much more formal than a trial. A test can be repeated. A test can be enhanced. You can add to a test. You can review a test. You can add a test to a larger suite of tests. A test is a document. A test is a program.

当我听到程序员说“在REPL中测试”，我很无语，在REPL中不是测试，只是在试验，测试是更正式的，测试是可重复的、可以被强化的、可以被增加的、可以被 review 的，可以将一个测试加入到更大的测试集中，测试是文档、更是程序。

Better REPLs are not the answer. Model Driven Engineering is not the answer. Tools and platforms are not the answer. Better languages are not the answer. Better frameworks are not the answer.

好的 REPL 不是答案，Model Driven Engineering 不是答案，工具和平台、更好的语言、更好的框架都不是答案。

Yes, those things are shiny, and they sparkle and glisten; but…

“The fault, dear Brutus, is not in our stars, But in ourselves…“

这些东西确实是闪闪发亮的，但是

亲爱的Brutus，错不在我们的星星，错在我们自己

I stood before a sea of programmers a few days ago. I asked them the question I always ask: “How many of you write unit tests on a regular basis?” Not one in twenty raised their hands.

我几天在面对着很多程序员，问他们你们有多少人在定期写单元测试，不到二十分之一的人举手。

PS：

END