項目管理和捆綁依賴關係

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的特定版本（你還需要定製編譯爲您的項目）

這真是寒酸。如果我依賴於自定義編譯的版本，他們已經完成了我的包裝。他們會發現一些沒有特定版本的內在奧祕和自定義編譯之前，他們會奮鬥。失敗。