技術文件編寫首先尋找資料，閱讀資料可以和編寫文件同時進行，即編寫段落一時查詢段落一的相關資料，當編寫到後面的段落時，發現和前面的段落有衝突，在回頭整改，整個過程類似於absd和螺旋開發模式。
第二部分技術文件編寫通常是指系統設計或者系統相關資料，系統的設計與開發的目的自然就是首要位置，其次就是系統的約束，有哪些規則約束的當前系統。最後設計原則或者方法，我們要用什麼樣的方法去設計系統。
第三部分就是系統設計完成狀態的展示，展示首先是總體展示，總體展示可細分為很多項，可以根據專案自行選擇，如整體用例圖、拓撲圖、結構圖，當然總體系統描述是不可缺少的。
之後是主要功能展示，即大專案是子系統或者模組描述，小系統是功能描述。
第四部分是決策，該部分並不是必須的，但是，如果當前技術文件是展示重構或者有類似的功能調整或者技術調整或者架構調整時，該部分是必不可少的，決策很簡單，只要描述變更點就可以了。
第五部分我稱之為邊界，該部分描述與系統連線的內容，比如介面、資料庫等，這些內容是系統的一部分，但又不在模組之中，所以單獨拿了出來。另外，如果當前文件有第四部分，則邊界的編寫則需涵蓋變更點。
第六部分擴充套件，擴充套件即可移植性、可擴充套件性、可維護性、可配置性等描述。
第七部分是效能與安全，效能與安全可以並存也可以只有其一，如果是小系統甚至可以不描述。
第八部分是故障，該部分可以有，也可以沒有。
第九部分是總結，總結當前文件，描述當前文件實現後的結果，即願景。這個部分也是可有可無。
，非常感謝！
技術文件編寫經驗總結
又乙個專案即將結束，從編寫技術文件 開發到聯調，8個人還不到兩周的時間，居然完成了，想想自己都很吃驚。雖然是個小專案，但還是有很多東西需要沉澱下來。正好晚上吃飽了沒事幹，寫個部落格記錄一下技術文件編寫經驗 1 對於乙個快速迭代的專案，存粹 簡單的資料模型 介面描述式的技術文件對整個專案還是有指導 推...
小議程式設計師編寫技術文件
一提到寫文件，可能很多程式設計師可能會不屑一顧，但是，無論處於規範開發流程，還是就於逃避嫌責的目的，能夠將自己所從事的工作用文件描述記錄下來，還是一件很有成就感的事情，拋開其功用不談，就個人的成長程序看，也是乙個循序漸進式的好習慣，還是值得大家稍微關注一下的。昨天在和同事的一次交流過程中，就自己編寫...
winSocket編寫心得
剛開始編定 winsock api每次編寫都要呼叫wsastartup 結束都到呼叫wsacleanup c socket和c 就沒有那麼麻煩，把它封裝起來了,又發現乙個有趣的事，c 宣告類後就可以用不像c 還得new winsock api socket bind listen accent re...