IT行业需要更好的命名吗？

栏目: 后端 · 发布时间: 6年前

内容简介：IT行业需要更好的命名吗？

关键点

为什么有合适的名称很重要
在IT行业内命名欠佳的实例
命名欠佳或有漏洞的命名有什么副作用
在团队和公司里如何处理欠佳的命名
如何防止在未来出现不好的术语

在阅读大量的文章、书籍和听了会议发言之后，我常常问自己，我们在IT业内是不是总在使用适当的或一致的术语呢。我们从其他领域借鉴一些术语，这是一个相当好的方法，但是，有时我们会歪曲这些术语的含义，或与其他学科相比，我们没有用一致的方式来使用这些术语。

在本文中我将分享一些不良术语的例子，并就为什么这很重要以及如何处理不一致谈谈我的看法。我将就如何在组织内部和跨组织改善这种局面提出建议。

为什么这很重要，什么使命名如此重要

近年来，IT业已经开始被越来越多的潮流和风尚（如方法、框架）所驱动；IT学术会议的数量以指数级增加，相比以往，我们已经开始更多地通过软件来表达我们的身份了。在技术飞速发展的大环境下，对使用合适的名称、对精确术语的依赖，以及具有有机而可持续的发展就很有必要了。名称反映了行业的质量和成熟度，使用不当会带来混乱和误解，有时会导致错误的期望。

架构——同时用于IT和建筑业

在解释架构在软件中表示什么之前，我将先来说说建筑业中的两个术语（相比软件而言，建筑业是个更为成熟的行业）：结构工程师（ structural engineer ）和架构工程师（ architectural engineer ）。结构工程师需要理解和计算建筑的稳定性、强度和刚度，以确保它能承受是重力、风力和其他外力。他负责建筑结构的完整性和一致性。另一方面，架构工程师负责基本的建筑物特性，如照明、音响、通风、采暖、水暖、急救通道、消防和安全系统。他们需要把这些工作紧密结合在一起，使建筑物牢固实用。

现在，让我们回到软件业。在这一背景下，架构表示的是什么意思呢？

从ANSI / IEEE标准1471-2000定义来说，架构是“一个系统的基本组织，表现为组件、组件之间和组件与环境之间的关系以及设计和演变的指导原则。”。另一种定义，是我看到过的最短的，它最初是由Ralph Johnson提出的，后来被Martin Fowler所推崇，它将架构定义为“重要的东西（不管是什么）”

基于与建筑工程的类比，软件架构师更像是结构工程师，而不是架构工程师。

也许，与建筑领域保持一致，遵从同样的术语会很好，但对于软件人员来说，“架构（architecture）”这个词的说法听起来更具吸引力。

然而，有些人可能很难予以准确界定。在我的软件架构职业生活中注意到，即使是经验丰富的老手对软件架构师的意义及其职责也有不同的理解。因此，在有些团队中，软件架构师的角色揉合了技术带头人的属性；在这样的情况下，前者（也就是软件架构师）甚至是不存在的！技术带头人在架构方面所有东西的设计上都有所有权，包括结构、边界、通信机制、整个系统与外部系统的接口，等等。这些混合的角色使技术分离模糊不清，可能会阻碍项目委派适当的职责给内部团队中适当的人。还有一个额外的后果，它还会影响我们接受教育的方式，以及职业生涯的发展。

非功能需求和质量属性

通常情况下，业务需求是对功能性和非功能性需求的深入挖掘。在这样的背景下，非功能性需求是指性能、可用性、可扩展性、安全性、可用性等质量属性。

但是，让我们采用两种方式去更好地了解一下隐藏在非功能性术语背后的是什么：第一个方式是搜索词典中的词，第二个方式是达成它们的技术含义。

根据字典的解释，“非 ” 词的意思是“不，没有，不重要的，无价值的。”。基于这个定义，由此产生的问题是：因为它的语义含义是“毫无价值”，我们怎么能把一些影响架构的东西称之为“非”功能性呢？我们为什么不应该把这些需求抛到一边呢？因此，第一个解释存在矛盾。

接下来使用第二种方法，所有的非功能性需求（如安全性、可用性）都是通过功能（如安全性通过加密功能，易用性通过向导功能）实现的，所以他们依赖于具体功能。这引出了第二个问题：如果一些东西是通过功能实现的，那么我们如何把它们称之为非功能呢？

如果参考产品的质量属性（比如可管理性、可维护性、易用性和可用性等）与非技术性利益相关者讨论非功能性需求会陷入困境，因为会出现一些混乱的情况，比如有些与可维护性相关的东西是通过可管理性实现的。这也是为架构师设的一个陷阱，为避免这种情况，他们必须进一步澄清的字面意思及其含义的细节，因为为实现一个质量属性（如可维护性），可能意味着在产品设计需要对另一个质量属性做出架构权衡（例如可管理性）。可能在产品的易用性和可用性上还会出现混乱的情况，它们经常被混用和滥用。

QA（质量保证）还是QC（质量控制）

几乎在每个软件团队中都有称之为“质量工程师”的成员。他们的角色主要是理解需求规格说明书并基于它们定义一组测试用例（比如，功能测试、接受测试、集成测试等），从而验证产品和检查可能的缺陷。如果我们通过定义来检索QA和QC的含义，按照merriam-webster.com上给出的定义，会把QC理解为“旨在确保已制产品具备合格质量的一系列活动，比如设计分析和缺陷检查”，而QA则理解为“系统化的评估程序和对产品、服务的全方位评估，或确认质量标准得以满足的机制”。

基于这些定义，软件开发团队中负责定义测试用例和验证产品的人多于QC工程师。这可能会导致问题。我就遇到过招聘人员把这搞混的情况，他按组织的QA职位检索人才却提供了QC工作，或者反之。有个朋友最近就遇到了这种情况，她受邀去讨论QC的职位要求（比如定义测试用例和验证产品），但其实她所具有的资质专用于QA（比如负责监控和确保公司过程符合ISO标准）。这两个职位完全是两码事，他们可能在某种程度上会有所互补，但所有的知识和技能都是不同的。

不适当地使用QA和QC名称还会导致团队内对职责理解不到位或混乱的情况。

层——软件和硬件的差异

层这个术语最初是在网络中引入的，此处的所有层旨在完成同一最终目的，它们只是处于不同的抽象层次：建立和支持网络中不同节点间适当的通信。例如，基于OSI栈，它们有七层（即物理层、数据链路层、网络层、传输层、会话层、表示层和应用层），每一层都服务于同一目标。抽象使每一层更恰当（比如，应用层的send()方法应基于多个更少的抽象和特定的API）。

在软件中，层在每层抽象中不是互为补充的，不像网络中那样。例如，数据访问层（例如负责处理数据连接和CRUD操作）有特定的目的。其他层（比如业务层）不参与数据访问层更高或更低层的抽象。他们主要的目的是隔离每层的职能，而不是用抽象的方式补完工作。Ralf Westphal就此主题做了一个很有意思的演讲：“ 用软件单元让软件设计充满活力吧 ”。

微服务

近年来，微服务这个词被在架构中得到了广泛和大量的采用。它是自面向服务的体系结构（SOA）浮现出来的，因为遵循这个架构模式的应用遇到了一些问题。我喜欢引用Jonas Bonér的说法，“微服务其实只是穿上新衣服的SOA”。但是微服务这个术语的真正意思是什么呢？按照字典的定义，它可能所谈的是一个非常小的服务，或者“少量的”服务。在现实中，它是一个目标实现的服务，自成一体，独立于其他实例和服务。现在的应用有着成百上千个服务，变得非常难以管理。一个可能的原因是，人们对实现微服务的方式有着不同的理解。没有一个共同的、强大的定义，也没有围绕它们的最佳实践。因为定义是有漏洞的，前缀的“微”加在“服务”上生硬牵强。我们一定要想出一个更好的词来反映实际的需要。为了绕过SOA的问题，它在行业内得到了过多的关注和应用。Uber首席系统架构师在“微服务之后是什么？”中描述了微服务暴露的许多现实问题。我个人认为，使用适当的定义以及强大的和标准化的指导（从架构的角度来看），我们会设计出更好的微服务架构。但从我们的错误中总结学习也不一定是坏事，因为错误并非不可逆转，我们在未来再也不会重犯了。

组件

组件（像微服务一样）是在定义这一方面存在问题的另一个术语。对于它有很多误解，人们有时用包甚至对象来代替它。从软件的观点看，架构包含组件，但在代码中这些组件实际表现为什么呢，或类比为什么呢？代码级的任何实体都称为组件？当然不是，因为这太含糊了。我喜欢Martin Fowler的定义：“组件是一个软件的单位，它可以独立更换和升级”。这个定义即没有参考包，也没有参考类，而是对组件自身的描述和及其自己的属性。

当开发者在实现时遵从架构设计（例如使用组件图）时，这种误解就会产生重大影响了。如果“组件”这个术语是不精确规定（例如如何映射到代码），实现较之最初的设计就会有缺失，可能会出现缺陷（例如以紧耦合、低内聚的组件，缺乏定义的API等而告终）。从一个软件架构师的角度来看，当我在与其他技术上的利益相关者讨论和使用组件这个术语时，我宁可从一开始就把它定义清楚： “ 在我们的上下文中组件代表的是什么意思？在我们的架构中如何能清晰地识别一个组件？ ” 否则，我们所指的就有可能是不同的事物。

弱代假说

在 java 虚拟机内，内存设计和垃圾收集器试探算法是基于 弱代假说 的，它说的是：

绝大多数的对象不会被长时间引用，这些对象在其Young期间就会被回收。
很老的对象(生存时间很长)和很新的对象(生存时间很短)之间很少存在相互引用的情况。

但是，假说一词表示什么？从科学的角度看，它指的是一个想法或一个解释，需要通过研究和实验予以验证。在科学领域之外，假说一词用得更为宽松，它常常关于的是对一个假设的猜测或以该假设为依据，因为它无法被证明（如编程语言仍然不是科学）。可能在这种语境下，它更应该被称之为猜测或前提条件，而不是假说，这可能不影响软件开发人员使用和实现这个概念的方式，但使用正确的术语肯定有利而无害。

软件应用命名

有些应用软件可能因为它们的名字而令人困惑。例如，有一个应用程序命名为协议缓冲区（Protocol Buffers），对它的说明是：“针对序列化结构化数据的语言无关、平台无关、可扩展性的机制”。这里的术语“协议”令人困惑，因为它（如网络协议）通常指的是设备发现、识别和相互联系的机制，以及定义在通信中如何包装数据的一套规则。基于上述，我们可以很容易地发现协议缓冲区不是网络上的“协议”，而只是在应用层处理结构化数据一种方式。为避免混乱，遵循行业的命名标准可能会更好。

如何在你的组织中处理和改善不好的术语

为了克服这些矛盾，在联想术语之前，我们可能需要搜索和阅读更多有关的基础知识（例如使用字典）。我们可以从我们的组织（团队内）开始入手，可以创建语义指南/词典（例如通过定义和例子）与各方分享，即一种从术语的立场去看的技术雷达，它可以为我们带来更正确和更充分的理解。在我的项目中我就创建了一个，我用来与所有利益相关者交流，使我们彼此之间的沟通更容易了。例如，它改善了业务分析师和开发人员之间的沟通，尤其是在定义业务规格说明书时，因为分析师可能会增加些参考资料到这些指南中（例如在用户故事的描述中）。同时在架构展示期间和内部技术文档中，我们总会参考这个雷达，从而对我们的环境达成共识。拥有一个基线很重要，一起讨论时有个共同的参考（如技术和非技术的利益相关者）会使交流更容易，最终它会加快整个开发过程。

另外，除了澄清术语的定义和例子，使用SMART目标也很重要（例如明确的、可衡量的、可实现的、现实的、与时间相关的），从而避免模糊的情况。例如，在你的项目或组织内部对于什么是 微服务 有一个适当的定义是不错的，但可能还不够。最好能细化语境，在哪种情况下，微服务将是更好的选择，如何衡量一个服务是否真的只实现了一个单一的目的，创建另一个微服务而不是扩展现有的那个有多么的可行，如何验证这个微服务与其他微服务之间的隔离和集成，增加新的服务对整体架构有怎样的影响，开发和维护这个服务会有多少成本，等等。

在技术的环境下，遵循定量的、可衡量的、可测试的、可证伪的原则去捕捉和指定的一切。否则就难以开发，验证和证明。

分布式团队中的术语

在分布式团队中工作是一个更大的挑战，但在我看来，处理术语的技术也同样如此。Eric Evans和之后的Martin Fowler提出了“通用语言”一词（与特定领域无关），作为一种具有不同背景和来自不同文化的利益相关者之间的交流方式。我想说，在处理不佳的术语时，我们可以采用同样的技术；我们需要定义在我们的环境中（经济、政治、文化和技术）有意义的术语集（适当的定义，例子，等），并和不同的团队分享。这些要作为一种内部词汇来用，或作为一种有界限的语言，并又能适当表达我们的业务。