做軟件以來，這個(gè)話題一直是自己很郁悶的一個(gè)地方，我們來看看軟件開發(fā)的過程，軟件開發(fā)的過程無論是采用傳統(tǒng)的瀑布、如今的迭代等方式都是一個(gè)需求-->設(shè)計(jì)-->實(shí)現(xiàn)的過程，在這整個(gè)過程當(dāng)中，每個(gè)環(huán)節(jié)都要有個(gè)完成的標(biāo)識(shí)，并且需要成為下一環(huán)節(jié)的前置條件、參考依據(jù)，這個(gè)時(shí)候通常的做法都是通過提供文檔的方式，但是在我所經(jīng)歷的開發(fā)當(dāng)中，我最郁悶的也是這點(diǎn)，需求這部我沒什么疑問，我覺得產(chǎn)生需求文檔是必須的，但其實(shí)就我所經(jīng)歷的開發(fā)來看，我認(rèn)為需求文檔對(duì)于用例最好不是僅僅依賴于描述，描述是沒人會(huì)仔細(xì)去看的，而最好是UI原型圖，這樣對(duì)于用例的表達(dá)會(huì)清晰些，當(dāng)然，有些復(fù)雜的部分仍然需要通過描述的方式。
來看設(shè)計(jì)部分，在這個(gè)部分我一直就覺得有些疑問，一直以來都不是很認(rèn)同在設(shè)計(jì)的輸出就是要提供一份詳細(xì)、規(guī)范的設(shè)計(jì)文檔，在我看來，設(shè)計(jì)確實(shí)是進(jìn)行實(shí)現(xiàn)的前提條件，這毫無疑問，但真的就一定要通過一份詳細(xì)的設(shè)計(jì)文檔來做到這點(diǎn)嗎？我覺得設(shè)計(jì)中最重要的設(shè)計(jì)理念的表達(dá)，而對(duì)于設(shè)計(jì)理念我覺得最佳的表達(dá)方式仍然是圖形，而這個(gè)圖形一定要采用規(guī)范的象UML這些來表示嗎？我并不是那么的認(rèn)同，我覺得設(shè)計(jì)圖最重要的就是要表現(xiàn)出自己的意思，至于你用什么圖形來表示我不覺得有什么重要，只要設(shè)計(jì)人員認(rèn)為那是他最擅長表達(dá)自己設(shè)計(jì)意圖的工具就行，沒必要在工具這件事上浪費(fèi)設(shè)計(jì)人員太多的時(shí)間，并且造成了限制，設(shè)計(jì)的評(píng)審我覺得是有必要做的，這時(shí)我覺得大家可能會(huì)問，沒有文檔怎么辦，怎么評(píng)審？我覺得評(píng)審的人是為了讓同行的設(shè)計(jì)人員能夠根據(jù)目前設(shè)計(jì)人員對(duì)圖形的一個(gè)解釋來準(zhǔn)備的了解設(shè)計(jì)人員的設(shè)計(jì)意圖，并且根據(jù)自己的經(jīng)驗(yàn)相應(yīng)的給設(shè)計(jì)人員一些建議；其次，從簡(jiǎn)單設(shè)計(jì)角度上來講，我覺得設(shè)計(jì)是一個(gè)不斷充實(shí)和完善的過程，設(shè)計(jì)是一個(gè)典型的求解過程，就象一道數(shù)學(xué)題，通常來說，也許會(huì)有N中解法，每個(gè)不同程度的人看到的解法也許是不一樣的，但首先能解出來這就是一個(gè)成功，其次才是看這個(gè)解法有什么可以改進(jìn)的地方，我現(xiàn)在做設(shè)計(jì)的時(shí)候就是首先采用自己目前能想到的最簡(jiǎn)單的解決方案，在做同行評(píng)審的時(shí)候也許有些同行能給出些建議，如果沒有的話，通常來說我會(huì)先按照這個(gè)簡(jiǎn)單的解決方案先做，在實(shí)現(xiàn)后其實(shí)就會(huì)發(fā)現(xiàn)目前這個(gè)實(shí)現(xiàn)方案的一些問題，即使當(dāng)時(shí)沒發(fā)現(xiàn)，在添加新功能的時(shí)候也會(huì)發(fā)現(xiàn)，這個(gè)時(shí)候依賴重構(gòu)開始進(jìn)行調(diào)整，其實(shí)我覺得只有這樣一個(gè)設(shè)計(jì)才能慢慢的被完善、被誕生，應(yīng)該說，不同程度的設(shè)計(jì)師的區(qū)別就在于設(shè)計(jì)出來的東西所被完善時(shí)投入的精力和造成的影響，我相信沒有哪個(gè)設(shè)計(jì)出來就是那么好的，在這種情況下，通常就會(huì)出現(xiàn)一個(gè)問題，就是最后實(shí)現(xiàn)形成的設(shè)計(jì)和最初的設(shè)計(jì)有很多的不同，這個(gè)時(shí)候是不是意味著在開發(fā)的過程中應(yīng)該一直去更新、維護(hù)設(shè)計(jì)文檔呢？所以我覺得最初的設(shè)計(jì)文檔不需要為了規(guī)范投入那么大的精力， 但不意味著不要，需要的是一份能夠表達(dá)設(shè)計(jì)意圖的文檔，最重要的是圖形化的表達(dá)，大家認(rèn)為呢？或者說大家都是怎么做的呢？還有就是這種時(shí)候正規(guī)的設(shè)計(jì)文檔什么時(shí)候出呢？^_^，缺少文檔時(shí)有的一個(gè)問題是怎么樣將設(shè)計(jì)意圖準(zhǔn)確的表達(dá)給開發(fā)人員，這部的做法在XP中通常不存在，因?yàn)閄P中設(shè)計(jì)是大家一起做的，在傳統(tǒng)的情況下我覺得更多的是依賴設(shè)計(jì)人員和開發(fā)人員的頻繁交流以及對(duì)于代碼的code review。
但缺少設(shè)計(jì)文檔在公司的運(yùn)作中通常會(huì)出現(xiàn)一個(gè)問題，就是領(lǐng)導(dǎo)們的不放心，領(lǐng)導(dǎo)們會(huì)覺得怎么經(jīng)過了這個(gè)階段沒啥正式的產(chǎn)物，領(lǐng)導(dǎo)們會(huì)認(rèn)為設(shè)計(jì)圖這些是不足以證明這個(gè)階段的完善的，郁悶，造成總是和領(lǐng)導(dǎo)形成矛盾，這也怪自己在安排任務(wù)時(shí)通常缺少這個(gè)正規(guī)的設(shè)計(jì)文檔的編寫過程，這個(gè)過程真的有這么必要嗎？疑問中......
ps：順便說下現(xiàn)在自己從設(shè)計(jì)到實(shí)現(xiàn)的一個(gè)步驟，在設(shè)計(jì)時(shí)首先我會(huì)根據(jù)目前的需求得出問題域，這個(gè)時(shí)候開始進(jìn)行設(shè)計(jì)，對(duì)問題域進(jìn)行求解，這個(gè)時(shí)候會(huì)給一個(gè)自己能想到的最簡(jiǎn)單的解決方案，注意，既然是解決方案就以為著首先要能解決問題，簡(jiǎn)單的解決方案不等于簡(jiǎn)陋的解決方案，在提供這個(gè)解決方案后開發(fā)人員實(shí)現(xiàn)后我會(huì)對(duì)code進(jìn)行review，而這個(gè)時(shí)候review經(jīng)常會(huì)發(fā)現(xiàn)設(shè)計(jì)中值得改善的地方，這個(gè)時(shí)候開始對(duì)設(shè)計(jì)進(jìn)行重構(gòu)，詳細(xì)設(shè)計(jì)一般要在迭代完成時(shí)才能最終形成.....覺得這樣的方法挺好的，^_^，自己在做實(shí)現(xiàn)的時(shí)候現(xiàn)在的做法都是先把測(cè)試代碼寫完后，寫設(shè)計(jì)的時(shí)候會(huì)先隨意的寫，寫完在通過測(cè)試后開始對(duì)代碼進(jìn)行重構(gòu)，這個(gè)時(shí)候開始把之初的長方法首先進(jìn)行重構(gòu)為小方法，重構(gòu)完后開始做封裝的考慮，形成對(duì)象模型，在對(duì)象模型形成后開始考慮繼承、多態(tài)的引入，最后開始考慮設(shè)計(jì)模式的引入，一般這個(gè)時(shí)候最終的詳細(xì)設(shè)計(jì)才得以形成，我覺得這個(gè)時(shí)候是體現(xiàn)一個(gè)設(shè)計(jì)師水平的時(shí)候，一個(gè)優(yōu)秀的設(shè)計(jì)師在設(shè)計(jì)之初就能想到很多，預(yù)見的很遠(yuǎn)，使得設(shè)計(jì)在設(shè)計(jì)之初就能足夠的完善，而不需要通過太多的重構(gòu)形成最終的設(shè)計(jì)，而一個(gè)普通的設(shè)計(jì)師也許最初只是能給出一個(gè)解決方案，但畢竟是可行的解決方案，在設(shè)計(jì)實(shí)現(xiàn)的過程時(shí)才逐漸的發(fā)現(xiàn)設(shè)計(jì)的不足，這個(gè)時(shí)候通過重構(gòu)進(jìn)行的完善，對(duì)設(shè)計(jì)師來講也是一種很好的積累，所以來說，在完成設(shè)計(jì)后最好是能多找人交流交流，^_^，喜歡這個(gè)方法.......