共享代码库，为何总被程序员弃用？

我们鼓励可重用性，并不懈地为此努力，却从未实现过。

作者 | Jeremy Morgan
译者 | 弯月，责编 | 屠敏
出品 | CSDN（ID：CSDNnews）
神秘的“可重用代码”的理念已经存在几十年了。在第一行代码问世后不久这个理念就出现了。我们鼓励可重用性，并不懈地为此努力，却从未实现过。多年来，我看到了不同程度的成功。有人说：“我们有75%的可重用代码库”，也有人说：“我们共享代码库，但从未在项目中使用过。”
最近的一次讨论不禁让我思考：为什么软件开发组织没有共享代码库？是因为老板不愿意吗？是团队冲突吗？还是开发人员自己不愿意？

代码的重用性不是头等目标。

我们不能因此责怪老板。如果你向管理层解释可重用代码的基本概念，大多数人都会赞同这是一个好主意。只需写一次代码，然后就可以重复使用。其中的好处不言自明。
团队的冲突也有可能阻碍代码重用，通常人们都无法达成共识共享哪些代码。由于没有足够的时间来构建可重用的代码，所以开发人员本身也可能会反对。
所有这些都是代码重用未能实现的因素，但同时我们也应该想想，我们是否需要可重用的代码库？

什么是共享库？我们为什么关心共享库？

如果你让开发人员编写一些可用于其他功能的代码，那么你就可以将这些代码放在自己的“库”中以供稍后使用。这种库可以是DLL、文件夹的一部分，节点模块等等。比如连接到数据库的代码，我们没必要为每个访问数据库的软件编写代码。我们应该创建一个DB_Connect类，并放在一个文件中，以后就可以复制到另一个项目。

这很简单。你从一个函数着手，如果这个函数足够抽象，那么你就可以通过设置参数供其他项目使用。当有新项目的时候，你就无需再编写代码来连接数据库，而是可以直接把这个库引进来，并输入参数。这样做的好处有：

只需编写一次代码就可以多次使用（节省开发的时间）
经过彻底测试的代码库可以减少回归错误
强制其他团队遵循标准

这些都是使用共享库的重要原因。关于代码重用的文章和书籍有很多，大多人都很熟悉这个概念。其最大的好处就在于不必一遍又一遍地编写“无聊的东西”，而且所有项目都可以使用同一个方法。这样节省下来的时间就可以让开发人员编写更加有意思的功能。

如何使用共享库？

以下是在业务中使用共享库的一些方法：

内部使用：在内部小组与项目之间共享的代码
外部使用：专门为组织外的程序员使用而设计的代码
分支：用户可以获取原始的代码，并通过“建立分支”来编写适合其特定需求的代码。

这符合DRY（Don’t Repeat Yourself）的软件开发原则：不要重复自己。

我们想要共享代码库吗？

为什么并非每个人都这样做？有些组织可能出于某种原因避免使用共享库。并非每个项目或团队都能从中受益，而且这也不是解决所有开发问题的灵丹妙药。以下是不使用代码库的一些原因：

分布式的庞大系统：即使你把一些代码放入一个库，每个人都愿意使用，那也并不意味着这段代码写得不赖。低效的数据库连接器设计会导致每个人都在使用低效的数据库连接器。你对自己的实现进行的任何改动都有可能产生负面的级联效果。一个API的小改动可能意味着每个系统都会遭到破坏。
强烈的依赖：如果每个软件都依赖于你的库，就会产生紧密耦合。这会引发无数的依赖关系，例如，所有软件都依赖于像Angular这样的框架。如果使用特定版本构建软件，升级它可能会在您的应用程序中产生连锁反应。
缺乏灵活性的设计：有时你不得不采用某种与实际需要不同的设计。因为“其他人都在这样做”，所以你不得不让按照同样的方法编写你的代码，这会增加开发时间。那么当初我们建立共享库的意义何在呢？
编程语言的限制：很多时候，人们都会说：“我们的库是用____编写的，所以我们不得不使用这种语言。”这意味着你被锁定在了某种编程语言中。这可能导致使用错误的工具。因此，不要假设因为你们团队不使用共享库意味着他们没有觉悟，或不想提高生产力。

如果要使用可重用代码库，那么应该考虑哪些因素？

如果你正在考虑创建可重用的代码库，首先应该看看这样做是否有意义。

仔细检查设计：然后再仔细思考。你真的会受益吗？你现在有重复的代码吗？是否可能导致紧密耦合的问题？
仔细检查依赖项：你是否会造成依赖项，导致别人不得不解决这些依赖？通常依赖项多久会发生变化？别人可以绕过你造成的依赖项吗？
开始时尽可能地抽象：你应该让你的库具有高度抽象性，这样才能保证它们执行预期的功能，同时为了满足特定的需求也能被重写或扩展。你只需给出基本的东西，然后让他们按照他们喜欢的方式发展。

如何让开发人员编写共享库

现在，你已经决定建立共享库了，那么你可以通过以下方式帮助团队采用你的共享库：

从现有项目中提取代码：这是建立新库的最简单的方法。引用现有的项目，删除项目特有的代码，并保留可以重复使用的所有代码，然后保持稳定。
彻底的测试：你肯定不想在软件中引入问题。在构建抽象库之后，你需要经过彻底的测试，才能依赖这些代码，并帮助开发人员找到回归。如果你希望开发人员使用你的共享库的话，就不要给他们一堆垃圾。
检查所有的当前使用情况：深入挖掘并了解人们使用共享库的方法，你需要确定每个人都能从中受益，并搞清楚是否需要进行更改。你需要逐个检查每个方法，以确保他们能够轻而易举地地使用你的共享库。与商业中的大多数情况一样，成功来自良好的沟通。自上而下的设计帮不了你，你需要搞清楚开发人员的需求并根据这些需求设计库。

总结

我共事过的大多数组织都不使用共享代码库。通常他们都在以某种形式尽力使用一两个已经被证明运作良好的共享库。
两种极端的情况是：第一，将所有重复的代码都放在库中；第二，根本没有共享库，每个人都为自己的项目单独构建软件。往往你会发现成功介于两者之间。至于倾向于哪个极端，则取决于你的需求。
我们应该共享抽象函数。我能想到的包括身份认证/授权、数据库连接和日志记录。你应该开发这类的共享库，或者使用其他人开源和构建的库。你应该考虑所有的其他因素，以及整体的设计。
对于是否应该以大型项目为基础构建一个巨大的代码库，我们不应该妄下结论，因为有时这会加重开发人员的负担。同时我们也不能完全排除这个想法。你需要凭借自己敏锐的判断，有目的性地找到最适合项目的策略。
原文：https://dzone.com/articles/thinking-about-reusable-code
本文为 CSDN 翻译，转载请注明来源出处。
【End】
CSDN 5G 沙龙来啦！
6 月 29 日，微软中国 CTO 韦青、北京邮电大学信息与通信工程学院多媒体技术教研中心主任/博士生导师孙松林、金山云 AIoT 事业部高级研发总监肖江、爱立信中国研发部多天线高级专家朱怀松、爱立信中国研发部主任系统工程师刘阳等行业内顶尖的领军者、资深的技术专家们共聚一堂，共同探讨 5G 在物联网中的巨大潜能。
扫描海报二维码，赶快预约直播吧！

点击“阅读原文”，也可马上预约直播。