你什么时候使用第三方代码?[关闭]

当我认为使用第三方代码的成本小于自己开发代码的成本时,我就使用第三方代码。注意,我说的不仅仅是金钱成本,而是时间、努力、金钱、限制等方面的总体成本。

听起来你的同事 Not-Invented-Here Syndrome ,这通常是不可信的。(另一方面, Joel has an interesting piece that takes the other side )

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

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

我自己的看法是,当功能已经被广泛的实地测试或者超出了我项目的计划和预算时,我将成为第三方。重新发明轮子是一项损害我公司竞争力的成本。

除了已经讨论过的时间和稳定性问题外,如果您开发的是商业产品,则必须非常小心第三方代码的许可。除了公共域代码或类似于bsd的许可证下的东西,您可能会发现发布自己的代码实际上比打开一罐蠕虫代码更有效率。

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

与重用现成的第三方模块相比,编写自己的实现当然有其优势:

• 特点 完全符合你的需要 . 对于现成的模块,情况可能并非如此。
• 有如 小代码 尽可能理解,因为实现与您的案例完全匹配。当需要编写扩展时,这是一个很大的好处,因为需要理解和修改的代码更少。
• 评价 一个现成的模块 费时的 . 此外,一些缺点只有在广泛使用后才会显现出来,因为现在换另一种产品已经太晚了。
• 扩展现成的模块会导致 通信开销 (与维护现成模块的开发人员进行讨论)。另一方面,分支代码是不空的,因为您将无法从错误修复和扩展中获益。
• 前面的所有注释都假设就绪的模块是 开放源代码 . 我从不使用封闭源代码模块,因为文档总是太少。

然而,我并不是说重用总是不好的。在解析.in i文件的示例中,我建议使用 Boost Spirit 解析器,它允许您以最少的工作量定义解析器。

我同意,首先寻找一个可靠的、经过验证的解决方案是一个好方法,但是有些问题用您的语言中现成的东西解决起来是微不足道的。

sscanf 在C中很好地解析INI文件。

这真的要看情况,我把情况放在一个尺度上。如果我自己写的时间不到10分钟,没有太大的改进空间,我从来没有寻找其他的解决方案。但是,如果任务很长,我将检查执行此任务的可靠库的可用性,而不检查其他任何功能。另外,如果这个系统需要集成到其他系统,我会自己写。我讨厌遇到兼容性问题。

有时候有些问题有很好的解决办法。不能跳过它们。大多数时候,我更喜欢独立的解决方案,不需要任何额外的依赖。我尽量选择单元测试和现场测试的库。我总是尽量避免添加框架或库,这些框架或库添加了太多的复杂性,无法完成任务。例如,我没有使用boost库来实现“任何”实现。这需要很多文件,boost头必须在include路径中,并且可能有更多的依赖项。

我也同意,有时候学习比写作更需要。那样的话,我更喜欢写作。有时重新发明轮子并不是那么糟糕,如果它能更好地适应你的系统。

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

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

如果图书馆简单到可以阅读和理解,那么我就用它。如果它更复杂,我使用它的唯一原因是如果它是一个非常复杂和商品化的问题。

例如,我会将第三方库用于HTML布局引擎、正则表达式引擎、矩阵解算器、SQL Server等。如果我能够阅读并完全理解ini文件,我只会使用第三方库来解析ini文件。

我认为这必须与开发人员在其职业生命周期中所处的位置有关。我从自己和其他与我交谈过的开发人员那里看到,开发人员的生命周期有几个不同的阶段:

1. 我会尽我所能,因为这是我唯一能做对的方法
2. 如果可以的话,我会用做过的组件,如果不行,我会自己写
3. 如果可以的话,我将使用done组件,如果不可以的话,我将不会这样做,因为从头开始写东西很麻烦

我宁愿使用ready ini解析器(对于c-e.g. this one ,它很小),而不是用手,用 sscanf 或者类似的(对简单的 key=value 也许吧,但ini文件可能比这更复杂)。

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

学习新库的api需要时间,但编写与之完全相同的代码也需要时间。重新设计有助于学习imho,但我总是在编写任何应该尽快工作的东西(除非不可能;例如平台限制)时尽量重用代码。