🧠 如何不用大脑成为一名优秀的软件工程师。

编辑：现在也可以在我的博客上找到。

我选择懒人来做难事。因为懒人总能找到轻松的方法。——比尔·盖茨

本文旨在教您如何以最少的努力做好软件工程师的日常工作。

虽然我相信这篇文章对大多数读者来说都会有一些有趣的信息，但对于那些患有注意力缺陷多动症的人来说，它尤其值得一读。如果你认识有这种情况的程序员或有志于成为程序员的人，分享这篇文章或许能帮助他们（也包括我自己）。

我们开始吧。

I - 用脑有害

我不喜欢用脑子。

原因在于，动脑子很难。大多数人会经常避免做那些困难的事情。如果你不用费力就能做得很好，那你为什么要这么做呢？难度并不会给你加分。

当你不再感到痛苦时，工作满意度就会提升。你的精力会保持旺盛，工作效率也会提高。

用最少的力气获得最高的效率，有一个秘诀，叫做“巧用之”。武术家通过对对手的敏感点施加高压来获得高效率。这真是个巧妙的技巧。

那么我们就聪明一点吧。

II - 问题：软件工程很复杂。

好吧，那我们就把它简单化，这样我们就不用想太多了。

事实证明，这项任务也是对软件工程师工作最好的描述：降低复杂性。

复杂很糟糕。非常非常糟糕。你的工作就是让一切尽可能简单。正如我们稍后会讨论的，这才是你真正需要聪明才智和动脑筋的地方。

我们通过编程实践和工作方法来实现简化。以下是一些示例：

编程实践：
优雅、高质量的代码。遵循最佳实践。在合适的时机使用合适的 OOP 模式，在合适的时机进行函数式编程。重构。避免技术债和意大利面条式代码。你明白我的意思了，但这不是本文的主题，我们接下来会讲到：

工作方法
让我们探索一些可以帮助您节省所有宝贵脑力的工作方法。

III-何时认真思考，以及如何认真思考。

你会注意到，我将要详述的方法论并非真的要求你不去思考，而是要求你在恰当的时机认真思考。

我确实相信“很困的时候才睡，很饿的时候才吃”这句话有道理。我还想补充一句：“只有在真正需要认真思考的时候才认真思考”。

知道何时认真思考并真正认真思考是构建优秀软件的关键。

以下是实现伟大思考的两种伟大工作方法：

深度工作：正如卡尔·纽波特（Cal Newport）在他（令人惊叹的）书中所解释的那样，这一切都是为了通过高度集中来最大限度地提高工作效率。

番茄工作法：通过将你的工作分解成小段时间并将其与深度工作相结合，你实际上可以实现最佳工作效果。

请随意研究这些主题，因为我不会在这里详述。我们将重点放在何时使用大脑，而不是如何使用大脑。

IV-适合愚蠢和懒惰的人的工作方法。

原子 Git 提交

使用 Git 的方式可以迫使你更高效地运用大脑。我强烈建议你阅读链接的文章，它很好地解释了其中的原因。

要点是：使用 Atomic Git 提交会迫使您在脑海中以小步骤映射实现目标所需的精确提交套件。

把大任务分解成更小、更简单、更轻松的步骤？这就是降低复杂性的经典秘诀！

这种方法的难点在于，你必须一开始就付出心理成本。正如人们所说，“一周的编码时间可以节省30分钟的规划时间”。然而，由于思考本身就很费劲，我们往往不会这样做。这是错误的，因为你以后必须付出相应的代价。

一旦你把任务分解成更小的步骤，你就可以关掉你的大脑了。你不再需要那袋肉了。

BDD，而不是TDD。

所以我绝对不是来这里交朋友的（你好，ThePrimeagen，希望你也喜欢这个），因为这是一个非常有争议的话题。这有点跑题了，但我觉得这很有趣。免责声明：这只是我的观点，等等等等。

我坚信行为驱动开发是一个令人惊叹的工具，它可以让你在获得高质量代码的同时尽可能少地使用大脑。

我使用术语“行为驱动开发”来解决对测试驱动开发的一个常见批评，即“你一开始不知道你想要什么，所以在进行 TDD 时，一旦你知道你想要什么，你就必须重写你的测试”。

我认为 TDD 的反对者和支持者之间存在误解，而这种误解可能源于对 TDD 和 BDD 的混淆。

TDD/BDD 的支持者们听到的往往是：“我不知道我应该满足哪些规格要求”。这听起来很荒谬：如果你不知道自己应该实现什么目标，你绝对应该去动动脑子，直到明确你的规格要求为止。

TDD 的反对者实际上说的是：“我不知道怎样的步骤才能让我满足我的要求”。

它们之间的区别基本上在于单元测试。当然，在编写代码之前，你很少知道代码的细节会是什么样子，所以如果你只对一小部分代码（比如方法）进行单元测试，你最终会重写大量（大部分是无用的）测试，这会很痛苦。

我认为，在面向对象编程 (OOP) 环境中，测试的最小单位通常是类。如果你对代码架构进行了足够深入的思考（例如，当你将任务分解成更小的步骤时，可以参考Git 原子提交），你就会知道每一步都需要哪些类。

因此，您永远不需要重写任何东西。

正如我之前所说，我确实相信在进行任何编码之前你应该仔细思考，至少直到你确切地知道你的规格是什么，包括对可能的边缘情况进行认真思考。

这就是 BDD 的精髓：认真思考具体的规格要求，并先将其编码。你知道自己想要什么，一旦将其写入代码，你只需要确保规格要求能够顺利通过即可。

坦白说，一旦你的规格写好了，你就可以关掉你的大脑了。剩下的工作几乎不能称之为“工作”。

结论

希望这篇文章能给你带来一些启发。如果你觉得这篇文章能帮助别人减轻日常软件工程的负担，请随时分享。

至于讨论支持或反对 TDD/BDD，评论部分就在那里👇。