?????? 計算機專業(yè)畢業(yè)的學(xué)生在學(xué)校當(dāng)中，都讀過軟件工程這本書，而軟件工程的書，都無一例外的，強行規(guī)定了一個編碼階段，并且十分嚴(yán)肅的告訴學(xué)生，代碼在整個軟件過程的生命周期階段當(dāng)中，只占了1/5左右。需求分析和設(shè)計、項目管理，更強于代碼。我想對這于剛畢業(yè)的學(xué)生，是一種思想上的毒害，很多人剛畢業(yè)一兩年，都耐不住性子，哭著喊著，要做architect，要做PM。
??????? 我認(rèn)為回避代碼是可恥的，只要編碼有意義，我們在任何階段，都應(yīng)當(dāng)投入到編碼當(dāng)中。
?? 最近一個項目，我下面有兩個設(shè)計人員（GM派過來的），協(xié)助我做設(shè)計，我做了一個設(shè)計的骨架，然后交給他們?nèi)サ?xì)化。下班前，我去看看他們的工作只有一些空洞的UML圖和一個還沒有寫內(nèi)容的概要設(shè)計模板，我對他們說，不要求你們?nèi)懳臋n，我也沒有時間去看，我不知道你們以前，是怎么做這設(shè)計的，但在我這個組，這樣做，不行。做為設(shè)計者，首先是自己要理解要做的東西，并且真正知道怎么去設(shè)計它才能滿足涉眾需求，第二步，才是讓別人能夠理解你的設(shè)計。怎么樣讓別人理解你的設(shè)計，文檔并不是唯一的途徑，對于普通程度員來講，白板上的講解和直白的代碼注釋甚至比UML圖更容易理解和平易近人，我們很多的設(shè)計者，總是喜歡用大量的4＋1 UML圖和文檔中生硬、冰冷的詞匯來嚇唬程序員，恰恰反映出了設(shè)計者內(nèi)心的空虛與膽怯。
?? 以往自身的設(shè)計經(jīng)歷，談一下：
?????? 我第一次給另一個組做一個子模塊的設(shè)計時，心里很緊張，因為我不在他們那個組中，也不參與他們的開發(fā)，這個設(shè)計對于他們的項目進度來說，又是一個關(guān)鍵路徑，我生怕我自己設(shè)計的不好，考慮問題考慮的不周到，在項目后期，如果出現(xiàn)問題，自己責(zé)任重大。
?????? 我對他們說，這個設(shè)計需要兩個星期，其實我只化了三天，就把接口文檔寫好了，我對著接口考慮來考慮去，還是覺得沒有底，我忍不住想寫代碼，來驗證這樣做對不對，又怕別人說我的設(shè)計能力不強。我就偷偷摸摸的寫代碼，又和他們的組的主要使用者反復(fù)溝通了幾次，根據(jù)需求，設(shè)計了幾種不同的案例，來驗證我的設(shè)計是否有漏洞。
?? 最后，又對接口修復(fù)了幾次，覺得接口相對穩(wěn)定和健壯了，就讓他們過來看看，提出問題，結(jié)果也沒有提出什么問題。于是我就交工了。
?? 實事上，這個接口，在開發(fā)后期，還是有一點修改，但并沒有給他們的項目造成很大的影響，他們自己也認(rèn)為能考慮的這么全面，已經(jīng)不易。
?????? 做開發(fā)這么多年，越來越覺得設(shè)計是一個很復(fù)雜的東東，他不像建筑工程中的設(shè)計一樣，可以用工程化的方法去中規(guī)中矩的驗證，并交給工人進行構(gòu)造。但如果沒有好的驗證方法，一個設(shè)計就交工了，大家都沒底。就好像選擇是獅子還是公主，只有把門打開才能知道。
????? 這幾年，我經(jīng)歷的每個項目，幾乎都有評審，需求評審，設(shè)計評審等等，但我現(xiàn)在回想過來，我想不出對我的項目有太多的意義，很多人癡迷于通過文檔和評審來試圖證明設(shè)計是正確的，而通過評審，對于PM和Architect，似乎也被當(dāng)做是一個項目當(dāng)中非常重大的milestone，直到現(xiàn)在，我的上級和我的同事，似乎從未改變。而我的自己觀點的表白在OP會上，迎來的是批判。
?????? 我認(rèn)為文檔必須要有，總體的架構(gòu)設(shè)計和模塊的詳細(xì)設(shè)計，都是需要的，但是設(shè)計者，往往忘記了，文檔只是設(shè)計者自己對已經(jīng)構(gòu)思好的設(shè)計的一種反映，這種反映只是讓別人去分析、理解、修正、接受并按照它來進行開發(fā)的一個工具，它絕對不是一個證明自己完成一個良好設(shè)計的方法。
??????? 編碼、測試、調(diào)試、交付用戶UAT，都應(yīng)當(dāng)視為是設(shè)計的過程，也應(yīng)當(dāng)是驗證設(shè)計是否正確的最好的辦法。
??????? 盡早的進入代碼開發(fā)，是敏捷開發(fā)中一個很重要的標(biāo)志，所謂的標(biāo)志，我認(rèn)為如果在項目前期的前一兩個月，你仍然徘徊在需求分析、文檔編寫的工作當(dāng)中，而沒有代碼產(chǎn)生，你絕對不是敏捷。這個觀點是我自己加的，我很難容忍，我的設(shè)計、分析人員天天在寫文檔，開發(fā)人員在心猿意馬的看長遍大論的需求和設(shè)計文檔。
????????? 一句話，越早進入開發(fā)，我就越主動。
?? 我驗證設(shè)計的一些方法：
?? 1.根據(jù)以往的設(shè)計經(jīng)驗，做一些check list.
?? 2.寫代碼，做demo。做Demo是我非常喜歡的一個方法，一個可以運行的Demo，遠勝過文檔了。開發(fā)人員一看，直接copy、paste就完了。做汽車、計算機等新產(chǎn)品，都會有樣機，對樣機做大量的試驗后，才能上線，大批量的生產(chǎn)，在軟件當(dāng)中，怎么一做完設(shè)計，就大規(guī)模的進行開發(fā)了呢。
?? 3.做測試案例，TDD是一種方法，有長期開發(fā)經(jīng)驗的人很容易吸收的思想，并且愿意在重要的地方使用，來理順和驗證自己思路。
?? 4.對于設(shè)計的涉眾人員，能夠盡早的看到，并充分的溝通，不要把文檔寫完了，才交給他們，那是一種思想上的強暴。很多時候，在領(lǐng)導(dǎo)的安排下，設(shè)計人員與開發(fā)人員，在能力上，并差不了多少。所以設(shè)計人員要虛心，并且要有責(zé)任心。
?? 好的設(shè)計應(yīng)當(dāng)交付什么：
?? 1. 有簡潔注釋的代碼
?? 2. TestCase
?? 3. Demo
?? 4. 模型
?? 5. 文檔
???
?
?