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

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

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

　　大多數(shù)的程序員沒有主動(dòng)寫文檔的習(xí)慣，這個(gè)可以接受，因?yàn)椴⒉皇撬械奈臋n都有用，大概九成以上的文檔是實(shí)際上的多余。

　　大家應(yīng)該仔細(xì)考慮文檔所處的位置和作用。 ——為什么不剪裁？ ——因?yàn)槲覀儾恢滥男┬畔⑹怯杏玫男畔ⅲ詻]有辦法建立“有用”的文檔。 在開發(fā)工具和開發(fā)模式高度發(fā)達(dá)的今天，我們還在用“手工作坊”的方式寫著文檔。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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