?可實現的是架構，空談是概念 So don't tell me the concepts show me the code! ?“不懂編碼的架構師不是好架構師” 好架構師都是超級代碼控。

代碼是最好的老師

從代碼中學習設計的思想、方法是提升類庫設計能力、印證你所了解的概念與理論這就是架構師看代碼的觀點。

基本準備

一個類庫可能有數千個類上萬個方法，應該如何去看呢？ 在看代碼前我們需要進行一些什么樣的準備呢 ？

• 設計模式?- 最標準的23種設計模式基本上要有一個了解，可能一下子不能理解他們的用法，但一定要記下他們的英文名字和基本的用途，如：Factory, Wrapper (Decorator), Command, ?Builder等?。
• 語言規范?- 熟讀語言本身的官方編碼規范與命名規則，這是共同的標準，也是從官方得到寫代碼的第一指導。
• 要看懂UML中對類的圖形表示方法（類、接口、抽象類、繼承關系、使用關系）

看代碼的方法

這里所提供的方法就先以C#作為語言基礎，因為C#有極為規范的的語法規則。.net 的文檔在類庫方面的文檔是最完整也是最易讀的。以.net framework作為起點會是一個很好的練習入口。在開始前我還推薦一下大家需要有一個反編譯工具我用的是.NET Reflector, 用反編譯工具不是讓你去抄代碼（代碼本身是沒有多大價值的，價值的核心在于設計）而是可以更深入地了解到代碼是怎樣實現的。用反編譯工具看微軟的代碼會看到很多的不同的，你會發現大最設計得非常有意思的內部類 (Internal) 。從中大至可以推斷出微軟的開發方法，“在外部接口完全一至的情況下，讓程序員編寫的自由度最大邊界就是內部類與內部方法” 你可以馬上動手先看看 System.Web.Mvc.dll 的實現 要點：多問為什么，帶著問題看代碼——為什么這樣寫（存在理由）？為什么這樣設計（出發點）？ 由你來寫又將如何實現？

看命名?

以面向對象的語言為例，大多會在名字內帶有具體的用法信息,從名稱推算可能使用的模式及實現 帶有模式印記的類：

• TagBuilder - 以Builder模式實現的Html標記的構建器
• StringBuilder - 以Builder模式實現的字符串構造建器
• XXXXWriter - 以構建器模式實現的各種寫入器
• ConnectionFactory - 數據庫連接對象構造工廠

XXX+模式名 是慣用的對模式類的一種命名規則 找到了模式實現如果你看不懂，那恭喜你這就是學習的機會到了，馬上翻開設計模式與實現類進行對照印證，這個過程可以加速模式在你大腦中的印象與加深理解。（模式是架構師的大殺招，能不能上檔次就看對模式的理解與認識了，一有機會就應該學） 帶有家族印記的類： XXX+Base - 抽象類 基類名+XXX - 某抽象類的子類? 是繼承關系一種常見的命名規則。 注：每一種基礎語言會有自身的命名規則，所以必須對官方提供的命名規則爛熟于胸，既可以學習別人怎么寫代碼也可以規范自己的代碼寫法。 做完這兩個練習基本上你可以在不看 Classes References（類手冊）的情況下一下子了解一大堆類的存在與用法。

看接口

接口在設計中有著極為重要的地位，結構再復雜的系統到了接口級別基本上都會很簡單。而且也是判定這個類庫設計是否成熟的一種標準。接口與接口間的定義就定義整個系統的基本框架。看接口的最基本意義就是深入理解類庫設計者的設計思路與了解類庫最核心的能力。 這里我們以 IRepository 為例來講講怎么去看接口 (如果想深入了解IRepostiory的朋友可以閱讀我之前的文章：“Repository模式與UnitOfWorks模式的運用” ) 我以 IRepository 為例是因為它的共識度很大，而實現起來可以很龐大也可以很小，眾所周知IRepository提供的就是對某個實體的CURD(增加、更新、讀取、刪除)的一個接口。那么當我們看到它的存在時，應該可以推斷出另一個接口：IUnitOfWork 因為它們往往會是孿生兄弟般的存在，再進一步推斷是否會存在IRepositoryFactory 和 IUnitOfWorkBuilder 呢？ 那么就可以帶著這些問題在類庫中找答案。 ??? 通過IRepository我會可能會發現一大堆的Repository類， 如抽象類：EntityRepositoryBase, FiledRepositoryBase ,JSONRepositoryBase 等 具體類：BlogRepository, PostRepository, UserRepository 等 注：作為練習大家可以去下載我在NuGet上發布的一個名為 DotNetAge Document Storage 類庫，里面就有Repository的實現 一但掌握了從接口看結構的方法，就可以快速地在無文檔的情況下理解類庫的核心與設計理念。

參考“最佳實踐”

一般上來說，流行的語言都會提供官方的“最佳實踐”提供下載學習。這是一個必修項目，同一個需求，我們可以采用各種的設計方法來實現，但哪一種最好的？ “最佳實踐”就提供了方法選擇的指導。“最佳實踐”會有大量文檔輔助講解，在此時使用上述兩個方法去學習那將會更大地提高你在設計上的提升。 隨著不斷的積累與大量的代碼閱歷，你可能就會得到這樣一種能力：隨便拿個Dll，在一個短時間內你可以如數家珍般說出整個Dll中的特點與功能。 這，就是“看”的練習方法，與練習后的效果

學

要成為架構師就需要突破語言的障壁，不同的語言有不同的優勢，設計應該是因勢利導，好的架構可用任何語言實現，反過來優秀的架構則應盡可能地發揮語言的特性。應用此方法前首先你至少已掌握或精通一門語言。

學習多種語言的動機

• 開拓視野，從不同語言中學習特有的設計理念
• 尋找與更新自己的 “最佳實踐”
• 規避語言被淘汰的風險

開拓視野

我最近在不少網站上看到這樣的一種論調：“學語言只學一門就好，不需要多只需要精”。咋一看，似乎是對的，而我認為僅限于初學者或不求進取者。這是一種語言同質論，是一種誤導與限制！如果學習語言能“窺一斑而見全豹”那就不需要有那么多的其它語言存在了，對嗎？? 當對某一門語言精通(我指的是精通類庫而不是語法)后，這個時間大概也得幾年，很容易進入到一種“思維定式”，以某種固定語言為基點想問題，或是設計。一旦進入這種狀態也就意味著局限性的出現，程序員或是架構師就被限制在了一個局部的小范圍，而且還是風險極高的范圍內。 IT的發展是飛速的，今天的寵兒明天的乞丐這種劇目屢屢上演著，你愿意被大浪淘沙嗎？吊在一顆樹上真是一條死路，這是技術發展的風險層面。又，你的設計工作對你還有挑戰性嗎？你是否仍然對設計和開發充滿激情？你的設計是否在當下可以有什么讓你自豪的特色或創建呢？ 被同質化后這些答案都會被否定掉。? 我的論點是：不斷學習各種語言，體驗各種語言所帶來的開發與設計的激情，開拓自我的視野才是一個架構師應走的路。架構師不單單是技術的選擇者，而更應該是技術的整合者。

選擇“最佳實踐”

我們長期會在某一領域內工作，自然而然會誕生出對此領域內的軟件的設計理念與實現方法。但這僅是一種，舉一個最簡單的例子，同一個網站我們可以用ASP.NET MVC , Java, PHP 或是NodeJS來實現，固然實現方法與代碼量就截然不同了。隨便寫個博客網站就能體驗他們的區別所在：

• ASP.NET 和 Java的思維方式與代碼量差異不大，學習曲線最長、 Hosting 資源成本中等，但數據庫Hosting成本高
• Php 相對前兩者簡單而且資源眾多，Hosting 資源最多，成本最低
• NodeJS性能最高、學習曲線最短、代碼量最少、資源也最多但Hosting 成本最高

從這個比較中可見，作為架構師不單要考慮設計方法與實現，還得考慮部署環境。如果只是某一方面的“能手”那只能干瞪眼，無可選擇。 我不是要選擇“最好”的而是要選擇“最合適”的，因時制宜，因地制宜才是我們所需要的“最佳實踐”

成為 “O” 型架構師

開發是一個團隊共同完成的，與真實社會一樣，活在哪里就說哪里的話才會深入了解對方的文化。 架構師不是一個獨立的個體，而是團隊中不可或缺的成員，在行政與地位上與其它成員是對等的。開發隊團就像是一個人，流著共同的血液。一個架構師，一份設計就應該是一種“O”型血，無論在哪個隊團內都能融合，使用哪種語言都能實現與優化這才是一個好架構師的目標。

學習多種語言的方法

學習語言的方法大家都會有各自的路徑與方法，在這里我只是介紹一下我自己的學習方法僅供大家參考與給我建議。我從業也10多年了，經歷了不少語言以下這些是一些記憶與狀態：

• Delphi (1-5) (Object pascal) - 這是初戀 , 擁有最多的界面組件和最簡單的可視化開發環境，VCL算是當時最好的選擇。
• VB (2-6) - 最容易調用COM的語言也是做面向對象很苦B的一個了。
• C++ - 學得最差的
• java - 用來學面向對象的
• C# - 算是我最擅長的，也是做項目最多的
• Php - 只能算是懂一點
• javascript - 我最喜歡的動態弱類型語言。
• css/less - 最讓我頭疼 (有了Less會好一點)?
• html/xml/xslt - 最容易建立方法論的標記性語言是最容易建立發散性思維與抽象思維的工具
• Objective-C 和 Swift - 現在在學的

每一種語言就像自己的女朋友一般天天在身邊陪伴著我們，所以想學得快首先是愛上她。即使她不再受寵也她會給我們留下很多美好的記憶。

感性認知

我學語言的第一步是不看語法的，因為面向對象的語言語法上基本是相似的，而且語法參考會很長讀起來慢（這跟找老婆不要光看外貌是一個理）。我是從類庫入手的，從主打的類庫中可基本上快速了解整個語言的重要特色和常用的內容。就如iOS吧，一入手我會先看Cococa Layer中的UIKit，花兩小時看完就知道XCode怎么用了然后就可以做個簡單的移動應用跑一下，從感性上互相認識一下。

相互印證

沒有哪個語言是沒有參照物憑空發明出來的，就像學java時如果學過c++會很快因為java就是在極大層面上改進C++而來的，學C#的時候學過java就一下能上手，因為C#是微軟沒買到java自己搞出來的同時也去改進了java。所以語言之間會有互通性存在，在學習的路徑上可以先了前他們的前輩是誰，有什么特色通過雙向的印證了解可以很快速地去掌握與深入理解一門語言。

長年的積累

掌握一門語法很快，精通一門語言就是硬功了。這和我們學自然語言一樣，詞匯量是日積月累的成果。開發語言的詞匯量就在于類庫了，每一門語言的標準類庫也是夠我們喝一壺的，需要實踐、學習與理解結合經驗沉淀成我們的成果。在這方面我給出的建議就是要培養自己的耐心與毅力，羅馬不是一天建成的，高手也不是一天就能修煉出來的。除了掌握官方類庫還得將業界流行的類庫和框架都能了解與熟悉這才算是“精通”。

寫 - 瘋狂的編碼

“實踐是檢驗真理的唯一標準” 能說不如能寫。學到的知識是別人看不到的內容，作為程序員或是架構師將腦中的精華程序化呈現，然后成為產品這才是我們的終極目標。 學會一門語言并不代表寫得好，作為一名架構師寫的代碼要求更是不同：

• 易讀 - 命名是否符合代碼規范，所有接口是否全部代碼都有注釋
• 易用 - 每一個類，每一個方法都是架構師與程序員的UI，少參數，容易理解的設計可以大大減少溝通成本。
• 框架化 - 一個一個類寫是很慢的事，要活用模式于代碼中能同時構建出10幾個或幾十個類。
• 參考性 - 架構師不是程序員，寫代碼為的是固定核心功能與公共用法，便于成員開發。面對復雜的場景需要多寫示例同時也是測試設計的易用性的方法。

怎么才能達到這樣的標準呢？

• 為自己立項從現在起為自己而編碼
• 多寫代碼片 - 對局部的理論進行實踐，多寫一些小的代碼片段或實驗程序，而按正式項目一樣來對待。完整的記錄，共享源碼獲得Feedback，有良好的注釋。
• 模仿是學習與理解新事物的最佳捷徑 — 可以去仿造某些項目，當深入其中可以更直接地理解設計者的最初設計想法，同時也可以得到一個仿造品（不是抄，仿造的目的是獲得編碼經驗）
• 嘗試使用模式并控制類的規模

最后也就是時間的積累，瘋狂地編碼。同樣的時間一個架構師的編碼能力至少需要同等于五個以上程序員同時編碼。

小結

架構師之路是一條很漫長而且需要不斷學習、思考與實踐積累的道路。我只是走了這條路的一小段，以此總結與更多的朋友分享共勉。在下一篇文章中我將會從另一個角度來談架構師的修改項目：表達力。希望有興趣的朋友能給予更多的關注與反饋。

?

?

轉載于:https://www.cnblogs.com/Ray-liang/p/3818385.html

總結

以上是生活随笔為你收集整理的架构师修练 I - 超级代码控的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。