2020帶領團隊學習成長，乾貨總結 | 掘金年度徵文

在2020年這個非同尋常的年份裏面，本身與團隊小夥伴一塊兒利用周例會時間，分享學習了《架構整潔之道》系列內容，同團隊一塊兒學習成長。在這個歲末年終的日子裏，恰逢【掘金年度徵文 | 技術人的2020】活動，來對本身本年度帶領團隊學習成長作個總結，分享給你們參考。

本文主要內容思路圍繞如下幾點：

• 經過系列學習分享，咱們get到了什麼？

• 咱們搞這個系列的分享，初衷是什麼？

• 經過系列分享，是否能夠指導咱們技術設計？

Part1：收穫

1.1 《架構整潔之道》系列內容

主要內容總結一下，主要分如下幾部分：

• 編程範式（結構化編程、面向對象編程和函數式編程）

• 設計原則（主要是SOLID）

• 組件處理（依賴、邊界）

• 軟件架構（其中講了不少高屋建瓴的內容）

簡單概況一下即包括 微觀（代碼層面）和宏觀（架構層面）兩個層面的主要開發技能。

1.2 「架構」究竟是什麼？

可能咱們每天會說到「架構」，那它究竟是什麼呢？

軟件架構（software architecture）

有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。 -- 來自維基百科

系統實際上是一羣關聯個體的組成，系統中的個體須要「根據某種規則」協做，架構須要明確這種協做規則。

架構＝骨架、結構，源於建築學。

骨架 揭示架構中內在的支撐物；

結構 則代表架構關心支撐物相互結合的某種構造方式。

架構的價值是什麼呢？

• 最少的人力成本知足構建和維護該系統的需求

• 支撐軟件系統的全生命週期，讓系統便於理解、易於修改、方便維護、輕鬆部署

1.3 「架構」的目的是什麼？

架構設計的主要目的是爲了解決軟件系統複雜度帶來的問題。

當明確了架構的目的以後，會有哪些好處？

主要對於「老鳥」架構師與「新手」架構師區分而言

• 心中有數，而不是一頭霧水

• 有的放矢，而不是貪大求全

現實中咱們還會遇到一些這樣的討論：

• 「咱們的系統必定要作到QPS 10w」

• 「淘寶的架構就是這麼作的，咱們也要這樣」

• 「Docker如今很熱，咱們的架構應該將Docker引入進來」

影響咱們作決策的首要依據應該是系統複雜度，那該如何分析呢？

1.4 複雜度主要分析點

系統複雜度主要分爲如下幾點：

• 高性能

單機複雜度、集羣複雜度

• 高可用

計算高可用、存儲高可用

• 可擴展性

預測變化、應對變化

• 低成本

創新（NoSQL、全文搜索引擎、Hadoop）

Facebook HHVM、新浪微博 SSD Cache、LinkedIn Kafka

• 安全性

功能安全、架構安全

• 規模程度

量變引發質變

功能越多（數據越多），致使系統複雜度指數級上升

1.5 架構設計的原則有哪些？

一樣的代碼，不管是不是同一人寫的，執行結果是肯定的，可是同一個系統，不一樣的架構師，最終均可以解決問題，但設計方案卻可能大不相同。

架構設計的原則主要是解決不肯定性，也是優秀程序員與架構師區分點所在。

如何解決這種「不肯定性」呢？

• 合適原則：合適優於業界領先

將軍難打無兵之仗（人手不足，卻想產出多）

羅馬不是一天建成的（例如各大電商平臺的「雙11」搶購技術能力支持）

冰山下面纔是關鍵（沒有業務場景，卻幻想靈光一現）

• 簡單原則：簡單優於複雜

結構複雜性（組件多，關聯多，故障機率大，定位問題困難）

邏輯複雜性（集全部功能於一身）

《UNIX 編程藝術》KISS：Keep it Simple，Stupid!

• 演化原則：演化優於一步到位

就軟件而言，變化纔是主題

知足當前的業務須要

應用過程當中迭代，保留優秀，修復缺陷的設計，改正錯誤的設計

業務變化時，擴展、重構，甚至重寫

Part2：初衷

2.1 軟件系統的價值

軟件系統價值主要分爲行爲價值和架構價值。

• 業務價值（核心價值）

需求的實現，以及業務可用性保障（功能性 bug 、性能、穩定性）

• 架構價值

需求變動時，軟件變動成本低且可控

事實代表，隨着軟件複雜度的上升，工程師人數隨之增長，可是代碼量到達必定量以後漲幅呈現緩慢。可是代碼維護成本卻呈指數級上升，同時工程師的生產效率也會隨之下降，需求變動維護成本增大。

2.2 對程序員的簡單分類

• 普通程序員

• 工程師

• 架構師

編寫代碼的方式有不少，只要能讓程序跑起來，能正確地處理業務流程和對數據進行計算，就能夠說「會編寫代碼」。程序員須要熟悉整個程序的邏輯及處理過程，須要熟悉程序語言的特性，還須要熟悉一些計算機操做系統的交互調用方式，才能寫出從用戶側交互，到數據和業務邏輯處理，再到與計算機系統交互的代碼，有效地把用戶信息、數據、業務和計算機串聯和拼裝出來。

還須要易讀、易擴展、易維護，甚至能夠直接重用。因而，這些人使用各類各樣的手段和技術不斷提升代碼的易讀性、可擴展性、可維護性和重用性。

2.3 咱們的初衷

談到咱們學習《架構整潔之道》系列課程內容的初衷，其實便是迴歸軟件系統的價值，利用多維的指導分析，幫咱們作出正確的架構決策和架構設計。

Part3：收益

3.1 架構分類

咱們須要針對當前業務需求，選擇合適的應用架構，如何面向將來，保證架構平滑過渡。

主要架構分類：

• 業務架構

戰略層面，業務方向是什麼，要作什麼；

• 應用架構

戰術層面，承上啓下做用；

• 技術架構

裝備層面，負責業務的具體落地實施。

3.2 架構演進

架構的主要演進過程：

• 單體式架構

俗稱「煙囪式」架構

• 分佈式架構

按功能模塊，服務化拆分

• SOA架構

• 微服務架構

其實不管哪一種架構方式，在當時環境下均可以解決問題的，都具備必定的意義的。

總結起來仍是那句話：存在便是合理的。

3.3 請求鏈路

除了系統架構自己，還須要關注每層技術架構的設計點。過程質量關乎總體質量，各環節的架構合理性相當重要。

3.4 編程之鑽

上圖描繪了編程做爲一個完整工做流程（work process）的四項最基本活動

1. 需求分析

2. 設計實現

3. 測試驗證

4. 調試糾錯

咱們開發任何一個軟件功能、實現某個軟件需求，通常都須要經歷這 4 項基本的活動或狀態。把這四個狀態連起來剛好造成一個菱形，因此我把它叫做「編程之鑽」（The Programming Diamond）。

猶如一顆大鑽鑲嵌了四顆小鑽，把它們稱做編程的「鑽石」，也凸顯了這幾個基本任務及其相關技術與方法在軟件開發、軟件工程中的重要性。

Part4：總結

4.1 「悖論」？

一般咱們在解決具體問題時候，最多見的想法就是快速的完成本身的工做任務，這樣一來，是否是建設優質的軟件架構造成了悖論呢？

4.2 觀點

不管是微觀世界的代碼，仍是宏觀層面的架構，不管是編程範式仍是微服務架構，它們都在解決一個問題：分離控制和邏輯。

所謂控制就是對程序流轉的與業務邏輯無關的代碼或系統的控制（如多線程、異步、服務發現、部署、彈性伸縮等），所謂邏輯則是實實在在的業務邏輯，是解決用戶問題的邏輯。控制和邏輯構成了總體的軟件複雜度，有效地分離控制和邏輯會讓你的系統獲得最大的簡化。

其中 簡單vs.簡陋、平衡vs.妥協、迭代vs.半成品 就是咱們須要涉及到軟件架構中平衡的藝術。

4.3 學習建議

最後給你們一些學習上的建議：

• 1w小時學習定律

不斷的踩坑與填坑，會帶給你真正的成長

• 關鍵點

對技術的保持熱情

須要持續不斷的精力投入

堅持學習、實踐、思考、總結

• 指導原則

經驗的沉澱與積累

拓寬視野，不拘泥於現狀

鍛鍊深度思考能力，抓本質問題

以上爲本身帶領團隊學習成長總結內容，借【掘金年度徵文 | 技術人的2020】活動分享給你們參考，其中不妥之處還煩請指正，謝謝！

掘金年度徵文 | 2020 與個人技術之路 徵文活動正在進行中......

Thanks for reading!