https://www.freecodecamp.org/news/the-hero-developer-who-knew-how-to-build-lego-bricks/

编程就像用乐高积木一样。任何开发人员都可以选择全新的LEGO集并按照说明进行构建。这很容易。可以将其视为编写学校作业或入门级教程的代码。

真正的软件项目是不同的。这就像建造一个非常大的城堡。除了过去已经建造过。然后有人用野蛮的脚把它撕成碎片。较大的部分仍然保持在一起。但是较小的部分被完全压碎了。一些元素消失在窗外。

您会得到一个盒子，里面装有剩下的东西，还有数千套其他物品。当然，指示也消失了。您只能依靠一张照片来了解城堡的外观。

现在很有趣！让我们看看在这种环境下如何有效工作。

1.接受未知

任何开发任务的第一步都是了解您需要做什么。听起来很明显。但是，任务越大，您获得的未知变量就越多。这是树立明确期望的时刻。

如果您不知道如何入门，那么思考和概念化的时间就太长了。开始并掌握所需的关键要素。然后再想一想。如果有人要求您提前估算或最后期限，请保持坦诚。您不了解或可能不了解的系统某些部分。没关系。

考虑一下Facebook，Netflix或Oracle等平台。或任何更大的企业软件。很少有人能够掌握全部范围。确实已经构建或花费了数年时间的人们。因此，首先，让自己休息一下，不要一无所知。更重要的是，接受您不会一无所知。

经验丰富，生产能力强的开发人员不是更好的程序员。他们更擅长评估他们需要做什么。并选择正确的策略来应对未知数。

乐高类比：想想我们要重建的城堡。假设有人给您一张城堡和盒子的图片，然后问您“建造城堡需要多少时间？” 除了“我还不知道。让我开始并看看一两天后我在哪儿”，对此没有好的答案。

最终完成这项工作的“我害怕未知数”方法是将所有元素从地板上的盒子中放出来。尝试根据颜色和形状将它们分成所属的组。然后看图片，并就如何组装积木制作一张心理图。

这种方法不是很有效，原因有两个。首先，如果城堡太大，您可能永远都无法到达那里。第二点也是最重要的一点：您无法评估进度。您可能走在正确的轨道上，或者根本不走。您没有反馈回路。

另一种方法是开始建造城堡。随着您的前进，您将了解找到所需零件的便捷性。您将知道图片是否显示了所有细节，或者结构是否比看起来复杂。

根据这些信息，您可以对完成这项工作所需的时间和精力做出更有根据的猜测。如果值得一做。

如果您需要明天早上建造它，也许去商店再买同一座城堡是更好的解决方案？这可能不是您的决定，但是解决问题并不总是通过更多代码来完成。

2. 接受妥协

开发人员经常称赞和重视“对细节的高度关注”。那里的每一份工作都以一种或另一种形式提供。很好 但是不要将对细节的关注与固执和完美主义相混淆。

启动大任务时，必须定义它的两个版本。第一个版本是您需要验证事物是否按照您认为的方式工作的最低要求。

这就是我所说的“水平工作”。您较大的任务中的每一项都是垂直的。您无需深入研究即可获得第一个结果。首先关注主要用例或方案。并从那里拿走。  

您可以在第一个版本中留下的东西：

• 错误处理
• 边缘情况
• 干净的代码
• 组态

不用考虑所有这些，只需编写所需的代码即可。您应该快速获得较高的功能覆盖率。当然，从第一个简单的版本过渡到最后一个版本将花费很多时间。那有什么意义呢？

这是一种更安全的进步方式。您想验证您的假设。设计和概念化虽然像您一样聪明又有能力，只能带您走远。弄脏你的手。它比任何“深入研究”都给您更多的知识和见识。

这与应用于业务中新产品或功能的MVP的原理相同。该方法还具有可以显示您的第一个版本并获得反馈的优点。或问问题。在现有代码上集思广益比在图形或概念上集思广益。  

乐高类比：您正在建造城堡塔。在图片上，高塔墙由交错的灰色和白色砖块制成。塔中有一个公主，屋顶上有一条巨龙。

您会找到公主和巨龙，但要找到所需的灰色和白色砖块可能要花很多时间。正确的方法是使用任何砖块建造墙，然后放置公主和龙。您可以留下“改善墙砖”之类的待办事项。

想法是您已经确定了一个问题：建造完美的墙将很困难。让我们接受这一点，继续发现我们尚不了解的所有其他障碍。接受妥协可以防止您陷入困境。

即使您从未到过TODO，也可以告诉您的客户：“这里是完整的城堡。我们知道我们必须改善塔墙，但它已经建成”。这比“由于我们花了很多年才能为塔找到合适的砖块而拖延的时间要好得多。但是，看一下，塔是完美的，并且与您发送给我们的图片完全一样。现在，我们将继续其余的内容。城堡”。

重要提示：不要混淆妥协和草率。

塔的主要元素是公主和龙。不要在塔上放一个农夫，在屋顶上放一只猫，不要以为这是个妥协。它不会工作:)

3.从外部世界开始

您可以控制很多事情。还有你做不到的事情。十年前，我了解到这是我作为开发人员的第一个任务时遇到的困难。任务是集成外部API并处理数据。我有一个星期。即使对于像我这样没有经验的人，这也是一个非常合理的时间表。

这是我所做的（以及您不应该做的）：

今天是星期一早上。我已经阅读了10分钟的API文档。看起来很容易。我创建一个测试数据集，然后继续编写代码以对其进行处理。完成后，我将使用真实的API进行测试。

星期三早上，我快完成了。我认为我的代码干净，设计良好，而且一切正常（事实并非如此）。现在，我只需要集成API，就可以提前完成。我不禁以为“我很棒”。

我很快进入了API部分。我正在尝试通过我的代码来达到目的。除了我不能。出了点问题。我浪费了一整天，仔细检查了一切。使用不同的API客户端。没有进展。那天闪烁着，现在是星期三晚上。

我被困住了，感觉与真棒相反。

我星期四上班，请同事帮忙。他告诉我，对API的访问可能受IP限制，因此我必须与该公司联系以将我们的IP列入白名单。好，我有前进的方向。

我向拥有API的公司发送电子邮件。就像早上8点。我愚蠢地期望在几分钟之内得到快速答复和解决。我整个上午都出汗，中午终于拿起电话，打了支持电话。我会解释我的问题，并尽最大努力突出它的“紧急”程度（不是）。

另一端的人向我解释，白名单的时间通常为1或2天。现在我很沮丧。1或2天？这怎么可能？我的任务是世界上最重要的任务（当然，仅对我来说），它们告诉我“ 1或2天”吗？

突然我不再领先了。我迟到了。我失败了。我去找老板，告诉他我搞砸了。我应该在星期一早上检查一下API。然后，我将在同一天请求访问权限，与此同时，我将编写代码。他只是笑着说“是的”。

我终于在星期五获得访问权，并且必须待得很晚才能完成工作。我使代码适应API数据带来的许多惊喜。再见，精心设计和简洁的代码。我稍后将说“没有时间”（有）来说明这一点。

在我幼稚的时候，我觉得访问和错误的文档是很不幸的。现在我可以说这是照常营业。

本课将从您无法控制的内容开始。确认您对环境的所有假设。使用手动和低成本方法尽早尝试。

乐高类比：想象您正在建造城堡，并且一切运行顺利。您现在已经将盒子混合了大约100次以寻找零件。您不禁会想：“我从未遇到过坐在照片塔上的那条巨大的橙色龙”。

您忽略了这些信息，而只关注于自己取得的良好进展。那是人类。前进比处理问题更令人兴奋。最后，您必须确认龙不见了。并非常晚地告诉您的客户，该套装中的较大部分将不存在。这不好。

相反，要做的是遵循该提示：“龙在哪里？”。花费时间来确保100％不存在。立即提出问题。告诉您的客户：“嘿，盒子里没有龙。我不能用其他砖头来补龙。我们该怎么办？”

当人们足够早地知道问题时，他们会惊讶地接受问题。尽早发现问题可以提供更多可能的解决方案。“我们继续知道没有龙吗？” “我们可以单独买龙吗？” “我可以在盒子里看到恐龙。我们可以代替它吗？”

4. 划清界限

当您开始为现有系统开发新功能时，请先定义其与现有代码的接口。当然，您应该尝试并遵循SOLID原则等。但是关键部分要比这简单。只需尝试使接触表面尽可能低。

清晰定义切割的简单过程将改善您的解决方案。这将迫使您解决以下关键问题：用户或系统将如何使用我的代码？ 我将得到什么输入？我应该产生什么输出？它可以帮助您将视线保持在球上。

如果您对正在使用的系统不了解，那就更是如此。这是一个很好的机会，可以探索未知的事物，然后再深入了解您已经知道的事物。

它还使打开或关闭该功能变得容易。您可以使用布尔标志或更高级的功能切换机制。

乐高类比：假设您需要建造城堡的延伸部分。要求很高，所以有很大的创造空间。但是您无法触摸现有的城堡。

您可以去建造一个不错的扩展，只是发现没有空间将它连接到城堡的任何地方。那真不幸。您必须快速更改扩展名以使其适合。

正确的方法是首先考虑触摸表面。扩展名将在城堡的哪儿？我可以将哪些砖块贴在上面？他们有什么形式？将延伸部分的几块砖放在一起，将其连接到城堡。验证它们是否插入牢固。您可以从那里自由样式化任何所需的扩展。

5.不要太干

DRY代表“不要重复自己”。这可能是最容易遵循的规则。一旦看到重复的代码行，就进行抽象。可以是基类，也可以是辅助方法。

那会发生什么呢？下一个人来了，需要更改通用代码以涵盖更多情况。它们添加参数和if语句以应对新出现的复杂性。很快，最初的5条简单行变成了30条行，很难弄清楚正在发生什么。

可读性差并不是代码重复的好方法。

最好保留重复的行。然后，您可以随意更改每个实例。

下次您到达“抽象的重复”时，问问自己：您看到某人从抽象中返回了多少次？就像删除基类，然后将通用代码放回继承类。我敢打赌答案永远不会。

原因是抽象和设计模式通常很酷而且很复杂。如果存在，那么“一定有一个很好的理由”。因此，一旦您引入了抽象，就很有可能将其永久保留在那里。

这是否意味着您不应该使用抽象？否。满足需求的用户抽象。像：

• “我们希望使用输入输出记录对此方法的每次调用”
• “我们想用数据a，b，c记录每个HTTP请求”
• “每次创建用户时，我们都需要这样做

这些是抽象的良好候选者，还有更多示例。但是请注意，与业务相关（日志记录，安全性，分析等）相比，这些要求的技术性更高。很少有抽象友好的需求成为您的业务领域的一部分。

为什么？因为业务领域接近于现实世界。而且我们无法控制。在项目开始时所做的假设往往很快就会落空。不要为了避免重复而过度使用工程师代码。

乐高类比：无。乐高积木没有干的概念。

外卖

聪明地工作与更好的代码无关。它是要弄清楚需要做什么，并安全地朝着目标前进。

艰巨而艰巨的开发任务将带来未知数。接受它。学习使用它。

如果您使事情变得简单，并使您的团队，老板，客户以及理想的所有人对结果的期望保持一致，那么您将更有生产力。

谢谢阅读！

最初发布在Fire CI博客上。