架構師修練 I - 超級代碼控

 可實現的是架構，空談是概念 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，有良好的註釋。
• 模仿是學習與理解新事物的最佳捷徑 — 能夠去仿造某些項目，當深刻其中能夠更直接地理解設計者的最初設計想法，同時也能夠獲得一個仿造品（不是抄，仿造的目的是得到編碼經驗）
• 嘗試使用模式並控制類的規模

 

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

小結

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