编写软件时如何胜出：汽车类比-CSDN博客

我意识到一个通用的类比将是帮助非工程师和非开发人员的有用工具……为什么不买车呢？现代车辆是工程学的壮举。以70英里/小时的速度从高速公路上驶下意味着必须消除各种振动和有害振动，以防止车辆自毁。像我的卡车这样的现代车辆实际上具有类似于LAN的网络，称为CAN（控制器局域网），该网络将传输和无线电之间的所有内容连接到一条数字总线上。很多研究和开发都投入到制造汽车中，那么与软件开发相比又如何呢？对车辆进行工程设计有很多阶段，早期阶段是定义，计划和试验。让我们专注于其中一些。

定义

任何开发过程的第一步都应该是定义，或为问题空间创建词汇表。目的是确保每个人都在谈论同一件事。例如，在Web应用程序开发中，用户和客户可以是不同的人！

在设计汽车时，有驾驶员，乘客，方向盘，电子刹车等等。在开发生命周期中必须始终使用这些术语。必须寻找和消除歧义。例如，驾驶员也是乘客吗？还是驾驶员和乘客都是乘员？敏捷方法论者掩盖了这一关键步骤，他们希望立即着手进行编码。

埃里克·埃文斯（Eric Evans） 撰写的《域驱动快速设计》 （ Domain Driven Design Quickly）是有关如何创建商务词汇的大量（免费）资源。埃里克（Eric）逐步创建了空中交通管制系统。在介绍任何DDD概念之前，几乎整整一章都在定义空中交通管制生态系统中的角色，名词，动作和关系。

如果您不是工程师，则应要求开发人员与您一起创建此词汇表。您痛苦地意识到，与开发人员交流想要的东西很困难。创建词汇表是一个交流渠道。没有它，不要直接进入开发或设计！

规划

通用汽车让汽车工程师设计雪佛兰Volt时，他们不太可能在板上贴上一堆便笺，上面写着：“用户应该能够将汽车转向特定的方向，”然后故意跑开，然后建造从现代液压执行器中取出转向齿条。后来，在第25冲刺中，当他们开始制造引擎时，他们意识到液压转向齿条并不是电动汽车的理想选择。事实证明，液压系统需要来自旋转泵的恒定压力，而电动汽车的电动机并不会在红灯下旋转。

他们也没有花8年的时间在纸上画画，而是开始制造汽车。每次设计车辆的组成部分时，他们都必须更改其余车辆的计划。他们的设计是迭代的，如果您查看早期的原型，它们看起来与最终产品完全不同。

两种极端情况都不是健康的，不幸的是，敏捷开发人员往往希望在不考虑全局的情况下快速上手。老派瀑布开发人员喜欢认为，一旦制定了计划，就永远不要更改它，并且还认为他们可以预见特定设计会出现的所有问题。

软件工程师应该处于中间位置。在完成用户故事后，应开发一个域模型，以显示对象属性以及它们与域其余部分的关系。在创建域设计之后，应制定体系结构计划，以显示对象如何在系统中存储，处理和改组。此时应引入诸如日志记录，监视和审计之类的跨领域问题。

不幸的是，对于非工程师来说，这里并不容易。您的开发人员应该有一个技术计划，并且他们应该能够以您理解的方式向您解释。每次迭代都应更新和更改技术计划和模型。如果您的开发人员实际上在两次迭代之间保持相同的技术计划，那么这应该是一个危险信号：没有人第一次就能正确地做到这一点。在开发期间，您的工程师会遇到团队根本没有想到的业务场景和技术问题。如果您真的只是“错了”，那么每次迭代都应该是一种改进，甚至是路线图的更改。

实验性

就像我之前说的那样，通用汽车直到花了8年的时间才把设计图纸画在纸上，直到他们认为解决了所有可能浮出水面的问题。在他们定义了词汇表并提出了基本设计之后，通用汽车使用各种测试平台在现实生活中对25种不同的电池化学成分进行了实验，以验证其设计。事实证明，有些制造商不知道他们的电池容易爆炸。

研究和开发实际上是您可以免税的东西。研发应该在每次迭代的开始，设计之后，开发之前进行。创建，测量和分析特定设计的性能，生产率和可维护性将帮助您清除昂贵的错误。开发人员应专注于制定特定的目标，并与同行有效地交流他们的工作，做事的原因以及发生的事情。 Wiki是存储R＆D结果的好地方，以后，当创建税收冲销时，会计可以显示实际R＆D已完成。

这是开发人员喜欢的领域，业务经理也不了解。业务经理倾向于认为，在应执行“实际工作”实施要求时，玩闪亮的开发玩具是浪费时间。（如果您在这样的公司工作，我建议您辞职。这类工厂值得人才匮乏，不值得为之工作）

确保完成实际工作的诀窍是对研发进行时间限制并设定目标。首先应定义特定的目标，然后根据实验比例分配适当大小的时间范围。具体目标可能是评估一个框架相对于另一个框架，或评估一个设计相对于另一个框架。大型研发箱应在项目开始时分配，而小型研发箱应在项目结束时分配。同样，这里的目标是避免浪费。主动而不是被动，尽管违反直觉，只会使您的项目成功。

……有些事情我们现在知道，我们不知道。但也有未知的未知数。有些事情我们不知道我们不知道

-唐纳德·拉姆斯菲尔德（唐纳德·拉姆斯菲尔德）

研发的最终目标是发现您不知道的东西。主动发现故障可以节省您的时间，并使开发人员感到满意。

结论

“编码”和“工程”之间的区别在于工程要具有确定性和可预测性。编码人员倾向于直接跳入事情而不考虑长期的业务目标，然后在遇到困难时跳船。解决方案是遵循工程生命周期的所有步骤，同时产生工程工件，例如模型和计划。最后，就像汽车一样，模型和计划也需要维护，并且应在工程生命周期内经常进行更改和升级。

参考： 编写软件时如何胜败：来自The Code Mechanic博客的JCG合作伙伴 Jonathan Fisher的汽车类比。