C 您何时使用第三方代码？

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

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

首先检查我的武器库中是否已经有适合它的武器。我的意思是检查我熟悉的库，比如Glib、APR，或者只是标准的capi

如果我没有找到任何合适的，我会检查是否有一个开源库来解决这个问题。我将看到它的API的质量，如果它有很长的历史，人们对它的看法，并亲自测试它

如果我什么也没有发现，那么我将自己实现。但是，这种情况非常罕见

通过这种方式，我相信我可以更专注于业务，专注于我们组织独有的东西

---

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

只相信C/C++标准库

除非完全不可能，否则执行任何其他操作

例如，当我问我的同事如何解析ini文件时，她说，“一个字符接一个字符”。似乎他从未想过这个问题可能已经被其他人解决了

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

---

有时候，我觉得这只是个人的选择，取决于一个人的性格。不同方法的人各司其职也没关系。 但当他们必须合作时，就必须妥协

---

你觉得怎么样？如何解析.ini文件？

我同意首先寻找可靠的经验证的解决方案是一个好方法，但有些问题很容易用语言中现成的解决方案来解决

---

在C中解析ini文件非常有效。

我完全同意您的方法，但有一点不同：

---

2.5-使用与第2条相同的标准，尝试找到一种解决我的问题的商业产品。同样的标准，因为许多代价高昂的错误告诉我，一个巨大的价格标签本身并不能说明代码的质量。

我宁愿使用ready INI解析器（对于C来说，它非常小），而不是手工使用

sscanf

或类似的工具（这对于简单的

key=value

可能很好，但INI文件可能比这更复杂）

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

---

学习新库的API需要时间，但编写与之完全相同的代码也需要时间。重新发明有助于学习IMHO，但在编写任何应该尽快生效的代码时，我总是尽可能多地重用代码（除非这是不可能的；例如平台限制）当我认为使用第三方代码的成本低于自己开发代码的成本时，我会使用第三方代码。请注意，我所说的不仅仅是金钱成本，而是时间、精力、金钱、限制等方面的总体成本。

这要视情况而定。如果我自己编写代码的时间不到10分钟，那么我会考虑到这个问题没有太多的改进空间。我从不寻找其他解决方案。但是，如果任务很长，我会检查可靠库的可用性，而这项工作仅此而已。此外，如果需要将此系统集成到其他系统中，我会尝试自己编写。我讨厌遇到兼容性问题

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

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

---

有时，为了获取知识，我自己编写了一个库。例如，我编写了一个用于毕业设计的库。这是一个很好的学习。

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

听起来您的同事正遭受着这样的痛苦，而这通常是不可信的。（另一方面，）

开发人员通常不记得他们为企业工作。企业的关键在于价值、成本和风险。当然，学习复杂的API和处理bug一样是一种成本，但我认为重新发明轮子也是一种成本。任何一种选择都有相关的风险

在我看来，除了非常琐碎的情况外，技术经理的工作是从业务的角度决定查找和使用第三方组件的成本和风险是否超过在内部编写功能的成本和风险

---

我个人的看法是，如果功能已经过广泛的现场测试，或者超出了我的项目计划和预算，我会选择第三方。重新发明轮子的成本会损害我公司的竞争力。

我的经验法则是，我喜欢尽可能充分地理解代码