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

?

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

?

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

?

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

?

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

?

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

?

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

原文地址： 針對12306.cn網站應用架夠的一些看法

?

?

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

?

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

?

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

?

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

?

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

轉載于:https://www.cnblogs.com/wala-wo/archive/2012/01/16/5119517.html

總結

以上是生活随笔為你收集整理的针对12306.cn网站应用架够的一些看法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。