你什么时候使用第三方代码？

Question

您通常如何解决编程问题，例如，当您必须解析ini文件时？

如果这是我的任务，我会：

1. 首先检查我的武器库中是否已有适合它的武器。我的意思是检查我熟悉的库，如Glib，APR或标准C API。

2. 如果我找不到合适的东西，我会检查是否有开源库来解决这个问题。我会看到它的API的质量，如果它有悠久的历史，人们怎么说，并自己测试。

3. 如果我一无所获，那么我将自己实施。但是，这种情况非常罕见。

通过这种方式，我相信我可以更专注于业务，关注我们组织所独有的事情。

---

但是，我通常看到一种完全不同的方法。

1. 只相信C / C ++标准库。
2. 除非完全不可能，否则实施其他任何内容。

例如，当我问我的同事时，他如何解析ini文件，她说，“只是逐个字符”。似乎他从未认为这个问题可能已被其他人解决了。

他认为：我们正在撰写商业产品，稳定性是最重要的。所以我们应该尽可能少地依赖第三方库。学习新的API还需要时间。

---

有时，我觉得这只是个人选择取决于一个人的性格。当有不同方法的人做自己的工作时，这是可以的。 但是当他们必须合作时，必须妥协。

你怎么看？你如何解析.ini文件？

Answer 1

当我认为使用它的成本低于自己开发代码的成本时，我使用第三方代码。请注意，我不是在谈论货币成本，而是在时间，精力，金钱，限制等方面的总体成本。

Answer 2

听起来你的同事患有Not-Invented-Here Syndrome，但这种情况一般都是名声扫地。 （另一方面，Joel has an interesting piece that takes the other side。）

开发人员通常不记得他们为企业工作。业务的关键是价值，成本和风险。当然，学习一个复杂的API是一个成本，就像处理错误一样，但我看到重新发明轮子也是一个成本。这两种选择都有相关的风险。

正如我所看到的，除了相当琐碎的案例之外，技术经理的工作是从业务角度决定查找和使用第三方组件的成本和风险是否超过编写功能的成本和风险-house。

我自己的看法是，当功能经过广泛的现场测试或者超出我项目的计划和预算时，我会去第三方。重新发明轮子是一种损害我公司竞争力的成本。

Answer 3

除了已经讨论过的时间和稳定性问题，如果您正在开发商业产品，您必须非常小心第三方代码的许可。除了公共域代码或类似BSD许可证之外的东西，你可能会发现推出自己的代码实际上比打开那些蠕虫更有效率。

Answer 4

我完全赞同你的方法，有一点不同： 2.5 - 使用与2中相同的标准，尝试找到解决我问题的商业产品。同样的标准是因为一些代价高昂的错误告诉我，一个巨大的价格标签本身并没有说明代码的质量。

Answer 5

编写自己的实现肯定比重用现成的第三方模块更有优势：

• 功能完全符合您的需求。使用现成的模块，情况可能并非如此。
• 尽可能理解小代码，因为实现完全符合您的情况。当您需要编写扩展时，这是一个很大的好处，因为需要理解和修改的代码较少。
• 评估现成的模块非常耗时。此外，只有在大量使用后才会出现一些缺点，因为转换到另一种产品为时已晚。
• 扩展现成模块会导致大量通信开销（与维护现成模块的开发人员讨论）。另一方面，分支代码是未经尝试的，因为您将无法从错误修正和扩展中获益。
• 以前的所有评论都假设现成的模块是开源。我永远不会使用封闭的源模块，因为总有太少的文档可用。

但是，我并不是说重用总是很糟糕。在您解析.ini文件的示例中，我建议使用Boost Spirit解析器，它允许您以最少的工作量定义解析器。

Answer 6

我同意首先寻找一个可靠的解决方案是一个很好的方法，但是一些问题很难用你的语言随时可用来解决。

sscanf可以很好地解析C中的ini文件。

Answer 7

这实际上取决于我的情况。如果我自己写它将花费不到10分钟，并没有太多的改进空间我从来没有找到其他解决方案。但是，如果任务很长，我会检查完成工作的可靠库的可用性，而不是其他任何东西。此外，如果需要将此系统集成到其他系统，我会尝试自己编写。我讨厌遇到兼容性问题。

有时候对某些问题有很好的解决方案。它们不能被跳过。大多数时候，我更喜欢独立的解决方案，这些解决方案是隔离的，不需要任何额外的依赖关系。我尝试更喜欢单元和现场测试的库。我总是尽量避免添加增加太多复杂性的框架或库来完成任务。例如，我没有将boost库用于“任何”实现。这需要许多文件，提升标头位于包含路径中，并且可能存在更多依赖关系。

我也同意有时学习比写作需要更多。在那种情况下，我更喜欢写作。如果能更好地适应您的系统，有时重新发明轮子并不是那么糟糕。

有时我自己写一个图书馆来获取知识。例如，我在我的毕业设计中写了XML parser。这是很好的学习。

Answer 8

我的经验法则是，我希望尽可能多地完全理解代码。一个完全理解它的同事也同样好。

如果库足够简单易读和理解，那么我将使用它。如果它更复杂，我使用它的唯一原因是它是一个非常复杂和商品化的问题。

例如，我会将第三方库用于html布局引擎，正则表达式引擎，矩阵求解器，SQL服务器等。如果我能读取它，我只会使用第三方库来解析ini文件并充分了解它。

Answer 9

我认为这必须在开发人员处于职业生涯周期的地方进行。我从自己和其他开发人员那里看到的内容与开发人员生命周期有几个截然不同的阶段：

1. 我会将自己的一切都归于自己，因为这是我能做到的唯一方法
2. 如果适用，我将使用完成的组件，如果不是，我将自己编写
3. 如果适用，我将使用完成的组件，如果不是，我不会这样做，因为从头开始写一些东西是麻烦的

Answer 10

我宁愿使用现成的INI解析器（对于C - 例如this one，它非常小），而不是手动使用sscanf或类似（它对简单{{1}有用或许，但INI文件可能比这更复杂。）

关于何时使用第三方代码 - 尽可能。稳定性很重要，但这正是为什么你应该尝试找到已经测试过的代码，而不是从头开始编写相同的东西 - 例如你可能会遇到一些模糊的边缘情况，其他人已经处理过了（你不会浪费时间纠正实用程序代码中的错误，而不是专注于主程序）。

学习新库的API需要时间，但编写完全相同的代码也是如此。重塑是有益于学习恕我直言，但我总是尽量在尽可能快地编写任何应该工作的代码时重用尽可能多的代码（除非它不可能;例如平台限制）。