臨近年終，公司請來一位講師來給我們作培訓，題目記得是設計匠藝。說實話，我做不到像講師那樣，快講完課時能將自己所講的內容都有條理整理一遍。我就大致講講我所做筆記的一些內容吧。總的來說這位講師的實踐經驗很豐富，講得也很生動。
觀點一：**的可擴充套件性和可維護性是矛盾的。這是講師在上課之初所提的乙個觀點。說實話我是不太同意這個觀點的，一方面加強了**的可維護性確實加大了**的維護難度，比如使用了模式可能加大的系統複雜性，但很多時候加強了**的可擴充套件性同時也方便了**的維護，比如擴充套件性增強了一旦出錯你也更容易找到自己所要維護的**了。這個我相信經常做**重構的同學都有這個體會。
觀點二：優秀**的三個特性：溝通、簡單和靈活。其實這三點都和**的可維護性息息相通的，所以講師的下乙個觀點是**的維護成本遠遠大於開發成本。這個應該是符合實際的，問題是限於國內的it環境，有多少企業重視對技術的積累呢？如果對技術積累重視起來，也就會真正重視**的維護了。有志向的企業都應朝這個方向努力。
觀點三：**就是設計。這是乙個說得都有點濫俗的觀點，但卻引不起我們重視的觀點。以前我總是幻想維護文件總是越多越好。現在發現文件存在很多弊端的：首先是**和文件的脫節問題，比如**更新了，而文件卻沒有及時更新；其次是即使你的文件寫得很好，可是維護人員會看你的文件嗎？而**是無論維護人員喜不喜歡看，都必須去看。現在我想除了一些涉及數學的複雜的演算法需要文件說明之外（而且還必須使用工具和**繫結在一起），應該做到**就是設計，就是文件！
觀點四：物件導向的三個要素是角色、職責和協作。所有的設計模式都是解決職責問題。。首先有職責，才有設計模式。這些觀點非常精彩。我想重讀四人幫的《設計模式》，一定會從這個角度思考問題。
觀點五：設計模式是一種封裝技巧，但封裝並不僅僅是資訊隱藏。
觀點六：設計手法：抽離（抽象隔離），間接和一致。
觀點七：對於大多的軟體專案或移動開發領域，需要做到快速迭代。快速交付乙個可用的產品比什麼都重要。不要祈求需求不發生變化（有乙個笑話：任何需求都發生三次以上，需求發生兩次變化的需求分析人員死在使用者更改需求的路上）。正因為變化必然要到來，就要爭取變化早點到來，而快速的交付就能帶來更多的使用者反饋，從而更好應對變化。
觀點八：持續構建必須和一系列的測試結合起來，比如單元測試、壓力測試等等。
觀點九：uml主要是一種交流工具。講師推崇一種簡單uml加測試驅動開發的開發模式。可測試實際上為軟體開發活動樹立一條紅線。
觀點十：講師認為單元測試非常好。他認為單元測試能及時提供反饋；單元測試讓你的**更加健壯；單元測試是有用的設計工具；單元測試是讓你自信的後台；單元測試是解決問題的探測器；單元測試是可信的文件；單元測試是學習的工具。（搞得現在我對單元測試非常感興趣。）
我的一些疑問：如果提倡快速迭代小版本交付，功能開發的優先順序由誰決定，怎麼決定？軟體的設計比如介面設計是否都由開發人員完成？
公司內部培訓的一些收穫
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！臨近年終，公司請來一位講師來給我們作培訓，題目記得是設計匠藝。說實話，我做不到像講師那樣，快講完課時能將自己所講的內容都有條理整理一遍。我就大致講講我所做筆記的一些內容吧。總的來說這位講師的實踐經驗很豐富，講得也很生動。觀點一 的可擴充套件性和可維...
公司內部SEO培訓指南
隨著seo日益正規化，在企業中推行seo變得越來越重要，在上一文 將seo整合入整個 專案 中也有提到seo程式設計客棧培訓對於整個seo專案的推動有著重要的作用。因此，乙個精心準備的seo培訓課程，可以讓seo變得不再那麼模糊，使整個團隊更好的了解seo，從而配合seo部門的工作。如果你的培訓課程...
公司內部技術積累的一些思考
很多小問題是大家習慣直接找到對應的負責人解決。對這個具體問題來說，當面溝通確實是最高效的，但沒有形成積累，只有直接參與這個問題的人知道問題的存在和解法。一旦人員調動就沒人知道了，或者時間久了連參與者自己都忘了。當然，問題本身是否需要被記錄，也是需要評判的。有些問題，確實參考意義不大。內部的研發系統上...