软件架构师速成指南

第 25 章 软件即协作

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

有 Git 吗？

你好，彼得，发生什么事了？

关于 IT 架构与经典建筑架构之间的差异， （正确地）已经说了很多，也写了很多，我们在比喻中经常提到这一点。例如，尽管建筑物会随着时间的推移而演变（只是非常缓慢¹但以低成本实现高变化率是实体物体无法做到的。但很多东西都可以，而且并不局限于软件开发。

谁说软件只能用于计算机？

企业花费大量精力创建、修订和共享文档，无论是战略计划、时间表、设计文档还是状态报告（第 30 章）。通常情况下，这些文件需要多方输入，并经过迭代和质量检查，直至发布。这些人工制品实际上是一种软件形式--它们肯定不是硬件，尽管有时它们可能会打印在实体纸张上（亲眼目睹有人打印 25 份关于数字化转型的大型幻灯片将永远烙印在我的脑海中）。

因此，如果文档实际上是软件，如果我们想要优化和加速协作与交流，我们或许可以从软件交付团队，尤其是分布广泛的开源团队的工作方式中学到一些东西。

版本控制

有一种工具是你无法从开发人员冰冷的手中撬走的，那就是版本控制（第 14 章）。版本控制是一张安全网，让开发人员有信心快速行动，因为他们可以保证，万一走错了路，可以迅速恢复。 如今最流行的版本控制工具之一是 Git。这个软件背后的模型需要一些时间来适应，但一旦你适应了自己的流程，你就再也不想回到其他的软件中去了。

我用 Markdown 写了这本书的前身、²一种简单的文本格式。我用 Git 进行版本控制，用 Dropbox 与出版引擎进行文件同步。 书出版后，我把关于其他章节（比如这一章）的想法积压了下来。因为这些章节还没有完成，也不会很快出版，所以我没有多想，就恢复了用 Microsoft Word 编写积压文档的做法。

我立刻注意到我的进度变慢了：我应该删除还是重写这一段？如果我以后改变主意，想保留它怎么办？我最好复制一份，"停放 "在某个地方备用。对了，我把最新版本放在哪里了？我应该使用 "跟踪更改 "功能吗？在使用文本文件和版本控制时，我不会在这些问题上花费一分一秒，因为我确信我可以随时恢复到之前的版本。此外，我还能看到一段时间内我所做的所有改动，因此可以轻松跟踪进度。

当然，我也可以将 Word 文档导入 Git 或 Microsoft SharePoint 等文档管理系统。但是，这样做会缺少两个主要因素：首先，Word 文件之间的版本比较要比简单的文本文件费力得多。Word 的审阅模式可以跟踪历史记录，但更多的是针对细微的修订修改，而不是文档的迭代创建。更重要的是，制作本书的构建工具链使用的是 Markdown 文件，因此我无法享受持续集成的好处，也就是说，我无法在做任何修改时创建本书的预览副本。

备注

任何看过公司文件服务器的人都会发现，我并不是唯一一个喜欢版本控制的人。 你会发现同一份文件有 20 多份副本，文件名有的以版本号为后缀，有的以日期为前缀（便于排序），有的以最后一位作者的姓名首字母为标记，以示分支等等。有人的想法是对的，但在实施过程中却磕磕绊绊。

唯一的真理之源

版本控制 如果所有团队成员查看的是同一个版本，那么版本控制就是一个强大的工具。将保存在本地驱动器上的文件通过电子邮件发送给其他人，意味着每个人都有自己的真相来源，这在最好的情况下会导致摩擦，在最坏的情况下会导致信息丢失。 ...