現在平時寫的一些非規範文件有些亂、時間長了自己都有些看不懂。
主要的開發文件就是functional spec 和 technical spec。
functional spec 對映需求到功能性，
technical spec 對映功能到實現。
以後隨手寫一些文件的時候也依照這些要求，相對規範，比較容易將來整理形成正式文件。
內容大於形式，注重實效。乙份內容，乙份模版，需要的時候找乙個熟悉這部分內容的人，很快攢出乙份文件出來。
關鍵在內容的組織上，而不是模版形式本身。
如果把需求，功能，實現在不同層面上講清楚，層次清晰，詳略得當。需要業務知識、技術知識、專案經驗、分析能力、表達能力。
這些都是要在開發用的上的文件，內容一定要詳實，體現問題的前提假設、實際問題、解決問題的思路，以及可能會出現的問題。fs，ts只不過要體現問題的不同層面，層次把握也很重要。
文件裡面可以適當的給出一些圖示，圖示給人以更好的直觀印象，表達能力強於文字描述；但圖一定要規範，要有文字解釋，避免的誤解。沒有解釋的圖很容易誤解，既是是規範的uml也是一樣的。表達能力強的方式對理解者的要求比較高，抽象的層次相對高了，還是那句老話，問題本身的複雜度不會因表達的方式而簡化，而且更高的抽象層次往往需要理解者有更多的專業知識才能正確理解，否則誤解難以避免。
空洞的套話、忽悠的話對開發沒意義，沒必要的都不要。
mmx開發文件
i mmx簡介 ii mmx基本指令集 具體細節請參閱 intel 體系結構mmx技術程式設計師參考手冊 第五章 2.1 拷貝指令 movq 64位資料拷貝，如果記憶體8位對齊的話，是乙個64位寫，否則2個32位寫。movd 32位資料拷貝，注意 如果從記憶體向mmx暫存器拷貝，mmx高32位清零！...
zencart開發文件
在zencart開發中，做乙個新的功能模組時，首先要明確這個功能的流程和與原來 的關聯。然後，需要為這個功能模組取乙個名稱標識，盡量不要與原有的模組名稱不相同。zencart模組結構 1.資料庫資料表部分 2.後台管理部分 3.前台功能顯示部分 資料庫部分 zencart使用mysql數庫據，在設計...
RxJava開發文件
在我們的第乙個列子裡，我們將檢索安裝的應用列表並填充recycleview的item來展示它們。我們也設想乙個下拉重新整理的功能和乙個進度條來告知使用者當前任務正在執行。首先，我們建立observable。我們需要乙個函式來檢索安裝的應用程式列表並把它提供給我們的觀察者。我們乙個接乙個的發射這些應用...