写代码能让你目前对程序如何工作的想法更加明

如果有更好的编程语言，软件开发就会更简单、更有效。这一观点在汇编和Fortran时代无疑是正确的。但现在语言已经足够好了，可以在其他地方发现主要的困难，从而找到改进的机会。虽然程序设计还是很困难，但和所用语言无关。

阿姆达尔定律适用于你有一系列连续任务的情况。这告诉我们，只通过加速一项任务，就能对整个系列任务的执行速度进行严格的限制。

假定煮沸10分钟后再煮一次意大利面条。假如你想找出一种方法快速煮开水的话，那你晚餐一定不会比面食少10分钟。强力燃烧器绝不会提供超过2倍的加速比。

一般的公式是，如果某物占据了总时间的p的一部分，那么你就永远不能得到大于1/(1–p)的加速比。若工作的一部分占90%,p=0.90。对零时工件进行优化，整体工作速度提高1/(1–0.90)=10倍。

Amdar定律的关键是，要得到最佳的加速，必须受要优化的零件尺寸的限制。

编程是困难的，原因有很多。要简单起见，我们可以把难以处理的事情看作是必须按顺序执行的任务。说到底，人并不擅长多任务处理。无论何时，你都可以使用构建工具，阅读文档，编写代码，或者参加会议。或是写代码而不是参加会议。我们每次都要面对一个挑战，所以Amdar定律基本适用。假如您能够将构建时间降低到零，那么您的项目只能更快地完成。您的工作效率仍然受到完成这个项目所需要的其他因素的限制。

以前，把程序计划转换成计算机能运行的东西是很困难的。在很久以前，这包括把程序转换成1和0，并且非常麻烦地输入它们。我不知道要花多少时间，但为了证明(和简单的数学操作)，我们假定90%的编程工作都是这样。也就是说，告诉计算机做什么(比如Python)更好的方法能让编程效率提高10倍以上。

但现在我们拥有了更好的语言不需要太多时间告诉计算机做什么-我们预计生产率会提高。把计划转化成代码不再需要90%的时间。目前(又一次辩论)只需要10%的时间。这就是说，简化零件所能得到的最大改进值现在只有1.11倍。现在的速度是过去2倍的81倍！

那是因为其他90%的软件开发工作是困难的，更好的编程语言(直接)不能让这件事变得简单。

为何编程依然困难。

怎么没有朋友啊？

这意味着编程很难独立于编程语言之外。为了解为什么会这样，我们首先假定与电脑有关的事情并不需要担心，你只需要告诉你的朋友们要做什么。不要欺骗他们，不要让他们依赖常识性的东西，你必须为他们做所有的决定。

您将发现解释关键的背景信息要花费很长时间。您的朋友需要了解程序可以在真实世界中使用的东西(“好，我们把这些东西叫做捆绑商品，您可以购买捆绑商品中的所有产品并获得折扣”)，以及您拥有的东西决定了程序应该做什么(“如果用户只返回捆绑包中的一个…”)。要对缩略语和术语进行解释，还要讨论外部因素(“生产商规定我们出售产品的价格是不合法的，但并不是由他们来决定我们宣传产品的价格，所以…

您的朋友需要了解所有可能发生的情况，需要处理许多小细节，比如用户不能在购物车中输入负数产品。使用者可以尝试所有可能的动作，可能会发生各种各样的事情，比如包裹在运输途中丢失，你会发现有很多边界情况需要告诉朋友。

向你的朋友们解释这些困难有几种不同的方式。第一，你必须了解所有与这个计划有关的实际细节(一些产品可能会脱销，可以打折，等等)。第二，你必须理解所有关于在每种可能的情况下，程序应该做什么的决定。最后，你要用朋友们都能理解的方式来表达这些信息。意思是说，你需要适当地组织想法，让他们容易理解。写一篇论文或博客文章，你就会知道传递大量信息并不容易！

值得注意的是，到目前为止，还没有任何工作涉及到计算机或编程语言。要了解这个世界是如何运作的，知道程序应该做什么以及如何组织这些思想的表达，是很困难的。

说明和说明。

这是一个很容易陷入的心理陷阱。描述和说明事物之间的差别是很容易忽略的。通过描述(“红色的汽车”)，你可以检验东西是否与描述相符(“红色的汽车，而非汽车”)，但这还不足以告诉你怎样做一辆车。那是规格说明。

做事情要做许多决定。若记录每项决定的结果，就会出现(混乱的)规范。写程序需要你做这些决定，所以只靠描述是不行的-你需要一个规范。如果您有一个描述(“它应该列出文件”)，那么很容易将其视为一种规范，因此应该很容易让计算机进行操作。但你忽略了要做的数以百万计的小决定(“文件应该按什么次序列出？他们各按一条线走好吗？

在写程序的时候，无论在什么地方，你都得面对，你的规范只是一个描述。电脑不会只接受“画一个矩形”，它会想知道它应该出现在屏幕上的什么地方，应该有多大，用什么颜色制作。把思想转换成代码常常会暴露你还没有做出的决定。作出这样的决定是很大的努力。要把这一努力的源头搞错，把责任归咎于编程语言，要比承认一个简单的事实更容易，那就是仅仅提供描述就很难创建规范。

继续用电脑。

开发软件不只是理解软件的功能，把想法转化成代码。电脑本身产生了程序必须解决的自身问题。您的程序必须在实际硬件和网络中运行得足够快。这个程序可能需要处理机器故障。复杂的工具和协议给这个领域带来了更多的问题。这并非由于向计算机解释操作过程而造成的困难，而是因为需要更多的解释。

您还必须在头脑中运行部分程序。有时候，逻辑流程和故事一样容易遵循，但有时候，事件的次序和要跟踪的状态会完全淹没你所能适应的。要正确理解程序的细节，或者是在错误的情况下进行修正，就必须理解不同情况下程序本身的状态。

写代码能让你目前对程序如何工作的想法更加明确。但是这并不意味着程序会停止改变。您将发现错误、需要新功能以及需要改变现有行为。这个计划一开始可能会很有条不紊，但这并不意味着它永远都是正确的架构。如果你发现自己并不是千篇一律的，那么你最终会花时间去尝试，包括预测未来，清理剩余的杂乱。

团体工作。

要想写出你自己的程序，就得和别人合作。它带来了全新的挑战

该项目中的所有人员必须以某种方式进行组织，每个人都有自己的任务。你们不想让别人妨碍对方，所以你们要分担工作。制定合理的分工需要理解程序结构。适用康威定律。

假如你是多个团队的话，情况会更糟。每一个团队都有不同的目标，所以要针对不同的情况进行优化。一项有利于其他团队的决定可能会妨碍你的工作。要知道对方在什么地方，然后找出一个折中的办法，是一件很困难的工作，但是必须要做。

大项目中，没有一个团队能够理解全部的事情，更不用说一个人了。然而，您仍然需要找出如何设计系统的部件，并将这些部件组合起来。它比您自己创建整个设计要困难的多。

即便在实际编写代码的几个步骤中没有人参与，与人打交道仍然是软件开发的重要组成部分。

怎样破裂？

我们可以找到超越阿姆达尔定律的方法。假如一个任务并不完全独立——如果你可以通过优化另一个任务来加快它的速度——希望技术解决方案能有所帮助。

语言和开发环境的改善可能是我们需要的漏洞。若让程式以较少的人来写(例如，两个人代替一个团队，或一个团队代替一个部门)，就可以极大地降低组织的开销。假如你是父母