新闻中心

译者 | Jeremy Mikkola

翻译者 | 战神

策画 | 百盛

软件设计为何这般之难？责任编辑指出此种十分困难与C语言毫无关系，即使当代的C语言早已足够多好了。所以，其原因究竟是什么？

有一类看法指出，采用更快的C语言就会让软件设计显得更容易、更高效率。在编订或 Fortran 黄金时代，此种看法毫无疑问是对的。不过，当代的C语言早已足够多好了，现阶段的主要十分困难和改良良机再次出现在其它各方面。程式设计依然极难，但引致此种十分困难的其原因却与所采用的C语言毫无关系。

1安萨尔运动定律

当你有一连串产品须要顺利完成的连贯性各项任务时，安萨尔运动定律就会有所作为。安萨尔运动定律说我们，透过大力推进当中的一个各项任务来大力推进整座系列产品各项任务的速率是有限制性管制的。

比如，煮沸水须要 10 两分钟，接着煮意大利面也须要 10 两分钟。即便你能找出一类可以更慢把水煮沸的方式，你做早饭的天数也当然不能多于煮意大利面所需的 10 两分钟。

通常的式子是这种的，假如某类各项任务的总天数占比是 p，所以你总有一天都难以赢得小于 1/(1-p) 的快速。假定各项任务的一部份挤占了 90% 的天数，所以 p=0.90，将这个部份强化到零天数，将使整座组织工作速率提升 1/(1-0.90)=10 倍。

安萨尔运动定律的突破点是，你所要赢得的快速受了你所强化部份的大小不一管制。

程式设计之所以十分困难，其原因有很多。为了简单起见，我们可以把十分困难的事情想象成必须按顺序顺利完成的各项任务。毕竟，人类并不擅长多各项任务处理。在任意一个时刻，你要么在采用构建工具，要么在阅读文档，要么在编写代码或者参加会议。你一次只能应对一项各项任务，所以安萨尔运动定律大致适用。假如你设法将构建天数降到零，所以项目的顺利完成天数也只会短一点点。你的效率依然受限于顺利完成项目所需的其它事项。

过去，把一个程序翻译成计算机可以运行的东西是非常十分困难的。很久以前，须要先将程序转成 1 和 0，接着再一个一个地输入到计算机。我不知道这须要花费多少天数，但为了便于讨论，我们假定须要挤占 90% 的天数。这意味着，假如有一类更快的方式来说计算机该做什么（比如 Python），所以程式设计效率将提升 10 倍。

现在，我们有了更快的C语言，可以花更少的天数说计算机该做什么，生产力得到提升。将程序转成代码不再须要 90% 的天数，现在只须要 10% 的天数。这意味着我们可以从中赢得的最大改变是 1.11 倍，这比以前可以赢得的快速少 81 倍!

这是即使软件设计其余的 90% 各项任务都是十分困难的各项任务，一个更快的C语言不能让它们显得更容易。

2如何做到没朋友

我的意思是，程式设计的难度与C语言毫无关系。为了理解当中的其原因，我们先假定不须要操心与计算机相关的东西，你只须要说你的朋友要做些什么。你不能作弊，不能让他们依赖常识性的东西，你必须替他们做出所有的决定。

你会发现，你须要花很多天数来解释背景。你的朋友须要了解计算机程序要处理的东西在现实世界中是怎样的，以及程序应该要做什么。你须要解释各种缩略词和术语，须要讨论一些外部因素。

你的朋友须要知道所有可能再次出现的情况，有大量的小细节须要处理，比如用户不能在购物车中输入负数个产品。用户可能会尝试做出所有可能的行为，会发生各种可能的事情，比如包裹在运输过程中弄丢了，你会发现有大量的边界情况须要说你的朋友。

向你的朋友解释这一切是很十分困难的。首先，你须要了解与项目相关的所有现实世界的细节 (产品可能缺货，可能有折扣，等等)。其次，你须要做出程序在各种可能的情况下应该做什么的决定。第三，你须要以一类你的朋友能理解的方式与他们交流。这意味着你须要组织好你的想法，让它们易于理解。假如你写过文章或博客，你就会知道传达大量的信息并不是一件容易的事情！

请注意，到现阶段为止，这些各项任务都还没有涉及计算机，当然也就不涉及C语言。了解现实世界，了解程序应该做什么，以及如何组织这些想法，这些都是非常十分困难的各项任务。

3描述与规范

这里有一个容易就掉进去的陷阱，人们很容易忽略描述与规范之间的区别。比如，当你做出一个描述 (一辆红色的汽车)，你可以测试一个东西是否符合这个描述 (是的，它是红色的，但它不是一辆汽车)，但这不足以说你如何制造一辆汽车，即使制造汽车须要制造汽车的规范。

创造出一样东西须要做很多决定。假如你把每一个决定的结果都写下来，就有了一个（未组织的）规范。开发程序须要你做出这些决定，所以仅仅进行描述是不够的——你须要一个规范。当你做出一个描述 (它须要把文件列出来)，指出它就是一个规范，却忽略了你还须要做出其它无数个细小的决定 (它应该以什么顺序列出文件？它们应该按照自己的路线走下去吗?)。

当你要开始写一个程序时，你不得不面对这种的现实，即你的规范实际上只是描述而已。电脑不能接受类似画一个矩形这种的描述，它须要知道矩形应该再次出现在屏幕的什么地方，应该多大，应该是什么颜色的。将想法变成代码，你还须要做出很多决定，而做出这些决定须要付出很大的努力。人们倾向于将此种努力归咎于C语言，却不愿承认这种一个简单的事实：仅给出描述是极难得到规范的。

4回到计算机上来

开发软件不仅仅是理解要做什么并将其转化为代码。计算机本身存在一些问题，这些问题也须要程序来解决。程序要能在硬件和网络上快速运行，可能须要处理机器故障，而工具和协议的复杂性带来了更多问题。这些问题并非是在向计算机解释应该做什么的过程中造成的，它们都是原本就须要做出解释的事情。

你须要在脑子里运行部份程序。有时候，逻辑就像听故事一样容易理解，但有时候，事件顺序和状态跟踪复杂到难以放在脑子里。赢得运行正确的程序——或者纠正它们不正确的行为——须要了解程序在各种情况下的状态。

写代码可以将你对程序的想法具体化，但程序不能保持一成不变。你会发现 bug，想要新的特性，须要改变现有的行为。一个解决方案在一开始可能行得通，但这并不意味着它将一直是可行的。最终，你须要花天数去预测未来，去收拾烂摊子，你会不可避免地发现自己并没有千里眼。

5康威运动定律

假如你自己不写程序，就须要和其它人一起组织工作，这带来了一连串产品全新挑战。

所有参与项目的人都必须以某种方式组织起来，每个人都有自己的组织工作要做。你不希望人们互相妨碍，所以必须分工。合理的分工要求你对程序的结构有很好的理解，这个时候康威运动定律就有所作为了。

假如你有多个团队，事情就会显得更加十分困难。每个团队都有不同的目标，因此会针对不同的事情进行强化。对其它团队有利的决定可能会阻碍你顺利完成组织工作。了解其它人的立场，并找出一个好的妥协方案，这是一项艰难的各项任务，但你必须顺利完成。

在大项目中，不可能有哪个团队（更不用说哪个人）能了解所有的东西，但你依然须要弄清楚如何设计系统的各个部份，并让这些部份相互配合，这比你自己做出整座设计要十分困难得多。

6打破运动定律

我们可以尝试找出安萨尔运动定律难以有所作为的地方。假如个体各项任务的速率不是完全独立的——假如你可以透过强化一个各项任务来大力推进另一个各项任务——所以就有可能找出对你有帮助的解决方案。

更快的C语言和开发环境可能是我们可以加以利用的地方。假如程序可以由更少的人来开发——比如说两个人，而不是一个团队，或者一个团队，而不是一个部门——那就可以大大地减少组织各方面的开销。假如你自己实现接口所有的代码，就不须要透过开会来决定如何设计接口。效率的提升不仅会降低编写代码的成本，还会改变组织工作的形式，从而降低其它各项任务的成本。也就是说，这里的管制变成了你可以在这条路上走多远，即使一个程序员不可能把所有跟实现业务相关的东西都装进脑子里。

迭代速率是另一个可以加以利用的杠杆。为了开发一个程序，你须要了解这个领域的问题和须要做出哪些决定。为了顺利完成这些各项任务，你须要把收集到的所有细节都装到脑子里，接着形成一个心理模型。这是一类可行的方式，但可能不是最有效的方式。另一类方式是基于某些明显的细节建立一个小的心理模型，接着根据这个模型创建一个小程序来测试这些想法是否符合现实，并根据反馈进行迭代，每次都创建出更丰富和更准确的模型。这似乎更适合人们实际的学习方式。为了让此种方式奏效，你须要能快速测试想法并赢得反馈。理想的状态是，在你顺利完成输入后，新代码就可以开始运行。透过改变开发环境来实现更慢的迭代周期，将使开发人员从第一类方式转到第二种方式，帮助他们更快地理解问题。

一类表达能力更强的C语言是否能有效地提升生产力，对于这一点我并不是特别乐观。我希望的是能有更快的开发环境。假如我们有更快的工具来理解现有的代码，有更慢的开发迭代周期，繁琐的组织工作显得更少，就可能会改变软件的开发方式，并以一类复合而非递减的方式给我们带来回报。

原文链接：

http://jeremymikkola.com/posts/2021_01_01_why_software_development_is_hard.html

今日好文推荐

程序员的黄金黄金时代，死去又重来？

放弃大厂高薪的程序员，涌进体制内

硅式鄙视：我们还在996，他们早已连955都不要了

InfoQ 读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加 InfoQ 小助手，回复关键字进群申请入群。回复资料，获取资料包传送门，注册 InfoQ 网站后，可以任意领取一门极客天数课程，免费滴！大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！

点个在看少个 bug👇