開源項目

Question

您可以在網上找到許多開源項目（如Linux，開放式辦公，...）

，但我沒有找到一個完整的，不錯過任何開源項目和REAL文檔。

我不是說只是源文件。我的意思是，收集客戶需求，設計模式和所有文件。

親切的問候

Answer 1

爲什麼我們有要求文件和設計文件？敲定兩方之間的協議，一方需要某種軟件，另一方則負責實現。該文件非常有用，因爲它可以幫助雙方共同合作，高效地製作正確的軟件。

有時在開源軟件中，你可以找到那種關係。在這種情況下，您有時可以找到預先設計的文件。如果你想添加一個功能到Python編程語言，你必須編寫一個Python Enhancement Proposal並獲得批准，以確保你正在實現的是Python維護者願意採用的。你可以在this page of OpenSolaris documentation找到很多設計文檔的鏈接;我猜這裏的「客戶」是Sun的營銷。我最近爲其他人實施的某些開源軟件設計了一個API，併爲此提供了一個開源軟件。

但很多開源的發展遵循一個完全不同的模型，其中以下因素一個或多個適用於：

• 工作的單位是一個單一的功能或錯誤修復。通常在錯誤跟蹤系統中，您可以找到一段需求文檔，如果您想以這種方式思考它們。較小的工作單位實際上很大的優勢;封閉源代碼開發往往不能遵循這種模式，因爲交易成本（建立信任，確定需要什麼，商定範圍和價格等）過高。

• 開發人員正在爲自己開發軟件。如果你知道你想要什麼，寫一份正式的設計文件可能沒有成效。 （你可能會在白板上寫幾條曲線。）

• 該項目最初並不打算廣泛使用。如果代碼將在一小時內在機器上運行並完成其工作，那麼單獨的設計文檔將如何提供幫助？如果它隨着時間的推移而成長爲其他人可以使用的東西，那麼過程文檔應該在什麼時候進入圖片？

• 有一個設計文件，但它沒有被公開。請記住，這些文檔的目的是幫助高效地製作正確的軟件。一旦完成，這些文件就不是非常有用。 （另外：開源軟件通常是根據公司的合同編寫的，雖然完成的代碼是公開的，但是過程文檔可能被明確或隱含地視爲保密）。前面的設計。我傾向於認爲這太糟糕了，但唉，這是一個促成因素。

有時軟件記錄後，它的實施和驗證。這裏是描述其內部的the GCC manual的一部分。這裏有一個關於Mozilla's JavaScript engine。如果您有一個特定的項目感興趣，找到示例相當容易。使用Google搜索linux kernel design找到more free, detailed documentation。

Answer 2

開源項目通常由癢不像開始瞄準了豐富的潛在客戶（客戶要求）專有應用程序從頭開始。設計模式與文檔無關。這只是樣板設計。至於文書工作，你會讓這聽起來像是一件「好事」。 :)

有一些開源項目在實施前提前詳細設計。想到的是bzr DVCS。 Docs Here。 Martin Pool在開始工作之前花了很長時間記錄下來。

Answer 3

看看（早期版本）jHotDraw。這是a.o.的HotDraw框架的java版本。 Erich Gamma（GoF）爲他的模式語言工作而開發。

您不可能找到包含依賴關係圖在內的完整和最新文檔的任何項目（開放源代碼或封閉源代碼）。爲了教育目的，您可能會找到一些非常小的構建。對於法律規定的系統，文件的實際質量通常很低，因爲它們不是爲了信息的作者或消費者的真正利益而產生的，而僅僅是爲了承擔法律責任。

在開源項目中，強烈傾向於只編寫直接使用的文檔，因爲它們具有非常好的工作優先級過程。交流工作需要交流。文檔可以提供。但是在大多數開源項目中，希望某個功能的人也可以成爲該功能的實現者。在這種情況下，很少需要大量文檔。 開源項目需要概述文檔描述工作標準，使用的設計模式以及可以幫助新貢獻者加快速度的所有內容。

如果你想真正瞭解它是多麼的困難妥善管理的依賴，來看看：

管理設計數據：CAD框架，配置管理，產品數據管理 麪包車的五個維度den Hamer，P .; Lepoeter，K. 訴訟的IEEE 卷84，第1版，1996年1月頁數：42 - 56 數字對象標識符10.1109/5.476025