關(guān)于功能詳細設(shè)計的討論
1令狐沖問：我感覺自己找不到太準確的衡量標準，我寫到什么程度算深淺適中，我不知道如何下手，好像有些東西不在寫代碼之前想不出來，有現(xiàn)成的模板嗎？
風清揚答：我們也想找個模板，可是網(wǎng)上的都是站著不腰疼，都是什么CMM，ISO9000
寫個故事，比如你去客戶那調(diào)查完了，你模擬一下客戶的工作過程，然后寫下來，不就成了？
不過可不要寫成客戶以后怎么使用你的軟件的過程，比如按一個按鈕然后….。寫成流水帳也沒關(guān)系，你看看你會有什么感覺。往往是正式做而真不知道該怎么做了，在自己閑暇時卻偏偏做好了，你說怪不怪？
然后交給其他同事閱讀，看他是否理解，把他的想法再填加到你的文檔中，你的文檔才會一點一點完善和趨于合理，羅馬不是一天建成的，想集中一段時間搞一個完善的東西是不可能的，事物是迭代進步的。
把事情你覺得說清楚了，別人看了也覺得清楚了，并且可以按照你的思路復(fù)述一遍，這就可以了。
如果還是不太明確你想做的事，搭一個小程序，按你的現(xiàn)有描述實現(xiàn)一個簡單的例子，在過程中想想有哪些你寫的代碼卻沒有描述，或者代碼與你的描述兩張皮，然后再試著修改文檔。
如果還是不清楚，如果你做過代碼維護工作，你想你在維護別人的代碼的時候最需要看到什么，這樣你就會知道你寫些什么
在寫文檔時沒必要我們想破腦子把所有的情況都想到都寫下來，那不可能，我們大家都憎恨這種不現(xiàn)實的東西。設(shè)計時描述不清楚的就不要描述，咱們干嗎非要固定不可能固定的東西呢？
但是有沒有一種方法，什么是可以描述清楚的，什么是不可描述清楚的呢？
2令狐沖問：為什么要寫呀，未來變化多端，你非要固定下來按這樣去做，這是軟件工程早就證明了的一種死辦法，我們應(yīng)該寫了客戶有什么問題，我們怎么解決的記錄下來，具體怎么實現(xiàn)，就由程序員決定，開發(fā)完了再寫詳細設(shè)計文檔，這樣的文檔才是真正的設(shè)計文檔。
風清揚答：》開發(fā)文檔就是把你的開發(fā)過程包括你的開發(fā)思想和各種問題的解決方法都記錄下來，
這是我們的需求分析文檔
》只是告訴要實現(xiàn)什么功能，
這是我們的功能概要描述呀
》程序員就記錄在開發(fā)文檔里面
這是我們的功能詳細描述和數(shù)據(jù)流詳細描述
》但以前我都是先寫程序再寫開發(fā)文檔，程序沒出來以前只有一份設(shè)計文檔
先寫程序再寫開發(fā)文檔，是為了以后人員的維護，來理解現(xiàn)在這個軟件是怎么回事。我們的這個詳細設(shè)計文檔也就是說清楚每個功能的大致流程，流程中涉及到的一些異常業(yè)務(wù)，業(yè)務(wù)中的術(shù)語，讓我們在編碼前好知道我們做出來的這個東西大致是什么樣，而不是我們就試著寫吧，遇到問題再說。那樣就不是商業(yè)的軟件開發(fā)。商業(yè)的軟件開發(fā)必須對進度，風險，成本有相當?shù)念A(yù)測。當然我們寫完詳細設(shè)計文檔也不是什么問題都沒了，我們也會在遇到問題時商討，但至少我們對我們要干的事的輕重緩急有一個大致的預(yù)測。
我們寫的也不是培訓(xùn)文檔。培訓(xùn)文檔是對照一個軟件，有什么DBGRID，有什么下拉框，先點什么按鈕。如果你的詳細設(shè)計文檔寫成了這樣，就出了問題。不是詳細設(shè)計的大思路錯了，就是你的功能概要設(shè)計劃分的太細了
3令狐沖問：那我們該寫些什么文檔，我們可忙著呢，別費了好大勁，寫出來也沒人看，沒人檢查，格式也不知道，各有各的寫法，最后不了了之。
風清揚答：我們不是為了文檔漂亮，給客戶看，給老板看，那樣是出不來好產(chǎn)品的，我們的文檔給我們是給我們在編碼期自己看的，看你對業(yè)務(wù)的了解是否用文字可以描寫清楚，如果能用文字描述清楚，你們寫代碼我們也就不擔心了。
就是怕：我們不知道你們理解不理解，你們自己也不知道是不是理解了，于是大家就開始瞎做吧，做到哪算哪，好壞也不是我一個人的錯。如果造成那樣的后果，我們現(xiàn)在所做也就沒有什么意義了
反正就是不要讓我們在做每一個工程時都思考我該怎么寫，以告戒其他同志正確的思考方向，不要重復(fù)思考別人思考過的問題；并且整理出一份你希望的詳細功能描述文檔的格式，以有個草案讓我們逐步改進它使它合理
所以我們準備寫這幾個文檔：
需求文檔
模塊進度文檔 為了估計最后的出品日期和每個模塊的工作量
功能概要文檔 為了在編碼期制定每周工作計劃，編制每個功能的詳細設(shè)計和數(shù)據(jù)流設(shè)計
表結(jié)構(gòu)文檔
|
|
資源大小：9.99 KB 
