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

?

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

?

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

?

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

?

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

?

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

?

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

原文地址： 針對12306.cn網(wǎng)站應(yīng)用架夠的一些看法

?

?

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

?

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

?

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

?

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

?

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

轉(zhuǎn)載于:https://www.cnblogs.com/wala-wo/archive/2012/01/16/5119517.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。