千文網小編為你整理了多篇相關的《公司培訓心得體會》，但愿對你工作學習有幫助，當然你在千文網還可以找到更多《公司培訓心得體會》。

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

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

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

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

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

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

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

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

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

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

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

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