我希望我的代码无聊

原文链接：https://dzone.com/articles/i-want-my-code-to-be-boring

今天早些时候，我正在与我的同事拉塞尔 （@RussellScheerer）谈论我们在转换计划中面临的一些挑战。

就我而言，我一直在将大量遗留的Adobe Flex代码转换为最终将在Spring Boot RESTful服务中运行的服务，或者作为AWS中事件驱动的Lambda服务。

由于拉塞尔在项目中提交了大多数拉动请求（PR），当他告诉我我的代码对他来说“无聊”时，我很感兴趣。他的评论让我有些措手不及。在我提出后续问题之前，他继续说道。

Russell指出，在大多数情况下，我提交审核的逻辑主要集中在满足客户需求的业务规则和功能上。他可以理解，在没有太多不必要的理解或深思熟虑的情况下，代码中发生了什么。他接着提到，如果他担任生产支持角色，那么理解和识别问题所需的时间非常短 - 因为我很容易遵循我建立的逻辑。

事实证明，这是一种恭维。我很自豪

我是如何达到这一点的
对我来说，我开始使用我在此项目之前没有使用的语言的大量源代码。虽然语法中有JavaScript的各个方面，但当我第一次查看代码时，Adobe Flex和ActionScript对我来说是新的。当您考虑使用前一个应用程序实现的复杂性时，结果是大量自定义代码以满足需求。经过十年的开发和维护，当前的存储库变得非常混乱，反模式仍然存在，并且妨碍了我理解代码当前正在做什么以及它应该做什么的能力。

在不止一次的情况下，我发现代码没有按照预期的那样进行操作，并添加了额外的代码以使事情重回正轨。这没有对作为问题根源的现有代码进行更改。显然，没有完全理解现有的代码库。基本上，代码“非常有趣”…与无聊相反。

从一开始，我对构建服务的方法很简单。我打算让代码尽可能易于阅读，将代码分解成可以轻松理解和重用的较小块。由于给定的原因，服务将存在，并且将建立一个边界 - 在服务中没有任何其他内容与服务所针对的方面无关。

我会在Spring Boot方面采用一些较新的Java方法，但始终将可读性和可支持性放在首位 - 就在那里专注于提供非常高效的代码。

罗素的灵感
我向拉塞尔解释了这一点，他提到了他最近观看的视频，这是JDD 2018会议的一部分。在视频中， Tomasz Nurkiewicz （@tnurkiewicz）介绍了“ 从反应式编程中学到的经验教训 ”。我建议采取罗素的建议，并在4:05标记观看，这是下面的视频应该定位的地方：

Nurkiewicz与语言无关，将常用用例从传统语言转换为被动语态。看到反应版本是非常了不起的，它几乎让每个人都知道代码实际上在做什么。除了，也许是创建代码的开发人员。

他继续说我们的代码应该专注于业务逻辑。如果我们从事保险业务，那应该是谈论政策和承保等。从代码风格来看，它应该是无聊的。这就是拉塞尔所说的，它让我感到震惊。因为这是我决定在处理从当前项目中构建新服务的混乱后所做的事情。

展望未来10年
如果您要查看我的代码，除了与集合相关的一些Lambda功能之外，我的大部分代码与使用Java 6或7编写的代码实际上没什么不同。好吧，我们正在使用服务器做一些有趣的事情-发送事件（SSE），但我们已经抽象和分割了这些项目 - 提供了一个易于使用的界面来发送，接收和处理这些SSE。

经验丰富的QA团队成员可以查看我的代码并弄清楚它在做什么。这里没有很多“有趣”的东西，因为这样做只会以一种并非真正需要的方式增加复杂性。

另一方面，如果我以反应式方式重写所有内容，我会转交一系列服务，这些服务无法由客户端的生产支持团队支持。我会介绍一些新的术语和概念，这些术语和概念在10年内可能不会受欢迎（甚至可能在周围）。有趣的代码往往不会经得起时间的考验。

相反，我应该专注于编写首先尖叫业务逻辑并最后设计/接近的代码。

我希望在十年内编写仍然无聊但很容易理解的代码。

结论
如果你发现自己处于我的一个PR的另一端，我完全希望你在看到我大部分时间使用的Java语言的各个方面时打哈欠。但是，我完全希望你能够理解正在发生的一切。如果您的朋友（他是QA /测试人员）恰好浏览了您的屏幕，他们也应该能够了解正在发生的事情。

我希望我的代码很无聊。我不想让你说，“这很有趣。” 因为，每次在我的职业生涯中，我的反应都与Tomasz Nurkiewicz在视频中所说的一样…“这是一个非常糟糕的迹象。”

（想自学习编程的小伙伴请搜索圈T社区，更多行业相关资讯更有行业相关免费视频教程等待你来学习。完全免费哦! ）