我一直在寻找方法来了解管理软件项目的正确方法,并且偶然发现了以下博客文章。我已经学到了一些很难提到的东西,其他的很有意义,还有一些我仍然不清楚。
总而言之,作者列出了一个项目的一堆特性,以及这些特性对项目的“糟糕”贡献了多少,因为没有更好的术语。你可以在这里找到完整的文章:http: //spot.livejournal.com/308370.html
特别是,我不理解作者关于将依赖项与您的项目捆绑在一起的立场。这些是:
== 捆绑 ==
您的源代码仅附带它所依赖的其他代码项目 [+20 points of FAIL]
为什么这是一个问题,特别是考虑到第 3 点,您已经修改了项目的依赖项以适应项目的需求,因此,您的代码应该与其依赖项一起分发不是更有意义吗?
如果您的源代码在不首先构建捆绑代码位的情况下无法构建 [+10 失败分]
对于针对 3rd 方库构建的软件,这不一定是这种情况吗?您的代码需要在链接器工作之前将其他代码编译到其库中吗?
如果您修改了其他捆绑的代码位 [+40 失败点]
如果这对您的项目是必要的,那么很自然地,您已经将所述代码与您的代码捆绑在一起。如果你想定制一些库的构建,比如 WxWidgets,你必须编辑那些项目构建脚本来构建你想要的库。随后,您必须将这些更改发布给希望构建您的代码的人,那么为什么不使用已经写入参数的高级 make 脚本并分发呢?此外,(尤其是在 windows 环境中)如果您的代码库依赖于特定版本的库(您还需要为您的项目自定义编译),那么自己给用户代码不是更容易(因为在在这种情况下,用户不太可能已经安装了正确的版本)?
那么您将如何回应这些评论,以及我可能没有考虑到哪些方面?你同意还是不同意作者的观点(或我的观点),为什么?
为澄清而编辑。