如何决定是使用库还是编写自己的实现 [英] How do you decide whether to use a library or write your own implementation

问题描述

受到这个问题的启发，该问题始于无辜，但

我们假设你需要一个实用的方法 - 相当简单，但不是一个单线程。引用的问题是如何重复一个字符串X次。你如何决定是使用第三方实现还是自己编写？

第三方方法的明显缺点是，您要为代码添加依赖关系。
但是如果你写的是你自己的，你需要编写代码，测试它，（也许）配置它，以便你可能最终花费更多的时间。

我知道决定本身是主观的，但你用来达到它的标准不应该是。

那么，你使用什么标准来决定何时编写自己的代码？

解决方案

一般决定

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

一般来说，我会寻找一个合适的库来解决问题，然后再编写自己的实现。如果我必须自己编写，我将阅读适当的算法，并从其他实现中寻找想法（例如，用不同的语言）。

如果，毕竟方面描述如下，我可以找不到合适的库或源代码，并且我已经搜索（并在合适的论坛上询问），然后我将开发自己的实现。

复杂性

如果任务相对简单（例如，MultiValueMap类），则：

1. 查找现有的开源实现。


2. 集成代码。


3. 重写或修剪




如果任务很复杂（例如，灵活的面向对象的图形库），则：



1. 查找编译（开箱即用）的开源实现。


2. 执行它的你好，世界！


3. 根据需要执行任何其他评估。


4. 根据问题域标准确定其适用性。



速度





如果库速度太慢，则：



1. 为此进行配置。


2. 优化。






如果代码太复杂，无法优化，速度是一个因素，请与社区讨论，并提供剖析细节。否则，寻找一个等效的，但速度更快（可能功能更少）的库。





API





如果API不简单，则：






• 写一个立面并将其返回社区。 li>
  
• 或找到更简单的API。










如果编译库太大，则：






• 只编译必要的源文件。






<




如果库没有开箱即可编译，请寻找替代方案。





如果图书馆取决于外部图书馆的数量，请寻找替代品。





>





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





时间限制





如果有充足的时间找到最佳解决方案，通常没有足够的时间从头开始写。通常有许多类似的库要评估。请记住，通过细致的松散耦合，你总是可以将一个库交换为另一个库。





开发环境





如果库与特定开发环境绑定，请寻找替代方案。





许可证





开源。




Inspired by this question which started out innocently but is turning into a major flame war.

Let's say you need to a utility method - reasonably straightforward but not a one-liner. Quoted question was how to repeat a string X times. How do you decide whether to use a 3rd party implementation or write your own?

The obvious downside to 3rd party approach is you're adding a dependency to your code. But if you're writing your own you need to code it, test it, (maybe) profile it so you'll likely end up spending more time.

I know the decision itself is subjective, but criteria you use to arrive at it should not be.

So, what criteria do you use to decide when to write your own code?

解决方案

General Decision

Before deciding on what to use, I will create a list of criteria that must be met by the library. This could include size, simplicity, integration points, speed, problem complexity, dependencies, external constraints, and license. Depending on the situation the factors involved in making the decision will differ.

Generally, I will hunt for a suitable library that solves the problem before writing my own implementation. If I have to write my own, I will read up on appropriate algorithms and seek ideas from other implementations (e.g., in a different language).

If, after all the aspects described below, I can find no suitable library or source code, and I have searched (and asked on suitable forums), then I will develop my own implementation.

Complexity

If the task is relatively simple (e.g., a MultiValueMap class), then:

1. Find an existing open-source implementation.
2. Integrate the code.
3. Rewrite it, or trim it down, if it excessive.

If the task is complex (e.g., a flexible object-oriented graphing library), then:

1. Find an open-source implementation that compiles (out-of-the-box).
2. Execute its "Hello, world!" equivalent.
3. Perform any other evaluations as required.
4. Determine its suitability based on the problem domain criteria.

Speed

If the library is too slow, then:

1. Profile it.
2. Optimize it.
3. Contribute the results back to the community.

If the code is too complex to be optimized, and speed is a factor, discuss it with the community and provide profiling details. Otherwise, look for an equivalent, but faster (possibly less feature-rich) library.

API

If the API is not simple, then:

• Write a facade and contribute it back to the community.
• Or find a simpler API.

Size

If the compiled library is too large, then:

• Compile only the necessary source files.
• Or find a smaller library.

Bugs

If the library does not compile out of the box, seek alternatives.

Dependencies

If the library depends on scores of external libraries, seek alternatives.

Documentation

If there is insufficient documentation (e.g., user manuals, installation guides, examples, source code comments), seek alternatives.

Time Constraints

If there is ample time to find an optimal solution, then do so. Often there is not sufficient time to write from scratch. And usually there are a number of similar libraries to evaluate. Keep in mind that, by meticulous loose coupling, you can always swap one library for another. Find what works, initially, and if it later becomes a burden, replace it.

Development Environment

If the library is tied to a specific development environment, seek alternatives.

License

Open source.

这篇关于如何决定是使用库还是编写自己的实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！