1 技術問題描述不清，解決效率低下
同學a在交付現場遇到技術問題，在專案群裡面求助同學b的解決過程。
同學a：大佬，雲架構改了之後，資料庫規劃不了。同學a可能的心理狀態：這個是產品的問題，不是我的問題，我已經把日誌和截圖發群裡面了。你負責的問題你自己爬樓看。同學a：解決方案導不出來。
其他同學cdef：其他問題討論，衝亂了上下文。
同學a：資料庫不能規劃，報風險。
同學b：先把問題描述清楚。
同學b可能的心理狀態：這啥問題啊，還得爬樓看，現在沒空，先不處理。...... n小時後，納尼，剛才是哪個群在@我了，群太多找不到了，沒**，看來不著急，先去吃個飯。
2 方案太抽象，可複製性有限
講師c：咱們這個方案，controller呼叫apiserver進行排程，然後apiserver去資料庫裡面查詢元資料配置資訊後，向業務伺服器傳送請求。巴拉巴拉，我不耽誤大家太多時間，講快點。培訓結束，一片掌聲。
同學d：這個方案我需要拿去和客戶交流的，得把原理弄清楚一點，加一些文字描述方便客戶理解。
一次**交流
講師c可能的心態：已經畫清楚了，還做了培訓，聽完得自己思考消化啊 。
同學d可能的心態：這些框框畫起來容易，沒有相應的說明，在客戶那裡交流效果可能會很差，需要找不同的人交叉驗證下，然後重新完善材料。
講師c的心態需轉變：最好的學習方法就是用通俗的語言教會別人，如果不能讓別人容易理解，那說明自己還沒有掌握透徹。
可行的交流方式：上次分享時間比較有限，沒說得很透徹，用乙個通俗的例子來說，可能更好理解，......此處省略500字。然後結合客戶場景，雙方展開更詳細的討論，各有收穫。
3 核心問題（技術決策點）未突出，技術評審效率低下
同學e去跟客戶介紹了乙個三機房的方案，需要客戶做決策選擇是物理第三機房還是邏輯第三機房，但是客戶聽完後，沒有get到決策點是啥？
一次決策匯報會
上述場景中，有2個問題需要解決：
費曼本人是諾貝爾得獎者，也是著名的教育學家，他的學習方法分為四步：
1 選擇乙個概念
選乙個你想學習的概念。
2 講授這個概念（費曼技巧的靈魂）
設想，你面對這個領域的菜鳥，甚至面對十歲的孩童，試**釋清楚這個概念，並讓對方完全聽懂。
一方面加深你的理解，另一方面，找到不明白的節點或卡點。
3 查漏補缺
當你無法解釋的時候，重新回頭找答案。
回到書上去，回去找同學、找老師、找已經懂的人，把這個概念重新研究一遍。
結果要求，你能夠把這個概念重新流利地解發布來。
4 簡化語言和嘗試模擬
繼續昇華。假若是乙個學術化或抽象化的詞語，嘗試用簡潔詞語來解釋，用別的東西來模擬它。特別注意的是，類別的目的是更好地理解核心觀點，允許和技術原意有小差異。
筆者第一次聽別人介紹微服務中註冊中心的功能介紹和實現原理時，對於rpc、rs、sessionserver、dataserver、metaserver術語，有點懵的感覺。筆者當時有乙個想法，如果我來向客戶介紹微服務的產品時，怎麼讓他們更容易理解呢？於是開始先找官網文件、研發團隊的文件理解後，然後用生活中的小故事小場景來介紹。
1 什麼是rpc？
技術解釋
rpc（remote procedure call）的本質是為了遮蔽網路的細節和複雜性，提供易用的api，讓使用者就像呼叫本地函式一樣實現遠端呼叫，所以rpc最重要的就是「像呼叫本地函式一樣」實現遠端呼叫，完全不讓使用者感知到底層的網路。sofa產品裡面不同容器間，通過rpc呼叫，實現的「高內聚，低耦合」的效果。
通俗介紹
幾個閨蜜在逛街，有人說突然想起快遞沒收，要回去收快遞。另外乙個人說，打個**回去給老公去收快遞就行了。提前和老公說明收快遞的資訊（哪個快遞公司、快遞點在**、快遞裡面是什麼、收件人姓名和**），打**遠端操作老公收快遞這個過程，叫rpc。
2 什麼是註冊中心？
技術解釋
registry 是指具有承載海量服務註冊和訂閱能力的、高可用的服務註冊中心。registry 服務註冊中心分為四個角色：客戶端（client）、會話伺服器（sessionserver）、資料伺服器（dataserver）、元資料伺服器（metaserver），每個角色司職不同能力組合後共同提供對外服務能力。
registry 服務註冊中心的主要元件有：
通俗介紹
註冊中心產品可理解為二手房中介機構，微服務架構中的服務註冊/發現/呼叫，可模擬買家和賣家通過中介完成房產交易的過程。
服務註冊過程（房東賣房子）
服務訂閱過程（買房者購房）
服務呼叫過程（買家詢價）
1 維護乙個自己的術語表，識別出在客戶交流介面的高頻術語
穿過身體的知識才屬於自己，哪怕是看到別人寫得好的材料，抄一遍。
2 為高頻術語都分別準備乙個有生活場景的介紹
平時多觀察生活中人/事/物之間的關係，道法自然。很多設計模式，比如**模式（例子：專利申報**機構）、責任鏈模式（例子：提交購房資格申請，不關心哪個委辦局來處理，最後能獲得購房資格即可）、觀察者模式（例子：某銀行在招標**發布乙個專案招標需求後，各類乙方廠商訂閱到有新專案招標，蜂擁而上）等等都能在生活找到相似的影子。筆者愚鈍，此處無法窮舉所有設計模式。
3 及時做筆記和持續更新
為高頻術語準備故事或場景，不是專門花一段時間可以完善的，有時候是半夜突然冒出來的靈感，有時候是剛好看到乙份資料裡面寫得比較好。
讓Duilib多執行緒程式設計更容易
一 duilib不能開發多執行緒程式？記得很久以前就聽有人說過duilib的多執行緒支援性不好，原因是duilib裡面的控制項是用陣列管理的全域性變數，不能進行多執行緒訪問，加鎖很麻煩。其實這個說法是非常不合理的，以至於在開發多執行緒程式時直接將duilib拒之門外。當然使用duilib裡面開發多執...
共享車位讓城市停車更容易！
現在停車難 停車貴成為了困擾車主出行的大難題，私家車的數量在逐年增長，得益於我國經濟的快速發展，一線城市的停車位缺口更大，停車位緊張，停車難已經成為城市的難題。共享車位的發展是為了緩解城市停車難題，在不增加停車位的基礎上，盤活存量的閒置車位資源，讓停車位充分使用起來，緩解停車位緊張問題，從目前的市場...
如何讓SOA更智慧型
讓soa更智慧型 用語義級的本體描述語言 owl 來描述soa的整個過程，可以提高soa的自動化程度，以實現服務的自動發現 自動匹配與自動組裝。北京地稅個稅soa專案組 soa是近幾年來被頻繁提及的概念，它作為一種架構模型，能夠幫助系統架構者更迅速 更具有重用性地架構整個業務系統。soa的核心是 服...