最近在一個軟件公司實習(xí)，這是一個小型的公司，承接政府和事業(yè)單位的一些工程項目。 我在這個企業(yè)所遇到的所有事情相信在中國絕大多數(shù)地方和絕大多數(shù)軟件企業(yè)中尤為重要。

　　我已經(jīng)在很多次的公開場合批評過形式化的軟件工程，就是將書本上所要求的軟件工程實踐內(nèi)容不經(jīng)過任何具體化的措施和方法直接形式化套用。 這個做法的后果是極大的浪費了時間和資源，打擊了開發(fā)者的積極性。

　　文檔的本質(zhì)是什么？為什么要寫文檔？什么樣的文檔才是有用的文檔。

　　大多數(shù)的程序員沒有主動寫文檔的習(xí)慣，這個可以接受，因為并不是所有的文檔都有用，大概九成以上的文檔是實際上的多余。

　　大家應(yīng)該仔細考慮文檔所處的位置和作用。 ——為什么不剪裁？ ——因為我們不知道哪些信息是有用的信息，所以沒有辦法建立“有用”的文檔。 在開發(fā)工具和開發(fā)模式高度發(fā)達的今天，我們還在用“手工作坊”的方式寫著文檔。

　　我們的開發(fā)是進步了，可是我們的文檔化卻沒有進步。 我對軟件工程一直秉持著實用化的態(tài)度。這個和RUP的原則也頗為類似。

　　作為一種可以剪裁的軟件過程方案，RUP在實際的應(yīng)用上已經(jīng)遠遠做到了我們現(xiàn)在還沒有做到的境界。

　　從需求、設(shè)計、實現(xiàn)、編碼、測試的一系列過程。我們需要的是“準確記錄”，而不是文字堆砌的卷宗。

　　文檔的本質(zhì)就是“記錄”，而記錄的方法卻有多種多樣，“我們沒必要用文字成篇的去描述，而一兩個圖形或者圖像更有表現(xiàn)力”，UML如是說。 而我在前篇文章所說的帶著一部DV去做需求，還是因為在需求的過程中需要采集需求，進而就需要記錄。

　　而文字的表達能力是有限的，你不可能把一部人性化的軟件交給一疊冷冰冰的紙張。因此，我們需要廣泛的采集需求的信息。這時我們是在同客戶分享一種感覺，一種用軟件的感覺。 說到需求的分析，用例圖給了一種改進，但不是里程碑式的改進。微軟的開發(fā)過程就充分的體會到這樣的問題，所以提出了一些改進的措施，可能是因為微軟所做的軟件并不是管理系統(tǒng)的原因吧。 到了設(shè)計和開發(fā)，作為結(jié)構(gòu)最主要的表達——圖形發(fā)揮了很大的作用，目前為止應(yīng)該是最豐富的表達方法。

　　 然而我們卻亂畫一氣……不根據(jù)變更的需求去變更設(shè)計……設(shè)計文檔又成了一種形式。我在很多地方都看不到設(shè)計文檔，因為這個依靠想象力和創(chuàng)造力的領(lǐng)域變化的太快，文檔跟不上思維。而我們需要的是一種可以經(jīng)過反復(fù)討論的設(shè)計思路，我們需要統(tǒng)一的設(shè)計規(guī)范——設(shè)計模式。它告訴我們在什么樣的情況下需要什么樣的設(shè)計。而Gof-23模式甚至不夠用，他們只是遵循了某種面向?qū)ο蟮脑瓌t。

　　但是AOP是否有這樣的模式呢，據(jù)我了解，是有的，只是很少有人總結(jié)。我希望很多專心于AOP的人可以像專心于OOP的那樣總結(jié)出一些設(shè)計模式。 編碼階段的文檔——這可能是大多數(shù)軟件工程實踐中最成篇累牘但是最沒有用的文檔了。 我所提倡的是良好的設(shè)計，良好的設(shè)計可以讓編程人員（無論是專業(yè)還是非專業(yè)）對于實現(xiàn)可以做到一目了然。類似于一種模式，例如某個地方需要冒泡排序，我們就知道代碼如何實現(xiàn)的。而不用考慮它是怎么實現(xiàn)的。

　　設(shè)計文檔就要做到這一步，能夠很輕松的告訴編碼者整個框架是什么，整個結(jié)構(gòu)是什么，而到了具體實現(xiàn)需要怎么做。而到了這一步，我們所需要的文檔可能很少，甚至——沒有。 編碼階段一直提倡的是自文檔化的代碼。這樣的代碼不光極具可讀性，而且極具格式和規(guī)范性。我們所需要的可能僅僅是一份編碼規(guī)范。剩下的，交給注釋吧。

　　 或者可以說：文檔即是代碼，代碼即是文檔。 這是編碼文檔的理想境界。但是這是需要很好設(shè)計才能做到的。而這樣的設(shè)計是需要長期編碼-設(shè)計，設(shè)計-編碼訓(xùn)練才可以達到的境界。

　　 而代碼規(guī)范，便是這個階段最重要的因素了。好的代碼規(guī)范會早就高可讀性的代碼——這是我們不需要在編碼階段另寫文檔的重要原因。因為這樣不光可以節(jié)省了時間和資源，還提高了代碼的質(zhì)量。

　　關(guān)于測試階段的文檔，這應(yīng)該是及其重要的一環(huán)。如果是使用的RUP的軟件過程，和現(xiàn)在通常使用的螺旋模型的話，當(dāng)然類似的模型可以。這類軟件要求測試對需求能夠有一個反饋，這是大家常用的模型的特點。

　　 而測試文檔在這里所扮演的角色不光是記錄，更多的是一種報告。包括從各種測試得出的分析及分析的對策。就像資深會計師對公司的運作情況和未來發(fā)展給出的分析一樣。

　　資深的測試人員一定會對整個軟件從需求、設(shè)計、到編碼有最全面的把握。 所以，測試在軟件工程中有很重要的位置。而不是所謂的簡簡單單“質(zhì)量保證”或者“驗證”，因為，質(zhì)量是沒辦法保證的。測試不可能也沒有必要窮舉。因此測試文檔不光要找出問題，更要有清晰的思路，因為新的需求會從這份分析報告（文檔）中給出。這往往是大多數(shù)測試人員忽略的一環(huán)。

　　這些僅是我的所思所感，歡迎與我討論。

　　我的原則是，軟件工程一定要實用，要切實的有用而不是為了點綴而做的形式上的工作。 拒絕形式化的軟件工程，拒絕形式化的文檔。

it知識庫：拒絕形式化的軟件工程文檔，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。