寻找真正的“工具链”

Question

我刚发了这篇文章是为了回答一个关于“最佳”bug追踪软件的问题.

一个工具本身就是一个工具。虽然所有人都在谈论工具链，但大多数只是指工具的松散集合。为什么不找一个“和其他孩子玩得很好”的问题追踪器呢？也就是说，与IDE、构建工具、版本控制系统都有很好的接口.

事实上，我想我该去问一个关于最好的连锁工具链的问题.

有什么意见吗？我更喜欢在Linux上开发C/C++和使用自由和开放源码软件的答复(但如果你认为这样做对别人有帮助的话，那就不要阻止你发布基于Windows的答案)。我们不需要一个完整的链，但也许有几组链接工具比链中完全分开的“链接”更好)

我使用

• Eclipse -用于编码和调试，也用于插件。
  • 汽车编码用DO2.文档
  • 用于静态代码分析的夹板和CppCheck
  • 用于自动测试的CppUnit
  • Bugzilla，et全部用于bug跟踪
  • 用于版本控制的CVS、Subversion等

​

• Hudson -用于自动构建，插件用于。
  • 汽车编码用DO2.文档
  • 用于静态代码分析的CppCheck
  • 用于自动测试的CppUnit
  • Bugzilla，et全部用于bug跟踪
  • 用于版本控制的CVS、Subversion等

​

我似乎缺少了一个用于项目管理的工具，它与工具链中的其他“链接”接口。我们能做到多完整，从头到尾，是否有一个“最好的”链(或者，至少是一个链接最多的链)？

编辑:让我们不要忘记需求跟踪和项目计划与跟踪- end Edit

是否每个人都绘制了各种工具之间的关系图(例如，哪些接口与哪些工具，以及向哪个方向；哪些工具可以以另一种导入格式导出，等等)？

Answer 1

G‘’day，

在我的经验中，我发现试图想出一个“确定的”工具链可能会导致问题。

最糟糕的是，它往往会迫使人们对项目采取“一切看起来都像钉子”的方法。也就是说，您已经完成了选择您认为合适的工具的工作，现在您已经拥有了您的工具套件。

在我的经验中，很难让人们改变他们的“规范集”为其他项目一旦工具集已经被选择和烦扰为这样。

二十多年来，我一直在从事各种项目，从机载潜艇声纳模拟器到空中交通控制显示系统，再到直升机控制系统。即使在同一家公司，不同的项目也需要不同的工具集来解决将要遇到的各种问题。

您可能会认为，一旦您为特定目的选择了一个工具，那么您就可以在所有项目中重用该工具，例如您选择的用于bug跟踪的BugZilla。但是，如果没有合适的SMTP服务器可用，因为您有一个分布式团队，并且您的邮件服务器是内部的、锁定的、安全的，例如。

我建议，最好建立一套可能的工具，您可以从中选择您的项目的工具套件。例如，添加Trac或FogBuzz作为一种可能的bug跟踪机制。

很多事情都会影响你对工具的选择。从我的头顶上我得到：

• 小组的地域分配，
• 内部锁定，即不能公开访问服务器，例如电子邮件、源存储库、测试平台等，
• 因为想要重用系统的各个方面而不得不与一些现有的系统进行接口，例如以前的团队对他们施加了VisualSourceSafe，
• 客户坚持使用特定的平台，
• 新项目的管理团队对于常规管理类型报告的要求与以前的管理团队不同，
• 等。

有了一套可能性，尽量减少的影响，“试图挤压一个方钉到一个圆孔”。

无论如何，您可能会发现，您可以在一段时间后减少您的可能性套件，因为您可以展示一种成功的方法，因此在公司内获得足够的支持来支持您以前做过的事情。

HTH

Answer 2

我认为Unix哲学反对这种紧密集成的工具链。您首先提到的Eclipse来自Java世界，这不是偶然的。Unix (以及扩展而言，Linux)倾向于不相信所谓的“插件”，而更多地相信共享存储在平面文本文件中的数据的一组工具。

说到“项目管理”，我不知道你指的是像Make这样的东西，还是用来跟踪团队进度的东西。如果您的意思是类似Make，那么Unix世界迫切需要一个可重用的Make，它支持“智能重新编译”，并将与多个编译器一起工作。最接近的是格伦·福勒氏病 nmake，但这并不是很接近。

关于更一般的集成工具集，

• 我见过的最好的一套工具是AT&T构建的高级软件技术工具，其中有一本最优秀的书http://www2.research.att.com/~gsf/publications/prus-1995-1.pdf，可以免费下载，它描述了大约1995年的游戏状态。从那以后，工具集变得越来越好和丰富，但是要想了解到底发生了什么，你真的需要这本书。这些家伙从贝尔实验室的Unix团队开始，他们创造的不是一个工具链，而是一种生活方式。乔·鲍勃说去看看。
• 在许多Unix工具链中，另一个普遍存在的元素是(这可能会让您大笑或呕吐) 埃马克斯。虽然Emacs并不是任何人最喜欢的编写插件或扩展的方式，但随着时间的推移，Emacs已经成为一个非常丰富、功能强大的编程环境--它还可以与其他各种工具交流。我喜欢简单，而不是复杂，所以我试着保持浅水区，但是如果您认真地研究Unix的工具链，这是需要了解的。

我期待看到你的问题有更多的答案。

Answer 3

它不是自由和开放源码软件，而是Rational提供了一个完整的工具链(除了编译器！)

您可以获得IDE、类图、用例、需求跟踪、测试工具、问题日志工具，这些工具以几千美元(或数百美元)的价格很好地集成在一起。

没有(从建模工具)是最好的品种，但，他们都是相当好的，并与彼此很好地集成。

免责声明：-我选择的“工具集”是vim，make，ddd，gmail和一个用于建模的moleskin笔记本。