使用 STL 与自定义实用程序类的程序员生产力

Question

在我工作的环境中，由于历史原因，我们使用的是自定义实用程序类的大杂烩，其中大部分是在 STL 出现之前编写的。 我认为至少使用 STL 编写新代码是个好主意的原因有很多，但最主要的是我相信它可以提高程序员的生产力。 不幸的是，我不知道如何证明这一点。

是否有任何研究试图量化甚至只是暗示使用 STL 所带来的生产力提升？

更新：我想我应该更具体。 我不提倡重写现有代码，并且我不担心新员工能否顺利开始。 前者是愚蠢的，而后者本身并不足以让人信服。

Answer 1

没有研究表明 STL 仅仅因为它是 STL 就更高效。 使用它可以提高生产力，因为它是程序员熟悉的标准，并且代码已经编写和测试过。

如果您的公司已经拥有员工熟悉的实用程序类，并且该实用程序代码在整个现有代码库中使用，那么切换到 STL 实际上可能会降低生产力。

也就是说，对于使用 STL 的新代码来说将是一个很好的举措。 我不一定会从生产力的角度来争论这一点，而是从可维护性的角度来争论。 如果您拥有早于 STL 的代码，听起来您公司的代码具有相当长的生命周期，并且多年来可能由许多新程序员维护。

您可能还想提倡使用 STL 作为每个人保持 C++ 技能的一种方式。 虽然我不会拒绝不懂 STL 的 C++ 候选人，但我肯定会将其视为一个污点。

Answer 2

STL之所以如此“好”，只是因为它已经存在很长时间了，并且它的实现已经得到了很多用户和关注。 它们经过了良好的调试，并且供应商对算法进行了很好的优化。

STL 对于您商店中的新开发人员来说会更有效率，因为他们可能已经熟悉它了。 您的自定义库将是外国的，并且可能缺乏开发人员习惯使用的功能。 不过，对于新开发人员来说，在最初的磨合期之后，这并不是一个大问题。

没有真正迫切的理由要转向 STL，因为它确实如此。 如果您的应用程序中有非常有用的实用程序类，我建议您坚持使用它们，除非它们不适用于新代码。 在新代码中将 STL 与自定义库混合会在某些时候导致兼容性问题，并且重构代码以使用所有 STL 会引入错误。 无论哪种方式，你都会失去生产力。

编辑：“新”代码是指使用旧类库的现有应用程序中的新代码。

如果您正在开发不利用任何旧应用程序代码的新独立应用程序，我会推荐 STL，因为它就在那里，大多数 C++ 开发人员都知道如何使用它，而且它非常稳定（并且您可以从工具集供应商那里获得支持）如果不是）。

Answer 3

我能想到的使用 STL 提高生产力的唯一论点是轻松集成其他库的可能性 - Boost、Arabica、SOCI 等。它们都是为与 STL 一起工作而设计的，而不是与您的内部容器类一起工作。

Answer 4

我认为关键因素是开发团队的流动率。

如果团队稳定，并且他们已经在该代码上工作了十年，并且可能从现在起十年后，他们将使用他们熟悉的实用程序类提高工作效率，并推动他们使用 STL 将导致生产力下降和错误。

如果团队变动较多，那么新的开发人员可能会熟悉 STL，而显然不是这个专有的实用程序类库，并且会用 STL 做得更好。

Answer 5

我也遇到过同样的情况。 这取决于相关的实用程序类。 我见过的许多自定义实用程序类都存在错误或设计不当，并且导致整个源代码出现错误和效率低下。 在这种情况下，直接替换为 STL 等效项将改进代码库、提高生产力、减少错误并降低未来的维护成本。

有时，您可以通过为旧类改造 STL 风格的迭代器来帮助弥合两个世界之间的差距，但要小心确保它们正确！

Answer 6

如果本地开发的实用程序以任何方式特定于您所做工作的领域，情况可能恰恰相反。

Answer 7

STL 有用的地方不是在 STL 提供的实际库等中，而是在 STL 使用的编码风格中。

下面需要进行 2 个主要测试：

struct DoSomething {
  bool operator ()(Container::value_type const & v) const
  {
    // ...
  }
};

void bar (Container const & c)
{
  std::for_each (c.begin (), c.end (), DoSomething ());
}

第一个测试验证 'DoSomething::operator()' 是否执行了它应该执行的操作。 第二个测试只需要验证“DoSomething::operator()”是否被调用。

与手写的 for 循环相比，这种分离有助于提高生产率。 对于上述情况，测试数量是“要做的事情”和对非空容器进行调用的测试的总和。 在 for 循环的情况下，测试次数是测试的乘积。

Answer 8

我认为的原因是：

代码的质量

STL 的编写者（无论是其接口，还是编译器的实现）无疑比贵公司中最好的开发人员要好得多。

他们的工作是制作一个可用的 STL，这意味着每个函数/方法/对象无论如何都经过严格测试。

代码的可维护性

随着人员的更替，一些代码可能会慢慢地、悄悄地失去维护。 这意味着，如果此代码中存在错误，或者发现其性能或界面缺乏（请参阅上面的“质量”），那么您将发现没有人可以熟练地改进它。

代码更改将在其他地方出现代码回归的非零概率，并且如果您的内部库没有经过单元测试，则这种回归将在相当长的一段时间内未被检测到。

我什至没有提到“我永远不会碰那个粘糊糊的代码”综合症，当有人试图纠正代码时发现他不明白为什么这样做（因为宏，奇怪的先决条件，等等..

结论

将两者结合起来，你会发现对于通用代码（即数组、字符串等），通过慢慢地从内部库迁移到STL库，在编写“转换函数”时会做得更好。 我认为

这种迁移是代码维护的一部分，并且您应该慢慢地（即使用新代码或重构时）尽可能使用 STL 而不是内部通用库。

Answer 9

由于您已经有了实用程序类，因此无需使用 STL。 当您发现需要开始将 STL 集成到您的实用程序库中时，它很快就会成为一个可维护性问题。 在我看来，这将是生产力损失。

也就是说，STL 可能提供许多实用程序库不提供的功能和实用程序。 （特别有用的是标头，您可以立即开始使用它，而不会出现遗留代码的许多问题。）如果您正在编写大量新代码，那么使用 STL（和 Boost，如果您可以）而不是编写自己的实用程序类和算法。 因此，这将是生产力的重大提高。

不过，我不知道有任何关于这个主题的研究。

Answer 10

考虑一下您雇用新 C++ 程序员时的情况。 他/她更有可能拥有 STL 课程的经验还是您自己的课程的经验？ 如果您开始切换到 STL，您可能会在变得富有成效之前节省大量时间。

Answer 11

目前，任何新雇用的员工都必须学习如何使用旧课程，这需要时间和金钱。 像其他人一样使用 STL 可以为您的公司节省资金并保持其在候选人中的吸引力。

Answer 12

不幸的是，我认为没有办法证明批量替换这些自定义类是合理的。 如果可能的话，一次用一个类的 STL 组件替换它们。

这是一项维护和保养工作。 可读性问题与任何事情一样重要。 (1) 使用 STL 可以帮助维护人员一目了然地理解代码，而不需要学习自定义实现的方法。 (2) STL 有很好的文档记录并且易于理解 - 您的自定义类怎么样？ (3) STL经过严格审查。 (4) STL自带渐近运行时上& 下限。

祝你好运。