害怕软件的复杂吗?其实复杂性是必须存在的 - ferd

20-05-04 banq

与复杂性作斗争是软件开发中经常出现的主题,我已经看到过一遍又一遍在各个级别上争论不休:在函数和方法中应该进行多少注释?理想的抽象量是多少?框架什么时候开始具有“太多的魔力”?组织中什么时候出现太多语言?

我们试图摆脱复杂性,控制它,并寻求简单性。我认为这种逃避复杂性的方式进行构架是错误的。复杂性必须生活在某个地方。

弹性工程学告诉我的一件事是控制论中的“需要多样性”的概念:只有复杂性才能处理复杂性。

使用构建工具时,一些事情变得显而易见:

  • 如果简化构建工具,它将无法处理存在的所有奇怪的边缘情况
  • 如果要处理奇怪的情况,则需要偏离要建立的任何规范
  • 如果您想简化通用默认设置的使用,则通用默认规则必须在工具和用户之间共享,这些用户可以调整他们的系统以适应该工具的期望
  • 如果允许配置或脚本,则可以为用户提供一种方法,以指定必须共享的规则,因此该工具适合他们的系统
  • 如果您想保持该工具的简单性,则必须强制用户仅在适合该简单性的参数内播放
  • 如果用户的用例不能很好地映射到您的简单性,他们将围绕您的工具建立填充以实现其目标

这是无法避免的。复杂性必须生活在某个地方。无论您是否意识到,解决问题始终是人们解决问题的一部分。

不幸的是,如果我们到达上述列表的最后一点(我们总是以某种方式这样做),复杂性不会处于休眠状态。它是每个人的学习经历的一部分,他们会适应它。

他们解决了这个问题,看到了两个冲突概念之间的不匹配。必要的复杂性可能会四处移动-回到工具(或新工具)中,或者通过重新组织事物来消除。每个这样的更改都需要付出努力和更多的调整,并且人们可以看到复杂性,了解复杂性并解决复杂性。在某些情况下,更改不会简化事情,而是会在各个人的假设之间造成新的不匹配,从而使事情复杂化,这将需要新的调整。偶然的复杂性只是表明其年龄的基本复杂性。它是不可避免的,并且一直在变化。复杂性必须生活在某个地方。

设计心理学,唐·诺曼提到“在头脑知识”和“知识世界”的概念(类似于概念更学术的Roesler&Woods的呈现设计的专业知识)。头脑中的知识是您知道的,已经学习的,记忆中的东西。知识就是一切:记下来的信息,设计线索(您可以通过查看电源按钮的符号来了解电源按钮,并且知道它可以像按钮一样被按下)。一个棘手的事情是,世界上对知识的解释既是文化的又是上下文的,并且依赖于头脑中的知识(您知道可以按下电源按钮,因为您首先知道按钮是什么)。

在某些方面,专业知识正在您的脑海中积累知识,使您可以更好地阅读世界。

我们在软件设计中的一个常见陷阱来自关注于我们如何以“简单”的方式读取和解释给定的代码。专注于简单性充满了危险,因为复杂性无法消除:它可以转移。如果将其从代码中移出,它将流向何处?

设计Rebar3时,我们觉得该工具可能很简单。其简单性的条件是您对Erlang / OTP项目的预期结构有基本的了解。只要遵守这些规则,一切都会顺利进行。我们将一些复杂性外部化为更广泛的生态系统。规则总是需要学习的(因此我们假设),但是工具现在取决于对规则的理解。在为了解规则的人简化工具使用时,我们使仍在学习规则的人变得更加困难。其他生态系统中用于其他目的的其他工具都在进行类似的权衡。

陷阱在软件体系结构和架构中是隐蔽的。当我们采用微服务之类的东西时,我们会尝试使之微不足道,以便每个服务都变得简单。但是,除非这种简单性如此之大,以至于您的实际应用程序继承了它并被迫简化为简单性,否则它仍然必须走到某个地方。如果不在单个微服务中,那么它在哪里?

复杂性必须生活在某个地方。如果幸运的话,它可以住在定义明确的地方。在您决定应该增加一些复杂性的代码中,在支持该代码的文档中以及在为工程师提供的培训课程中。您为它提供了一个位置,而没有试图将其全部隐藏。您创建管理它的方法。您知道在需要时可以去哪里见面。如果您不走运,并且您只是假装可以完全避免复杂性,那么这个世界就无处可去。但是它仍然不会停止存在。

它无处可去,它必须在您的系统中漫游,无论是在代码中还是在人们的脑海中。随着人们四处走走和离开,我们对此的理解逐渐减弱。

复杂性必须生活在某个地方。如果您接受它,请给它应有的位置,在知道它存在的情况下设计系统和组织,并专注于适应,它可能会成为一种优势。

                   

5
猜你喜欢