项目管理和捆绑依赖关系
我一直在寻找方法来了解管理软件项目的正确方法，并且偶然发现了以下博客文章。我已经通过艰难的方式了解到了其中提到的一些事情，另一些是有道理的，但另一些对我来说仍然不清楚。
总而言之，作者列出了一个项目的一系列功能，以及这些功能对项目“糟糕”的贡献有多大，因为缺乏更好的术语。您可以在这里找到完整的文章：http://spot.livejournal.com/308370.html
特别是，我不理解作者对将依赖项与您的项目捆绑在一起的立场。这些是：
== 捆绑 ==
您的源代码仅附带它所依赖的其他代码项目 [+20 点失败]
为什么这是一个问题，特别是考虑到第 3 点，您已经修改了项目依赖项以满足项目的需求，因此您的代码应该与其依赖项一起分发不是更有意义吗？
如果在不首先构建捆绑代码位的情况下无法构建源代码 [+10 点失败]
对于针对第 3 方库构建的软件来说，这不一定是这种情况吗？您的代码需要将其他代码编译到其库中，链接器才能工作吗？
如果您修改了其他捆绑代码位 [+40 点失败]
如果这对于您的项目是必要的，那么您自然会将上述代码与您的代码捆绑在一起。如果您想自定义某些库的构建，例如 WxWidgets，您必须编辑该项目构建脚本来构建您想要的库。随后，您必须将这些更改发布给希望构建您的代码的人，那么为什么不使用已写入参数的高级 make 脚本并分发它呢？此外，（特别是在 Windows 环境中）如果您的代码库依赖于特定版本的库（您还需要为您的项目进行自定义编译），那么您自己向用户提供代码不是更容易吗（因为在在这种情况下，用户不太可能已经安装了正确的版本）？
那么你会如何回应这些评论？我可能没有考虑到哪些点？您同意还是不同意作者（或我的）的观点，为什么？
编辑以澄清。
I've been looking for ways to learn about the right way to manage a software project, and I've stumbled upon the following blog post. I've learned some of the things mentioned the hard way, others make sense, and yet others are still unclear to me.
To sum up, the author lists a bunch of features of a project and how much those features contribute to a project's 'suckiness' for a lack of a better term. You can find the full article here: http://spot.livejournal.com/308370.html
In particular, I don't understand the author's stance on bundling dependencies with your project. These are:
== Bundling ==
Your source only comes with other code projects that it depends on [ +20 points of FAIL ]
Why is this a problem, especially given point 3, that you have modified your projects dependencies to fit your project's needs, doesn't it therefore make even greater sense that your code should be distributed with its dependencies?
If your source code cannot be built without first building the bundled code bits [ +10 points of FAIL ]
Doesn't this necessarily have to be the case for software built against 3rd party libs? Your code needs that other code to be compiled into its library before the linker can work?
If you have modified those other bundled code bits [ +40 points of FAIL ]
If this is necessary for your project, then it naturally follows that you've bundled said code with yours. If you want to customize a build of some lib,say WxWidgets, you'll have to edit that projects build scripts to bulid the library that you want. Subsequently, you'll have to publish those changes to people who wish to build your code, so why not use a high level make script with the params already written in, and distribute that? Furthermore, (especially in a windows env) if your code base is dependent on a particular version of a lib (that you also need to custom compile for your project) wouldn't it be easier to give the user the code yourself (because in this case, it is unlikely that the user will already have the correct version installed)?
So how would you respond to these comments, and what points may I be failing to take into consideration? Would you agree or disagree with the author's take (or mine), and why?
Edited for clarification.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的项目需要项目 X。
但是，由于我的项目依赖于 X 的秘密内部奥秘，或者 X 的先前版本，所以我的项目包括 X 的副本。特别是发布 X 的 nm。没有其他。
尝试安装最新、最好的 X，看看我的项目有什么问题。由于升级 X 破坏了我的项目，所以忘记我的项目吧。他们不会为更新后自发损坏的东西而烦恼。他们会找到更好的开源组件。
因此得分为“不及格”。
我的项目不依赖于 X 的 API。它依赖于绕过 API 到 X 的特定部分的深层内部链接。
如果我的项目依赖于 X 的 API，那么对于 C 或 C++ 等某些语言，我的项目可以仅使用 C 或 C++ 头文件进行编译，而不是二进制文件。
对于 Java 来说，情况不太如此，因为没有独立的非二进制标头。对于动态语言（如 Python）来说，这没有技术意义。
然而，即使是 Java 和 Python 也有方法将接口与实现分开。如果我依赖实现（而不是接口），那么我仍然会产生相同的基本问题。
如果我的项目依赖于 C 或 C++ 二进制文件，并且他们无序地构建东西，或者升级另一个组件而不重建我的项目，那么事情可能会变得很糟糕。他们可能会看到怪异、破损、“不稳定”。我的产品似乎已损坏。他们不会（也不能）调试它。他们完成了。他们会找到更稳定的东西。
因此得分为“不及格”。
当我修改 X 时，我有两个选择。
让它被接受为 X 的一部分。
修复我的程序以使用未修改的 X。
如果我的项目依赖于修改过的 X，那么没有人可以简单、正确和独立地安装 X。他们无法升级 X，他们无法维护 X。他们可能无法对 X 应用错误修复或安全补丁。
我基本上通过修改 X 使他们的工作变得不可能。
因此 FAIL 分数。
事实上，他们会因此而恨我。他们不想知道X的神秘变化。他们想按照规则构建X，然后按照规则构建我的东西。他们不想阅读、思考或确定神秘更新补丁包是否已正确应用。
他们不会拿这个开玩笑，而是会下载一个竞争包。失败。
那真是太糟糕了。如果我依赖于具有自定义编译的版本，他们就会检查我的包。他们会在陷入困境之前找到一些没有特定于版本的内部奥秘和自定义编译的东西。失败。
My project requires project X.
However, since my project depends on secret inner mysteries of X, or a previous release of X, then my project includes a copy of X. Specifically release n.m of X. And no other.
Try to install the latest and greatest X and see what breaks in my project. Since upgrading X broke my project, forget my project. They will not struggle with something that spontaneously breaks after an update. They will find a better open source component.
Hence a FAIL score.
My project doesn't rely on the API to X. It relies on deep, inner linking to specific parts of X, bypassing the API.
If my project on depended on the API to X, then -- for some languages like C or C++ -- my project could compile with only the C or C++ headers, not the binaries.
For Java this is less true, since there is not independent, non-binary header. And for dynamic languages (like Python) this makes no technical sense.
However, even Java and Python have ways to separate interface from implementation. If I rely on implementation (not interface), then I've still created the same essential problem.
If my project depends on C or C++ binaries, and they build things out of order, or upgrade another component without rebuilding mine, things may go badly for them. They may see weirdness, breakage, "instability". My product appears broken. They won't (and can't) debug it. They're done. They'll find something more stable.
Hence a FAIL score.
I have two choices when I modify X.
Get it accepted as part of X.
Fix my program to work with unmodified X.
If my project depends on a modified X, no one can install X simply, correctly and independently. They can't upgrade X, they can't maintain X. They probably can't apply bug fixes or security patches to X.
I've essentially made their job impossible by modifying X.
Hence the FAIL score.
Actually, they'll hate me for that. They don't want to know about the mysterious changes to X. They want to build X according to the rules, then build my stuff according to the rules. They don't want to read, think or be sure that the mystery update patch kit was applied correctly.
Rather than joke around with that, they'll download a competing package. FAIL.
That's really shabby. If I depend on a version with custom compiles, they're done looking at my package. They'll find something without version-specific inner mysteries and custom compiles before they'll struggle. FAIL.