在很多项目上开发人员和业务人员之间的讨论有很大一部分是词汇的误解造成的，即使在技术人员、业务人员内部讨论也存在同样的情况。例如，某电信运营商项目，话费套餐属于商品还是产品这个问题经常被拿出来讨论，直到找到了总部给出的规范性文件才定性下来。
越是专业的软件系统对专业术语的定义需求越发迫切，这些定义往往需要极其精确，甚至一个字都不能错。
在保险领域，“保单”和“投保单”虽然只差了一个字但是含义完全不一样，投保单是一种申请，可以翻译为 insurance application，而保单是正式生效的保险文件；在财会领域，经常会混用 “成本” 和 “费用”，这两个词有时候等同有时候又需要严格区分，否则会带来二义性。
语言沟通的二义性是软件工程的隐形杀手，往往会让团队付出额外的工作。在领域驱动设计中，实践模型驱动开发的方法，非常重要的原则之一便是统一语言。
看起来统一语言是四个字，在实践中我们发现，这几乎伴随需求分析工作的整个阶段。极端一点来说，做到了语言统一，系统中每一个业务对象、字段实现了精确定义，需求分析工作也就差不多结束了。因为程序员的工作本来就是替业务分析师将他们的非结构化（形式化）语言翻译成精确定义的计算机语言。
得到了精确、不会变化的形式语言，就可以通过代码生成的方式完成软件开发，遗憾的是前者不能实现。理想中的软件开发，需求分析人员输出了一套精确、逻辑自洽的设计说明书，实际项目中不同模块、不同迭代之间的术语、字段和逻辑可能无法完全自洽。
从这个层面上来看，软件工程更像是写作或者翻译工程，而非建筑工程，虽然后者的类比更加直观。
这也就解释了软件团队为什么如此难以管理，因为超过三个人以上合作写作或者翻译就变得非常困难。
既然软件工程是写作，那么术语管理就有了它的意义。
意义
一次和一个数据平台项目的负责人交流过关于统一数据口径的问题。
我们都有共同的困惑，对于一家 200 百人的 IT 公司，可能需要管理上百个应用系统，那么如何统一开发过程中的术语?
这几乎不可能，原因是：
- 基于一直演进的业务，难以建立稳定的抽象和定义。例如，原本只做外卖订单的公司开始搞打车，订单的概念会随着业务的演进变化。
- 规模问题。无法把几十个应用所有的语料信息建立全局的术语，这样会拖慢各个部分的开发进度，且无法真正理解每个地方的真实含义，难以做正确定义。
- 执行的难度。即使解决了上面两个方面问题，团队执行的又非常困难。
虽然理想中的完美统一不太现实，但是一定程度上实现统一并进行管理依然有其意义：
- 团队之间的沟通将变得简单，不会频繁建立术语之间的信息映射，即使这种映射无法避免。
- 中心化的报表、数据平台、业务中台等的实施会变得容易。
- 开发效率会提升，对新加入到团队的人员更加友好。
- 统一对外口径，可以建立更专业的平台形象，产品中的术语不一致会给客户使用产品带来更多的困难，比如软件产品的用户界面与帮助界面的术语不统一会让用户不知所措，用户会对产品的质量产生质疑。
- 统一术语后，可以降低人员成本。
- 进一步来看也可以提高开发效率，以及充分争取产品发布窗口时间。
在软件工程中，如果能理解该业务领域的术语，也就意味着理解相关的业务。因此，一些公司会将术语库当做信息资产并保护起来，甚至有自己的术语管理部门。
《现代术语学引论》作者冯志伟先生说“术语是人类科学知识在语言中的结晶”，在很多项目中体会后深以为然。
理论基础
有一门专门的学科叫做术语管理，用于指导人们日常设计一些术语，达成共识后再推广使用，这里简单聊聊这些略显“枯燥”的理论。
什么是术语管理?
简单地说，术语是在某个专业领域中具有专门意义的词，术语管理是系统化的收集、描述、处理、记录、呈现及查询特定专业领域中专业词汇的活动。
对于企业来说，术语是全球化企业语言资产的重要组成部分，也是企业信息开发和技术写作的基础性工作，属于企业语言战略的重要组成部分。
有哪些现代化的术语管理技术？
根据个人级/小微团队级和企业级不同的诉求，业界已经有一些解决方案。在 IOS 704:2022 标准中，将术语管理系统分为独立式、集成式和整合式。
独立式比较适合个人或者小微团队级使用：例如 AnyLexic、Lingo，对于小范围、小规模的场景使用办公软件（Excel、WPS 等）则完全够用。
集成式和整合式比较适合企业级使用：往往包含术语提取、术语服务器、在线术语工具、翻译工具和写作助手等，例如 crossTerm、 MultiTrans TermBase、Transit TermStar，国内的东方雅信、传神、朗瑞、语智云帆等语言服务或语言技术企业。
另外，还有一些在线的术语管理软件：SDL Multiterm Online、crossTerm Web、MultiTrans Prism TermBase Web、Acrolinx IQ Terminology Manager、Termweb。
实践中的问题
前面讨论了这么多，实际在项目上做好术语管理非常困难。下面聊聊在实践中有哪些问题。
在软件项目中，可以从哪些材料中提取术语？
如果是瀑布的项目，在技术团队参与前分析人员就已经整理好了完整的 PRD 文档。可以通过一些分词工具提取相关的词汇，清洗后获得统一的英文翻译。由于这个阶段往往是一个小团队在一起开始整体完成，其统一性非常高。
如果在敏捷的项目中，可能是按照迭代、模块分批进行的，需要分批提取术语，并维护相关的术语库，难度比较大。
在国内项目中，几乎没有标准的英文语料来源，可以尝试寻找相关英文网站、对外出口使用的英文说明书等材料。
在软件项目中，需要提前敲定哪些东西？
在有条件的情况下，可以提前定义下列信息的双语名称，尤其是在被反复引用的情况下：
- 系统和项目的名称和代码
- 外部系统的名称和代码
- 业务对象名称和属性
- 数据库表名和字段
- 枚举和枚举值
- 业务配置和配置项
中英对照翻译有哪些经验和坑？
中英对照翻译上有一些语言学上的痛点，在《术语管理概论》一书中，介绍了一些关键的语言学问题。
- 词条抽取的颗粒度：如果将所有词汇都纳入词汇管理，如何将术语分级，将日常频繁使用的基本词汇不纳入术语表，例如，“通用计算机” 中的 “通用” 可以不纳入词汇管理范畴。
- 多义性：一条中文术语对应英文会有多个，反之亦然，需要在根据场景翻译。
- 时态和语法规则：英文术语存在时态和变形，例如协商作为名词出现可以使用 negotiation，而出现在短语中往往是形容词，可以使用 negotiable。
- 不可译性：英语属于印欧语系，而汉语属于汉藏语系，文字结构和修辞手法不同，某些场景下无法找到对等术语。
在翻译上可以参考下面的策略：
- 使用同一款翻译软件，避免前后翻译差距较大
- 优先直译，有专业翻译的情况使用专业翻译。例如定期存款 “fixed term deposit”，在金融中往往叫做 “time deposit”，在能确认的情况下优先使用后者，反之使用前者也不会造成歧义。
- 词性不明时优先使用基本词汇，例如创建时间可能有 “creation time”、“create time” 等译法，不确定的情况下优先使用基本词汇，容易保持命名风格统一。
参考资料
- 软件开发是设计还是生产？https://mp.weixin.qq.com/s/BbGOuBJeromDfnoTZ_sASQ
- 梁爱林.术语管理的意义和作用——以微软公司术语管理策略为例[J].中国科技术语, 2012, 14(5):5.
- 王华树.科技翻译项目中的术语管理[J].中国科技术语, 2015, 17(4):5.
文 | 少个分号 （转载请注明出处）
本文仅供学习！所有权归属原作者。侵删！文章来源： DDD和微服务 -少个分号 :http://mp.weixin.qq.com/s?__biz=MzA4Mzc2MzcyMQ==&mid=2247484614&idx=1&sn=e817a785a694c5c1b4994b59d587c932&chksm=9ff033a0a887bab633026ef867f866717a60bde3b325670c4c4e2a01d318e6d4b3b5300c5d6d&scene=21#wechat_redirect
文章评论