臨近年終，公司請來一位講師來給我們作培訓，題目記得是設計匠藝。說實話，我做不到像講師那樣，快講完課時能將自己所講的內容都有條理整理一遍。我就大致講講我所做筆記的一些內容吧?？偟膩碚f這位講師的實踐經(jīng)驗很豐富，講得也很生動。

觀 點一：代碼的可擴展性和可維護性是矛盾的。這是講師在上課之初所提的一個觀點。說實話我是不太同意這個觀點的，一方面加強了代碼的可維護性確實加大了代碼 的維護難度，比如使用了模式可能加大的系統(tǒng)復雜性，但很多時候加強了代碼的可維護性同時也方便了代碼的維護，比如擴展性增強了一旦出錯你也更容易找到自己 所要維護的代碼了。這個我相信經(jīng)常做代碼重構的同學都有這個體會。

觀 點二：優(yōu)秀代碼的三個特性：溝通、簡單和靈活。其實這三點都和代碼的可維護性息息相通的，所以講師的下一個觀點是代碼的維護成本遠遠大于開發(fā)成本。這個應 該是符合實際的，問題是限于國內的IT環(huán)境，有多少企業(yè)重視對技術的積累呢？如果對技術積累重視起來，也就會真正重視代碼的維護了。有志向的企業(yè)都應朝這 個方向努力。

觀 點三：代碼就是設計。這是一個說得都有點濫俗的觀點，但卻引不起我們重視的觀點。以前我總是幻想維護文檔總是越多越好?，F(xiàn)在發(fā)現(xiàn)文檔存在很多弊端的：首先 是代碼和文檔的脫節(jié)問題，比如代碼更新了，而文檔卻沒有及時更新；其次是即使你的文檔寫得很好，可是維護人員會看你的文檔嗎？而代碼是無論維護人員喜不喜 歡看，都必須去看。現(xiàn)在我想除了一些涉及數(shù)學的復雜的算法需要文檔說明之外（而且還必須使用工具和代碼綁定在一起），應該做到代碼就是設計，就是文檔！

觀點四：面向對象的三個要素是角色、職責和協(xié)作。所有的設計模式都是解決職責問題。。首先有職責，才有設計模式。這些觀點非常精彩。我想重讀四人幫的《設計模式》，一定會從這個角度思考問題。

觀點五：設計模式是一種封裝技巧，但封裝并不僅僅是信息隱藏。

觀點六：設計手法：抽離（抽象隔離），間接和一致。

觀 點七：對于大多的軟件項目或移動開發(fā)領域，需要做到快速迭代?？焖俳桓兑粋€可用的產品比什么都重要。不要祈求需求不發(fā)生變化（有一個笑話：任何需求都發(fā)生 三次以上，需求發(fā)生兩次變化的需求分析人員死在用戶更改需求的路上）。正因為變化必然要到來，就要爭取變化早點到來，而快速的交付就能帶來更多的用戶反 饋，從而更好應對變化。

觀點八：持續(xù)構建必須和一系列的測試結合起來，比如單元測試、壓力測試等等。

觀點九：UML主要是一種交流工具。講師推崇一種簡單UML加測試驅動開發(fā)的開發(fā)模式?？蓽y試實際上為軟件開發(fā)活動樹立一條紅線。

觀點十：講師認為單元測試非常好。他認為單元測試能及時提供反饋；單元測試讓你的代碼更加健壯；單元測試是有用的設計工具；單元測試是讓你自信的后臺；單元測試是解決問題的探測器；單元測試是可信的文檔；單元測試是學習的工具。（搞得現(xiàn)在我對單元測試非常感興趣。）

       我的一些疑問：如果提倡快速迭代小版本交付，功能開發(fā)的優(yōu)先級由誰決定，怎么決定？軟件的設計比如界面設計是否都由開發(fā)人員完成？