如何决定是使用库还是编写自己的实现

一般决定

在决定使用什么之前,我将创建一个库必须满足的条件列表。这可能包括大小、简单性、集成点、速度、问题复杂性、依赖性、外部约束和许可证。根据具体情况,做出决定所涉及的因素会有所不同。

通常,在编写自己的实现之前,我会寻找一个合适的库来解决这个问题。如果我必须自己写,我将阅读适当的算法,并从其他实现中寻求想法(例如,使用不同的语言)。

如果在下面描述的所有方面之后,我找不到合适的库或源代码,并且我已经搜索(并在合适的论坛上询问),那么我将开发自己的实现。

复杂性

如果任务相对简单(例如,多值类),那么:

1. 查找现有的开源实现。
2. 整合代码。
3. 如果过多的话,重写它,或者删减它。

如果任务很复杂(例如,灵活的面向对象图形库),则:

1. 找到一个编译(开箱即用)的开源实现。
2. 执行它的“你好,世界!”当量。
3. 根据需要进行任何其他评估。
4. 根据问题域标准确定其适用性。

速度

如果库太慢,则:

1. 仿效它。
2. 优化它。
3. 将结果反馈给社区。

如果代码太复杂而无法优化,并且速度是一个因素,请与社区讨论并提供分析细节。否则,请寻找一个等效的,但速度更快(可能功能更丰富)的库。

美国石油学会

如果API不简单,则:

• 写一个正面图,并把它贡献给社区。
• 或者找到一个更简单的API。

尺寸

如果编译的库太大,则:

• 只编译必要的源文件。
• 或者找一个较小的图书馆。

漏洞

如果库不是开箱即用地编译,请寻找替代方案。

依赖关系

如果图书馆依赖于外部图书馆的数量,那么就寻找替代方案。

文档

如果没有足够的文档(例如,用户手册、安装指南、示例、源代码注释),请寻找替代方案。

时间限制

如果有足够的时间找到最佳解,那么就这样做。通常没有足够的时间从头开始写。通常有许多类似的库需要评估。请记住,通过仔细的松耦合,您总是可以将一个库替换为另一个库。找到最初起作用的东西,如果它后来成为负担,就替换它。

开发环境

如果库与特定的开发环境相关联,请寻找替代方案。

许可证

Open source .

10个问题…

+++(使用库)…---(编写自己的库)

1. 图书馆正是我需要的吗?只需几步就可定制?++
2. 它是否提供几乎所有的功能?易于扩展?++
3. 没时间了?++
4. 这对一个半场很好,对另一个半场也很好?++
5. 很难扩展,但文档很好?++
6. 很难扩展,但大部分功能是什么?+
7. 功能正常,但过时?-
8. 功能正常。但奇怪(疯狂的界面,不是健壮的,…)——
9. 图书馆工作,但需要决定的人是在狂妄自大吗?---
10. 图书馆工作,可管理的代码大小,投资组合需要更新?---

一些想法…

如果它是一个小而有用的东西,可能对其他人也有用,那么为什么现在要写一个库并把它放到网络上呢?出版这类小型图书馆的成本降低了,同时也降低了其他人进入图书馆的障碍(见 bitbucket 或 github )那么标准是什么呢?

也许它不应该完全复制现有的已知库。如果它复制了现有的东西,那么它应该从新的角度来处理问题,或者更好地说,它应该提供一个更短或更精简的*解决方案。

* _乐趣

如果它是一个微不足道的函数,那么就不值得在整个库中使用它。

如果它是一个非平凡的函数,那么它可能是值得的。

如果它是多个函数,所有这些函数都可以通过拉入一个库来处理,那么它几乎肯定是值得的。

对我来说,这是一个相当简单的答案。

如果您需要具有成本效益,那么最好尝试找到一个能够满足您需求的库/框架。如果你找不到它,那么你将不得不写它或找到一个不同的方法。

如果你有时间,觉得很有趣,写一篇。在这一过程中,你会学到很多东西,你可以用你的杀手级新代码包回馈开源社区。如果你找不到,那就别找了。但是如果找不到,那你就得写了;)

就我个人而言,如果我能证明写图书馆是正当的,我总是选择这样。这很有趣,你学到了很多关于你将注意力集中在什么方面的知识,你还有另一个工具可以添加到你的军火库中,并把你的简历上。

如果功能只是应用程序的一小部分,或者如果你的需求与其他人的需求相同,那么图书馆可能就是解决问题的途径。例如,如果您需要使用和输出JSON,您可以在五分钟内将一些东西组合在一起以处理您的即时需求。但是你开始一点一点地增加它。最终,您将拥有在任何库中都能找到的所有功能,但是1)您必须自己编写它;2)它并不像在库中找到的那样是一个健壮、良好的文档。

如果功能是应用程序的重要组成部分,并且您的需求与其他人的需求不完全相同,那么请仔细考虑。例如,如果您正在进行机器学习,您可能会考虑使用WEKA或MAHOUT之类的包,但这是两种非常不同的野兽,并且此组件可能是应用程序的重要部分。在这种情况下,库可能是一个障碍,因为您的需求可能不适合原始作者的设计参数,并且如果您试图修改它,您将需要担心一个比您自己构建的最小系统更大更复杂的系统。

有一篇很好的文章讨论了如何清理HTML,以及它是应用程序的一个重要组成部分,以及一些需要大量调整的内容,因此使用外部库并不是最好的解决方案,尽管有许多库确实执行了看起来需要的操作。

保持平衡

你应该保持几个标准的平衡。我会考虑几个话题,问几个问题。

开发时间与维护时间

我能在几个小时内开发出我需要的东西吗?如果是,为什么我需要图书馆?如果我得到一个lib,我确定它不会导致花费数小时调试和文档读取吗?答案是-如果我需要一些明显和直接的东西,我不需要一个额外的灵活的lib。

简单与灵活

如果我只需要一个错误包装器,我需要一个具有灵活类型、堆栈跟踪和彩色打印的lib,以及……不!即使使用设计精美但灵活和多用途的libs也会降低代码的速度。如果你计划使用2%的功能,你就不需要它了。

挖掘任务与小任务

我是否面临着一个巨大的任务,需要外部代码来解决它?显然,AMQP或SQL操作太大,无法从头开始开发,但可以就地解决微小的日志记录问题。不要使用外部libs来解决小任务。

我自己的LIB与外部LIB

有时,最好是发展自己的库,因为它是100%使用的,为了100%适合您的目标,您最好知道它,它总是最新的应用程序。 不要仅仅为了酷而构建自己的lib,请记住,供应商目录中的很多lib都是“为了酷”而开发的。