天下之至柔，馳騁天下之至堅，無有入無間，吾是以知無為之有益。不言之教，無為之益，天下希及之。1. 什麼是架構？做架構設計有什麼用處？
架構是乙個很寬泛的概念，實際上，生活中到處都充斥著架構，公司的組織架構，房屋的結構，機械的結構等等，都是架構，架構不是本身就有的，是為了實現某種目的進行設計而產生的。做架構的目的是為了使我們想實現的目標更加具體，易於實現，便於分工合作，放在軟體行業，就是讓我們的**耦合降低，開發bug數降低，易於維護，部署簡單等等。
架構是否必須要做？答案是不一定。按照我們系統的複雜程度來確定，系統越複雜，我們在架構設計上耗費的時間應當越久一些。架構設計屬於軟體流程的設計階段，在軟體流程相對靠前的位置，發現問題後修改和調整的成本相對較低，而且能夠站在全域性的角度對系統各個方面進行考量，對於保證系統的概念一致性具有重要的作用。架構設計會選擇技術，考量風險點，所以對後續專案的推進也有積極作用。所以，複雜的系統，我們雖然在設計階段想不到所有的問題，但是我們應當發現盡可能多的問題，使用一定的手段和方式給出問題的解決方案和思路，這樣就能緩解後期的專案風險。
2. 架構設計到什麼程度？
設計不一定在一次開發中全部實現，隨著版本迭代，可以分版本實現，但是應當區分核心設計和非核心設計，對核心設計，應該盡早開發，這樣有利於整個專案結構的穩定，而非核心設計，可以看具體情況之後再進行開發。架構設計應該盡可能包含大量的隱喻，限制開發者天馬行空的**，比如某個介面應當返回常量，結合程式語言，就應該使用const限定。介面和類設計要盡可能富有意義，同時權衡好泛化和具體，比如有乙個電插鎖，我們是應該把類名定為電插鎖嗎？可能更好的是定義為門禁，這樣可以包含更多種類的鎖。
所以，架構到底涉及到什麼程度，沒有確定的要求，保持適度就好。
3. 如何評價架構設計的好壞？
能夠讓需求得到滿足，能夠讓開發輕鬆實現並進行自測，能夠讓測試簡單實施測試，能夠讓運維輕鬆部署和維護，架構不過於複雜，這樣的架構就是好的架構。不應該按照架構的複雜程度來評定架構好壞，真正好的架構是以最簡單的設計解決複雜問題的。過度推崇架構複雜性，會導致**的學習和維護成本增加，做架構設計應當時刻權衡架構的複雜性和解決問題帶來的收益之間的價效比。做架構設計最核心的思想就是封裝和迭代，封裝表現為提高**復用性和減小耦合，迭代體現在設計的迭代更新和**的不斷重構。
4. 如何提高架構設計能力？
架構設計是需要實踐鍛鍊的，作為新手程式設計師，不要小瞧自己的每一段**，就是寫乙個函式的工作，有架構思想的和完成任務型的程式設計師，寫出來就會是兩種風格。抓住每一次實踐機會，多練，多想，多總結。逐漸豐富自己的經驗庫和風險庫，能夠很快地從需求中識別出風險點和難點，並能很快地想到相應的手段和方法解決問題。多寫**，多回頭看看自己以前的**，嘗試改進**結構，從中總結經驗。
沒有寫不好**的架構師，但是有做不好架構設計的程式設計師，對於程式設計師，有架構意識和沒有架構意識是兩個完全不同的境界，隨著程式設計師工作年限的增加，逐漸加強自己的架構設計能力，你會發現，自己寫**的能力也會進一步提高，寫出的**質量也會更高，有效**的生產率就會提高。
我的技術管理感悟 技術篇
道衝，而用之有弗盈也。淵兮！似萬物之宗。銼其兌，解其紛，和其光，同其塵。湛兮！似或存。吾不知其誰之子，象帝之先 1.技術的發展，應該注意些什麼？企者不立，跨者不行，自見者不明，自是者不彰，自伐者無功，自矜者不長。其在道也，曰餘食贅行。物或惡之，故有道者不處。關於自己技術的發展，應該要看清自己的能力和...
技術管理 技術管理的患得患失
技術是看得見摸得著可以衡量的，而管理卻是虛無縹緲，伸手去抓什麼也抓不到，學到的是抓的過程中的經驗總結。所以我在做管理的時候經常會因為技術和管理的取捨問題而困擾，技術和管理兼顧一般就是自己累得要死，而兩者都做不好，因為沒有掌握問題的根源 患得患失 在管理技能沒有悟道前，覺得什麼都沒有而自己又在遠離一線...
我理解的技術管理的核心工作 定戰略
很多程式設計師技術做的很好之後晉公升為組長，又做的很好，晉公升為了技術管理者，比如技術總監 技術vp等等。我和這些人接觸之後，發現他們大部分有個共性，就是自認為只是個專門開會，然後根據會議精神給技術人員派活的人。事情很虛，誰來都能做，已經不是做技術的了。由此又引發了危機感，需要做出成績，然後抓著一些...