一千萬個為什麽

搜索

項目管理和捆綁依賴項

我一直在尋找方法來了解管理軟件項目的正確方法,我偶然發現了以下博客文章。我已經學到了一些難以理解的事情,其他事情是有道理的,但其他人仍然不清楚。

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

特別是,我不理解作者關於將依賴項與項目捆綁在一起的立場。這些是:

==捆綁==

  • 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)?

那麽您如何回應這些評論,以及我可能沒有考慮哪些方面?你是否同意或不同意作者的觀點(或我的觀點),為什麽?

編輯澄清。

最佳答案

您的源代碼僅附帶其依賴的其他代碼項目。

我的項目需要項目X.

但是,由於我的項目取決於X的秘密內部奧秘或X的先前版本,因此我的項目包括X的副本。特別是X.的釋放n.m。沒有其他。

嘗試安裝最新和最好的X,看看我的項目有什麽中斷。由於升級X破壞了我的項目,忘了我的項目。他們不會為更新後自發破壞的東西而掙紮。他們會找到一個更好的開源組件。

因此失敗分數。

如果沒有先構建捆綁的代碼位,就無法構建源代碼。

我的項目不依賴於X的API。它依賴於深層的內部鏈接到X的特定部分,繞過了API。

如果我的項目依賴於API到X,那麽 - 對於某些語言,如C或C ++ - 我的項目只能使用C或C ++頭文件而不是二進制文件進行編譯。

對於Java來說,這不太真實,因為沒有獨立的非二進制頭。對於動態語言(如Python),這沒有任何技術意義。

但是,即使是Java和Python也有辦法將接口與實現分開。如果我依賴於實現(而不是接口),那麽我仍然會創建同樣的基本問題。

如果我的項目依賴於C或C ++二進制文件,並且它們不按順序構建內容,或者在不重建我的情況下升級另一個組件,那麽事情可能會對它們造成嚴重影響。他們可能會看到古怪,破損,“不穩定”。我的產品壞了。他們不會(也不能)調試它。他們完成了。他們會發現更穩定的東西。

因此失敗分數。

如果您修改了其他捆綁代碼位。

我修改X時有兩個選擇。

  1. 將其作為X的一部分接受。

  2. 修復我的程序以使用未經修改的X.

如果我的項目依賴於修改過的X,那麽沒有人可以簡單,正確和獨立地安裝X.他們無法升級X,他們無法維護X.他們可能無法將錯誤修復或安全補丁應用於X.

我基本上通過修改X來完成他們的工作。

因此失敗分數。

隨後,您必須將這些更改發布給希望構建代碼的人。

實際上,他們會因此而恨我。他們不想知道X的神秘變化。他們想根據規則建立X,然後根據規則建立我的東西。他們不想閱讀,思考或確定神秘更新補丁包是否正確應用。

他們不會開玩笑,而是下載競爭套餐。失敗。

如果您的代碼庫依賴於特定版本的lib(您還需要為您的項目自定義編譯)

那真的很破舊。如果我依賴於自定義編譯的版本,他們就會查看我的包。在他們掙紮之前,他們會找到沒有版本特定的內在奧秘和自定義編譯的東西。失敗。

轉載註明原文: 項目管理和捆綁依賴項