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