读《Software Engineering at Google》（21）

作者：术子米德

2022 年 5 月 02 日
本文字数：682 字
阅读完需：约 2 分钟

🤔☕️🤔☕️🤔

读《Software Engineering at Google》（21）—— Dependency Management
📖：管理库或包的依赖网络，一个理解很少，却最具挑战的软件工程问题。
🤔：劈头一句，只有被这样的挑战捆住过的人，才有心领神会的体感。依赖，如果在最初没有设定简单规则，如果在过程里没有遵守简单规则，那么演变出网络式依赖后，远不是挑战一个词，能够表达出其中携带的困难。除了本身事情不好弄，更多是心理上的不可思议感。为何明明是简单的事情，非得闹出如此不可收拾的复杂。难道把简单搞乱到难以驾驭的复杂，就是我们刻画在基因里的恶性嘛。当然，非得拿熵增这种只能尬聊的概念来解释，未尝不可，但也依然心有不甘，简单点的秩序就这么难嘛。
📖：当有机会时，优先解决代码控制问题，次选解决依赖管理问题。
🤔：所有代码在一个仓里，这听起来不可思议，怎么适应各种需求。这个想法一直在我的观念里，可就在今天，我现在要对观念提出质疑。如果把单一仓作为代码管理的约束，当新需求来的时候，面临这个约束，问题会在很早暴露出来，在早期就把问题解决掉，会让以后的所有依赖，只需面对一个代码仓。这在初期看来的不可思议，会让后期的版本依赖显得无比清爽简单。因为所谓版本管理的问题，实际上就是在使用的程序，其对应的源代码存在好几种可能性，越多的可能性就越无法回答，它们在一起是否会好好相处，毕竟它们已经分离太久。反过来，只要所有依赖的源代码，都在一个仓里，最直接的答案就是，它们肯定能工作，这个答案就解决了版本依赖问题的一大半。以前觉得要有版本分支，现在反而觉得单仓唯一主干，更符合规模化和长期实践。
📖：

—— By 术子米德 @2022.04.29

发布于: 刚刚阅读数: 2

原文链接:【http://xie.infoq.cn/article/d984ab43e9bc2f0326af8387b】。文章转载请联系作者。