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

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

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

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

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

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

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

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

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

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

　　 然而我們卻亂畫一氣……不根據變更的需求去變更設計……設計文檔又成了一種形式。我在很多地方都看不到設計文檔，因為這個依靠想象力和創造力的領域變化的太快，文檔跟不上思維。而我們需要的是一種可以經過反復討論的設計思路，我們需要統一的設計規范——設計模式。它告訴我們在什么樣的情況下需要什么樣的設計。而Gof-23模式甚至不夠用，他們只是遵循了某種面向對象的原則。

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

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

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

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

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

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

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

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

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

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

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