货物崇拜式编程！

我正在观看/收听Simon Brown在 GOTO 2018 大会上关于模块化单体架构的精彩演讲。

他提到了一个叫做“货物崇拜式编程”的术语，这真的引起了我的共鸣。

我最近加入了一家新公司，公司采用新的编程语言、新的工具、新的流程，还有一个新的团队。实际上，几乎所有的一切都是“新的”。

这促使我近几个月来进行了大量的学习。由于我经验相对丰富，所以在学习新事物时，我更喜欢探究“为什么”，而不是“怎么做”。但我发现，这并非最常见的学习方法。

当用户被要求在现有代码库中添加功能，扩展现有解决方案时，他们很可能会先查看之前是如何实现的，然后照搬之前的做法。他们可能会盲目地遵循这种模式，因为以前就是这么做的。就像在塔顶不断添加新的模块一样，他们不会质疑这样做是否正确。如果每个人都这样做，最终就会出现这种情况。

这就是“货物崇拜式编程”一词的由来。

维基百科是这样解释的：

“货物崇拜式编程”是一种计算机编程风格，其特点是机械地将一些毫无实际用途的代码或程序结构复制到代码中。这种编程方式通常表明程序员既不理解他们试图解决的错误，也不理解表面上的解决方案（参见“乱枪式调试”和“深奥的魔法”）。^[1]当一个不熟练或新手的程序员（或对当前问题缺乏经验的程序员）将一些程序代码从一个地方复制到另一个地方，却几乎或完全不理解这些代码的工作原理或它们在新位置是否必要时，就可以使用“货物崇拜式编程”这个术语。

“货物崇拜式编程”也可以指盲目地应用某种设计模式或编码风格，而不理解其背后的原理。例如，在不言自明的代码中添加不必要的注释、过度遵循某种编程范式的惯例，或者为垃圾回收机制会自动回收的对象添加删除代码。

常见问题？

想象一下这样的场景：你正在修复一个 bug，寻找导致故障的代码。你不太确定发生了什么，所以你；

1. 用谷歌搜索这个错误。
2. 你找到了一个 StackOverflow 上的问题。
3. 找出点赞最多的答案。
4. 复制并粘贴解决方案到你的代码中。
5. 尝试调试一下，看看是否能解决你的问题。

已经办好了，所以你办理入住手续，然后继续前进。

听起来是不是很熟悉？

我们为什么要这样做？为什么我们要盲目地直接使用这段代码片段，并将其原封不动地应用到我们的实现中？

使用场景可能不同，所以解决方案相同我会感到惊讶。抛开简单的例子不谈，理解解决方案背后的原理比解决方案本身更重要。如果你不理解某个东西，很多事情都做不了。你无法修改它、改进它或测试它。你无法编写文档，也无法拥有它。

技术趋势、流行语和微服务

我们都喜欢新鲜事物，管理层尤其喜欢追随流行趋势，紧跟技术进步的步伐。

现在大多数团队都会采用敏捷方法。测试驱动开发 (TDD) 和自动化测试在某些情况下非常有用，持续集成大大减轻了基础设施团队的负担，大数据和人工智能可以显著提高用户满意度，而容器化以及最近兴起的微服务则将我们原有的单体架构转变为更小、更独立的服务。

这些技术进步本身都很出色，但我并不赞同其中任何一项。我的困惑在于，我们是否需要将它们全部应用到所有流程和代码中？我们看到Netflix、Facebook和Twitter等公司都在博客文章中展示了这些技术的使用如何改变了他们的工作方式。如果大公司都认为这些技术是必要的，我们难道不应该也这样做吗？这正是盲目照搬技术编程的弊端再次浮现的地方。

我们需要了解当前设计存在的问题，探究其成因，并思考如何才能在未来彻底摒弃这些问题。诚然，这些新流程或许能帮助我们解决问题，但盲目地照搬并寄希望于它们有效并非正途，也毫无逻辑可言。

我之所以特别提到微服务，是因为很多公司似乎都在进行转型，并列举了以下优势：

• 更快的开发速度
• 高可扩展性
• 易于增强
• 易于部署
• 拥有自主选择权的技术团队

有了这样的清单，还有什么好犹豫的呢？让我们都加入进来吧！

等等……这种方法有什么缺点吗？

• 建筑复杂性

在单体架构中，复杂性和依赖关系的数量都集中在代码库内部；而在微服务架构中，复杂性则转移到实现特定领域的各个服务的交互上。

• 运营复杂性
  • 如何以可扩展且经济高效的方式配置资源
  • 如何在不增加工作量的情况下高效运维数十个或数百个微服务组件
  • 如何应对缺乏标准以及包含不同技术和技能水平各异的人员的异构环境
  • 如何处理版本控制
  • 如何跟踪和调试整个系统中的交互
  • 如何跟踪数百个代码部署管道及其相互依赖关系

这些内容摘自亚马逊的白皮书《微服务的挑战》。我不知道你怎么想，但对我来说，它的缺点远比优点可怕得多。我再次强调，我并不是说这种方法不对，但除非这些优点能抵消缺点，否则你采用这种方法又能获得什么呢？

“公众”问题。

其实很简单，停止使用public关键字，停止自动创建public类。我们为什么要这样做呢？

使用 `public` 关键字的问题在于，你会错过封装带来的好处。为什么我们如此频繁地使用它？因为它几乎成了我们创建类时的默认用词，所有示例都会使用 `public` 类，向导和​​代码片段也会实现 `public` 类。是时候改变这种做法了。有多少人拥有公开的 Facebook 账号？世界上大多数事物都是私密的，我们的类也应该如此。默认将它们设为私有，如果需要公开，再进行更改。

丰富的经验往往伴随着深深的忧虑。

在某个领域待的时间越长，你对新工具或新流程带来的改进就越不会抱有天真的想法。如今的大多数理念都源于几十年前对该领域的研究，而这些研究成果最终才被广泛接受。一旦某种事物被大众接受，人们就更容易欣然接受它。当然，前提是它确实是正确的做法。

良好的判断力来自经验，而经验来自错误的判断。

丽塔·梅·布朗

所以，请继续在互联网上搜寻问题的解决方案和教程；继续探索新的语言、框架和实现方式。但要注意它们为什么有效，而不仅仅是如何运作。我们都从自身的经验和错误中学习，因此理解基本原理可以避免你将来重蹈覆辙。