货物崇拜编程–克里斯·贝特朗–中

我正在看/听西蒙·布朗(Simon Brown)在GOTO 2018的Modular Monoliths上的精彩演讲。

在此他提到了一个名为“ 货物崇拜编程的术语,这确实引起了我的共鸣。

我最近以新的编程语言,新的工具,新的流程和新的团队加入了一家新公司。 实际上,几乎所有东西都是“ 新的 ”。

这使我最近几个月学习了很多东西。 由于经验丰富,我喜欢在学习新事物时关注“ 为什么”而不是“ 如何” 。 我已经意识到这不是最常见的方法

当用户承担添加到现有代码库,扩展当前解决方案的任务时,他们很可能会检查以前的工作方式,并复制其解决方案的方法。 他们可能/将盲目地遵循这种模式,因为以前是这样。 无需怀疑这是否是正确的事情,即可在塔顶上添加其他块。 如果每个人都这样做,那最终将发生。

这就是术语“ 货物崇拜编程 ”的来历。

维基百科是这样解释的:

货物崇拜编程 是一种 计算机编程 样式, 其特征在于仪式性地包含没有实际目的的代码或程序结构。 货物崇拜编程通常是程序员不了解他们试图解决的错误或表面上的解决方案(比较 shot弹枪调试 深度魔术 )的 症状 [1] 当不熟练或新手的计算机程序员(或一个手头没有问题的计算机程序员)将 某些程序代码 从一个地方 复制 到另一个地方而几乎不了解它的工作方式或是否需要它 时,可以使用 术语“邪教程序员”。 在新的位置。

货物崇拜编程也可以参考 盲目 应用 设计模式 或编码样式 的实践, 而无需了解该设计原理背后的原因。 例如,在不言自明的代码中添加不必要的注释,过分地遵循特定 编程范例 的约定 ,或者为 垃圾回收 会自动收集的 对象添加删除代码

常见问题?

想象一下您正在处理错误,找到导致错误的代码的情况。 您不太确定发生了什么,所以您;

  1. 谷歌的错误。
  2. 您会发现一个StackOverflow问题。
  3. 搜索最挑剔的答案。
  4. 将解决方案复制并粘贴到您的代码中。
  5. 尝试调试,看看是否可以解决您的问题。

它具有,因此您可以将其检入并继续前进。

听起来有点熟?

我们为什么要这样做? 为什么在我们的实现中我们盲目地使用此代码段并按原样使用它?

用例可能并不相同,因此如果解决方案使我感到惊讶。 除了简单的示例,了解解决方案背后的原因比解决方案本身更重要。 对于许多您不了解的事情,您有很多事情是做不到的。 您不能对其进行修改,改进或测试。 您无法记录它,也无法拥有它。

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

我们都喜欢新事物,尤其是管理人员似乎喜欢顺应流行趋势,紧跟技术进步。

现在,大多数团队将遵循敏捷方法。 TDD和自动化测试在某些情况下非常有用,持续集成可消除基础架构团队的大部分开销,大数据和AI可以极大地提高用户满意度和容器化,最近,微服务将我们的旧式整体架构转变为较小的自包含服务。

这些进步中的每一项都有其出色的表现,我不容忍任何一项。 我的困境是我们是否需要将所有这些都纳入我们的所有流程和代码中? 我们看到来自Netflix,Facebook和Twitter的博客文章显示了它们的使用方式如何改变了它们的工作方式。 如果大公司认为有必要,我们是否也没有必要? 这是货运邪教节目再次抬起头来的地方。

我们需要了解当前设计的问题,发生的原因以及将来如何将其抛弃。 是的,这些新流程可能会帮助我们解决问题,但是盲目跟随它们,以淡淡的希望实现这些目标不是前进的道路,也没有任何逻辑意义。

我之所以特别提到微服务,是因为许多公司似乎正在过渡,并列举了以下好处

  • 更快的开发时间
  • 高扩展性
  • 容易提升
  • 易于部署
  • 具有自主选择技术的自主团队

有了这样的列表,有什么要考虑的? 让我们一起跳上潮流吧!

Etienne Boulanger在Unsplash上​​的照片

等一下…这种方法有什么缺点吗?

  • 建筑复杂性

在单片架构中,复杂性和依赖关系的数量驻留在代码库中,而在微服务架构中,复杂性转移到实现特定域的各个服务的交互上

  • 操作复杂性
  • 如何以可扩展且经济高效的方式配置资源
  • 如何有效地运行数十个或数百个微服务组件而无需付出更多努力
  • 如何应对缺乏标准和异构环境的情况,这些环境包括不同的技术和技能不同的人
  • 如何处理版本控制
  • 如何跟踪和调试整个系统中的交互
  • 如何跟踪数百个代码部署管道及其相互依赖性

这些是从亚马逊自己的“微服务挑战”白皮书中删除的。 现在,我对您一无所知,但是缺点对我来说比好处要可怕得多。 再说一次,我并不是说这不是正确的方法,但是除非这些好处大于缺点,否则您从这种方法中获得的好处是什么?

“公共”问题。

确实很简单,停止使用Public关键字,停止自动创建Public类。 为什么这样做呢?

使用public关键字的问题是您错过了与封装相关的好处。 我们为什么这么多使用它? 这几乎是我们在创建类时使用的默认单词,所有示例都将使用公共类,向导和​​代码片段将实现公共类。 现在该停下来了。 有多少人拥有公开的Facebook帐户? 这个世界上的大多数事物都是私人的,我们的班级也应该如此。 默认情况下将它们设为私有,然后如果需要将它们公开,则可以对其进行更改。

有了丰富的经验,就会有极大的忧虑。

您在某个领域工作的时间越长,对新工具或新流程所带来的感知改进的天真就越少。 今天的大多数想法来自数十年来对该领域的研究,最终被人们接受。 一旦某事物获得了广泛采用,就可以轻松地完全拥抱它。 也就是说,如果这是正确的事情。

“好的 判断 来自 经验 ,而 经验来自 不好的判断”

–丽塔·梅·布朗(Rita Mae Brown)

因此,请随时搜索互联网上的问题解决方案和教程。 不断探索新的语言,框架和实现。 只知道它们为什么起作用,而不是简单地知道它们为什么起作用 我们每个人都从自己的经验和错误中学习,因此了解基本原理将使您将来不再走同样的路。