项目管理和捆绑依赖关系

Question

我一直在寻找方法来了解管理软件项目的正确方法，并且我偶然发现了以下博客文章。我已经学会了一些难以提及的事情，其他人有意义，但其他人对我仍然不清楚。总而言之，作者列出了项目的一大堆功能，以及这些功能对缺乏更好的术语而导致项目“糟糕”的程度有多大的影响。你可以在这里找到完整的文章：http://spot.livejournal.com/308370.html

特别是，我不明白作者的立场捆绑依赖与您的项目。它们是：

== ==捆绑

• 你的信号源仅附带了这取决于[+20 FAIL的分]其他代码项目

  为什么这是一个问题，尤其是考虑第3点，你已经修改了你的项目依赖项以适应你的项目需求，那么它是否更有意义，你的代码应该与它的依赖关系一起分发？

• 如果你的源代码，如果不首先建立捆绑的码位[FAIL的+10分]建

  这难道不是一定要为构建针对第三方软件库的情况下？您的代码需要其他代码在链接器可以工作之前编译到其库中？

• 如果您已修改与其他捆绑码位[FAIL +40分]

  如果这是必要为您的项目，那么它自然你捆绑表示，与你的代码。如果你想自定义某个库的构建，比如说WxWidgets，你必须编辑该项目的构建脚本来建立你想要的库。随后，您必须将这些更改发布给希望构建代码的人员，那么为什么不使用已经写入参数的高级make脚本并将其分发？此外，如果你的代码库依赖于一个特定版本的lib（你还需要为你的项目自定义编译），那么（特别是在Windows环境下）不会更容易让用户自己编写代码（因为在这种情况下，用户不太可能已经安装了正确的版本）？

那么您如何回应这些评论，以及我可能没有考虑到哪些问题？你会同意还是不同意作者的观点（或我的观点），为什么？

编辑澄清。

Answer 1

您的源代码仅随其它依赖的代码项目提供。

我的项目需要项目X.

但是，因为我的项目依赖于X，或X的前一版本的秘密内部奥秘，那么我的项目包括X的副本，具体释放X的纳米没有别的。

尝试安装最新最好的X并查看我的项目中有哪些中断。由于升级X打破了我的项目，忘记了我的项目。他们不会与更新后自发断裂的东西纠缠。他们会找到一个更好的开源组件。

因此FAIL得分。

如果您的源代码在没有先构建捆绑代码位的情况下无法构建。

我的项目并不依赖于X的API。它依赖于深入的内部链接到X的特定部分，绕过API。

如果我的项目依赖于X到X的API，那么对于像C或C++这样的语言，我的项目只能编译C或C++头文件，而不是二进制文件。

对于Java来说，这是不太正确的，因为没有独立的非二进制头。对于动态语言（比如Python），这没有任何技术意义。

但是，即使Java和Python也有办法将接口与实现分开。如果我依赖实现（而不是接口），那么我仍然创建了相同的基本问题。

如果我的项目依赖于C或C++二进制文件，并且它们不按顺序构建，或者升级另一个组件而不重建我的项目，那么对他们来说事情可能会变得很糟糕。他们可能会看到古怪，破碎，“不稳定”。我的产品显示损坏。他们不会（也不能）调试它。他们完成了。他们会发现更稳定的东西。

因此FAIL得分。

如果您修改了其他捆绑的代码位。

我有两个选择，当我修改X.

1. 得到它接受为X.

2. 的部分修复我的程序与未改性的X.工作

如果我的项目依赖于修改的X，那么没有人可以简单，正确和独立地安装X.他们不能升级X，它们不能保持X.他们可能无法应用错误修复或安全补丁为X.

我已经基本上通过修改X.

因此，做他们的工作是不可能的FAIL分数。

随后，您必须将这些更改发布给希望构建代码的人员。

其实，他们会恨我的。他们不想知道X的神秘变化。他们希望按照规则构建X，然后按照规则构建我的东西。他们不想阅读，思考或确定神秘更新补丁包是否正确应用。

而不是开玩笑说，他们会下载一个竞争的软件包。失败。

，如果你的代码库是依赖于一个lib的特定版本（你还需要定制编译为您的项目）

这真是寒酸。如果我依赖于自定义编译的版本，他们已经完成了我的包装。他们会发现一些没有特定版本的内在奥秘和自定义编译之前，他们会奋斗。失败。