IT架構師介紹-軟件架構設計學習第一天（非原創）

時間 2019-11-13

原文原文鏈接

文章大綱

1、架構師定義
2、架構師分類與具有能力
3、研發人員發展的技術路線
4、架構師知識體系
5、參考文章php

1、架構師定義

什麼是架構師，這個聊架構話題時永恆的問題。每一個公司對架構師的定位也有所不一樣，由於不一樣公司所處的階段，業務模式，應用場景也都不同。對架構的要求也不同。
在初創公司的野蠻生長階段：業務場景和需求邊界很難把握，有時候根本不須要架構師，產品須要快速迭代和變現，需求頻繁更新，這個時候須要的是快速實現。固然若是公司成長之後，這個階段就是欠下不少技術債，埋下不少坑，若是人員流動很頻繁，後期系統維護成本是很是巨大的。
在公司成長穩定階段：業務模式和應用場景邊界都已經比較清晰，這個時候最須要架構師須要架構師能對線上業務進行模塊劃分，系統拆分重構，並作好相關高可用的措施，以保證系統的穩定，安全、高效地運行。
不一樣的行業，對架構師的要求也不一樣，好比電商業務和AI領域，從架構到業務場景，徹底是兩個物種。
在百度百科裏面這麼定義：系統架構師是一個既須要掌控總體又須要洞悉局部瓶頸並依據具體的業務場景給出解決方案的團隊領導任務。具體來講是一個確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節、掃清主要難點的技術人員。主要着眼於系統的「技術實現」。所以架構師應該是特定的開發平臺、語言、工具的大師，對常見應用場景能立刻給出最恰當的解決方案，同時要對所屬的開發團隊有足夠的瞭解，可以評估本身的團隊實現特定的功能需求須要的代價。系統架構師負責設計系統總體架構，從需求到設計的每一個細節都要考慮到，把握整個項目，使設計的項目儘可能效率高，開發容易，維護方便，升級簡單等。
架構師實際上就是軟件的整體設計師。打個通俗的比方好比某個工程總設計師，相似三峽工程的總設計師。
架構師的造成必定是在實踐中積累起來的，而並不是上了幾回培訓班，讀了幾本書就能夠成功的，架構師是在工程實踐中培養出來的!html

2、架構師分類與具有能力

1. 架構師分類

其實架構師就是個title，每一個公司稱呼均可能不同，和架構概念同樣
1.1 軟件架構師
軟件架構師是軟件行業中一種新興職業，工做職責是在一個軟件項目開發過程當中，將客戶的需求轉換爲規範的開發計劃及文本，並制定這個項目的整體架構，指導整個開發團隊完成這個計劃。主導系統全局分析設計和實施、負責軟件構架和關鍵技術決策的人員，好比這些架構師的title多是JAVA架構師、Python架構師、LAPM架構師等等。前端

1.2 解決方案架構師
與客戶探討業務需求，將業務、市場，與技術、產品結合起來，爲客戶提供解決他們需求的方案。好比阿里雲針對大客戶都有解決方案架構師。java

1.3 系統架構師
也稱應用架構師。最終確認和評估系統需求，並將業務轉換爲技術，爲研發人員制訂核心框架與技術規範爲研發工做澄清技術細節並掃清技術障礙。服務器負載，可靠性，伸縮，擴展，數據庫切分，緩存應用
平臺架構師:這裏的平臺其實包括兩個平臺，一個是系統平臺，也就是負責搭建多個系統整合的系統應用平臺；另一個實際上是基礎平臺，是專門負責搭建基礎技術平臺；二者其實區別蠻大，也常常容易被從業人員混亂。舉個簡單例子，金蝶有平臺架構師一職，可是金蝶BOSS應用和金蝶中間件二者招聘的對象和技術要求是大相徑庭的。git

1.4 業務架構師
業務架構其實已經開始脫離技術層面了，可是它要求架構師有跨越多系統的大局觀，去整合和組織不一樣系統的技術平臺與交互模式。其實這個職位的將來也就是CIO了。主要內容：理解業務，梳理模型，設計模式，接口，數據交互。程序員

1.5 網絡架構師
過去，咱們可能聽的最多的是網絡工程師。不錯，一個優秀的網絡架構師必須有足夠的網絡技術基底，而且它的關注點也是系統的基礎架構。好比說若是搭建並優化集羣環境，若是構建基於雲計算的系統應用與部署等等。它對於像淘寶、騰訊這樣的互聯網公司是極其重要的。web

1.6 移動架構師
移動互聯網的迅猛發展橫向和縱向都細分出了不少新的職責和崗位，移動架構師的職責和做用日益重要，既要總體和全局考慮整個先後端的軟件系統架構，又要重點深刻移動客戶端的架構設計的方方面面，既要有跨平臺思惟，又要拿捏好原生和混合開發的尺度，另外移動應用的特色，致使移動架構師必需要比傳統系統架構師更加註重非功能性的質量屬性。面試

1.7 前端架構師
這也是移動互聯網的迅猛發展而細分出來的新的職責和崗位，這裏的前端特指網站開發中的前端，主要考慮前端呈現層的設計（HTML/CSS/JS/AJAX/RIA/…），跨瀏覽器設計等等。算法

1.8 大數據架構師
好比某些公司作大數據處理，須要理解業務，並經過大數據相關技術來實現。sql

2. 架構師須要具有能力

2.1 技術實力：每一個好架構師都是好的程序員
總結：游泳教練，一定游泳水平好，由於這些都是實踐性很強的工做。書上學來終覺淺，絕知此事要躬行。
這一點毋庸置疑，若是不是寫過N年代碼的優秀程序員，必定不是好的架構師。「架構師」這是一個聽上去比較虛的職位，它的主要價值在於「落地」的過程當中，而不是「指點江山」。eBay的架構師總結架構師在項目中的職責：
解決方案
產品團隊要作一個產品，架構師要幫助團隊把技術可行性，技術方案權衡取捨一一剖析清楚；

架構設計和技術實現步驟
技術方案權衡取捨出來了，架構師要設計總體的技術實現步驟，這個過程必定是和團隊其餘成員一塊兒完成的，常見的實踐是，1到2個核心成員出一個初稿，而後你們討論完善；

編寫核心模塊
技術實現步驟出來了，架構師要和開發團隊一塊兒，進行編碼，可能架構師不必定細究到任何細節，常見的實踐是，系統最困難最核心最關鍵的部分每每由架構師親自操刀；

部署上線和完善流程
系統第一版實現了，架構師要和開發團隊、測試團隊、運維團隊一塊兒，完成各種測試，協助解決最困難的bug，和團隊一同完成線上部署、並一同排除上線初期系統的故障；
在項目的過程當中，架構師至少一半以上的時間是和開發團隊一塊兒進行的，好的架構師不能將實施細節拋之腦後，更直白一些，他要經過撰寫代碼的方式來指導團隊其餘成員理解和實現架構中的細節。
反面的例子是，項目失敗後，架構師反饋「團隊的技術能力不夠」，團隊反饋「這是一個一行代碼也不會寫的大忽悠」。

2.2 業務理解和抽象能力：駕馭概念的技能是最高潛力
總結：抽象能力是善於把實物概念化並歸類。
業務理解
架構師須要理解業務，並轉換爲可被研發理解的實現方案，所以業務理解能力是架構師的必備技能。
一般來講一個資深的業務架構師，對業務有足夠的敏感度和深刻的認知和積累，可以清楚地知道本身的設計能給公司帶來多大的業務影響，應該能大概預判業務將來的發展趨勢，以便在系統的可擴展性上留好必定的空間，因此也會很天然的出現有些業務架構師作着作着就乾脆轉爲PD類型的角色。

抽象能力
是經過對業務的理解轉換爲系統實現的模型，這顯然也是重要的能力，抽象不少時候也承擔了分解清楚多個團隊的職責，分工清晰化。
「邏輯思惟，抽象思惟」比「編碼的時間」對架構師而言更爲重要，若是你不能讓某個非IT人員明白某個概念在說什麼，這個架構師註定也是失敗的邏輯思惟不用展開多說，程序員的代碼都是邏輯，若是XXX就YYY，若是AAA就BBB，缺少良好的邏輯思惟能力基本不可能成爲好的架構師，甚至好的程序員。
抽象思惟又分兩點，一個是將實在的事物概念化，一個是將模糊的感受數量化。一個蘋果，抽象爲質量、大小、顏色、形狀、味道等，這是概念化，是架構師的必備思惟。至於質量、大小、顏色、形狀、味道如何轉變成數字來描述，這也是架構師必備的思惟。
好比面對一個大型的B2C網站，可以迅速抽象爲採購->運營->前臺搜索->下單->履單這幾大塊，對系統分而治之，庖丁解牛，早已目無全牛。
有了上述兩點，架構師能將一個「虛」的架構概念描述清楚。

2.3 設計能力
具備前瞻性的設計眼光，站在技術的山頂向前眺望
鐵打的程序員，流水的技術。程序員的開發生涯可能長達幾十年，但一門技術的平均壽命卻不長。所以做爲程序員們的技術領袖，架構師必須有很好的技術前瞻性，要先於你們瞭解到最新的技術。

架構是過程，並不是結果: 架構是架構師洞察內在結構、原則、規律與邏輯的過程，架構師要作到清晰理解系統，以及簡潔描述，這是分析整合的能力。

一個架構師必須具有極強的分析能力，要作到根據產品宗旨和目標，分析清楚產品定位以及產品業務，再整合利用現有的技術領域，找出最佳方案，實現產品概念。

架構師與技術高手的區別在於，架構師不只侷限於如何調用、如何併發等架構細節（技術高手對這些也很是熟練），還跳出三界，考慮將來問題和潛在風險的應對之道。

一名合格的架構師設計出來的架構是要有前瞻性的，要爲了未來的組織能力更上一個臺階而設計，知足當下需求並可以適當擴展，是遵循架構設計的系統實現要關注的事情，系統是多樣的，架構不是，系統是演化出來，架構不是。

要培養本身的技術前瞻性，首要是學好英語（很少屆時了，但願將來最早進的技術都首先從國內誕生），看懂外文技術文章，能與業界專家溝通交流，學習別人的實踐方案。

反面的例子是，整天將技術前言的名詞掛在嘴邊，大談「雲計算，SaaS」這些東西，每天吹水，而落不了地（有可能他本身也搞不清概念如何落地）。

技術前瞻性還提如今對新技術的選型上，哪些東西適合本身團隊，哪些不適合。學習成本、維護成本、硬件成本、潛在風險等等都是架構師須要考慮的。

架構師在本身所處的領域確定瞭解頗深，將來本領域技術該如何發展，應該有本身的理解。也會對將來技術的發展有所期盼，有本身的看法。固然這屬於比較發散的想法，我的有我的的目標。

2.4 技術深度
能透過問題看本質，解決問題和繞開問題
總結：透過問題看本質則是由虛到實，往深層次地挖掘

看到問題的本質，是架構師必須具有的素質。

例子1：菜鳥程序員的如此寫php：

echo $_GET['username'];

大部分人知道這個出現安全隱患。通常人使用htmlspecialchars解決問題就能夠了。但問題的本質是什麼？能夠從更深的層次去理解：

好比echo是如何執行的？在何時執行的？哪些字符可能致使安全問題？htmlspecialchars爲何能解決這個問題？它真的解決這個問題了麼？

那麼他將會一點一點的進步，逐漸成爲一個合格的程序員。

再好比看到一段java代碼，知道它在JVM如何執行；一個跨網絡調用，知道數據是如何經過各類介質到達目標(操做系統內核/網卡端口/電磁介質等）。透過問題看本質使架構師可以敏銳地發現底層之真實，系統性端到端地思考問題，識別木桶的短板並解決之。

什麼是本質？將世界萬物理解爲原子，將整個互聯網理解成0和1，這倒的確是很是本質了，不過並不能解答任何問題。從問題看本質，實質上是一個從表層逐步深刻的過程。在架構師面對一個用戶需求時，這個「用戶需求」是很是表層的——好比說，一個自動遠程備份數據庫的功能。而架構師的主要工做，就是把這樣的「業務需求」翻譯成「技術需求」。這個過程一方面須要經過抽象思惟將用戶需求提煉爲啓動、讀取、存儲、中斷處理等模塊，而另外一方面則須要看到更深層次的網絡、操做系統、硬件等方面，以及其可靠性、穩定性、適用性、安全性等問題。

架構師要有將「業務需求」轉化爲「技術需求」的能力，這是一個本質的挖掘。例如，業務層面看到的是一個「電子商務網站系統」，架構師看到的是一個多人在線，併發交易，須要保證數據一致性的站點、服務、數據系統，功能、性能、擴展性、維護性、安全性、可用性這些字眼會慣性的蹦到架構師的腦子裏。

架構師之因此是架構師，他在龐大系統的面前，仍然可以敏銳發現其底層之真實，這就須要，他有多年多領域知識和經驗的沉澱。

2.5 技術廣度
要成爲百科全書式的智者
總結：一、全面瞭解各個層面的知識。二、瞭解主流公司的系統設計，碰到實際問題，很快有多種方案可供評估。

首先，做爲一名卓越的程序員，架構師確定不欠缺開發方面的知識。從架構到方法論，從數據處理到安全監控。能夠說IT開發層面上，架構師能夠作到爐火純青的地步。可是這僅僅是一名卓越程序員的能力級別，離架構師那還有很大的一段距離。

架構師做爲一名技術領袖，須要經過散發知識的光芒來溫暖開發團隊，若是隻一個領域內的知識爛熟於胸，那也僅僅是一名技術高手。要想更進一步，須要對APP層面、服務層面、數據層面均要了解（系統分層），要對研發、測試、運維、安全也要有所瞭解（職能），上要對接口，下要對原理（接口與實現）都有所瞭解，甚至，要在多個業務領域都有所涉獵。

有的程序員也會說，若是多學習跨領域、跨學科的東西，會不會成爲何都懂，但什麼都不精的人？其實在這裏的跨領域，並非要求你們都成爲每一個領域的專家。最重要的是有一門敲門磚，學習的引子。若是開發一套金融系統，對於財務結算以及處理方法都不瞭解，那別說是勝任架構師的任務，連普通程序員的工做也不可能作好。假設你們工做一段時間後，對某領域很瞭解，但因爲工做變更的緣故，到其餘公司後，開發的領域徹底不會。這裏就要用到跨領域知識學習的能力了，須要你們樣樣都要知曉。

談到跨領域學習，知識面廣彷佛是最好實現的目標，只要博覽羣書，加上高中以前各學科紮實的基礎，相信大多數程序員自己就具有必定的跨領域學習的能力。但想成爲真正的百科全書式的智者，恐怕不光是簡單以爲眼熟就行。在條件容許的狀況下，程序員其實能夠去參加一些其餘領域的專業考試。好比參加會計資格證的考試，抑或其餘專業中較初級的考試。這樣的經歷，主要仍是在於「以學促考」，經過必定的壓力讓本身能鑽進去學習。

初級架構師所懼怕的，是跳出本身的「獨門絕技」，在必定程度上說，在必定深度以內成爲一個「雜家」也沒什麼很差。

2.6 溝通能力
善於溝通的技術領袖
總結：溝通能力確保各方對架構達成共識，願意採起行動

架構師必須參與項目開發全過程，包括確認需求、系統分解、架構設計、技術選型、制定技術規格說明、系統實現、集成測試和部署各階段，在這一系列過程當中，架構師會與各部門溝通交流。

一個產品會有多部門合做，架構師在其中的溝通極爲重要，直接影響產品進度與質量。架構師不只要與開發人員溝通，也要和項目經理、分析人員甚至用戶溝通，來實現產品的各類可能性。

架構師和項目經理，對溝通能力的要求都很高，不少互聯網公司甚至直接由架構師擔任項目經理的角色。這兩個角色其實仍是有所偏重的，項目經理更傾向於與客戶的交流，跨團隊的協做與交流，架構師主要偏向技術團隊內部的溝通與交流，純技術上的溝通。

如何成爲一名「善於溝通」的架構師呢？在目標清晰的前提下：

首先作到平和，不能將本身所在象牙塔上，頤指氣使的發號施令，這樣的態度必然遭恨，你們都是技術人員，只是分工不一樣，爲什麼要受你的氣呢？

其次，架構師要有必定的繪圖能力。人對圖形的理解遠大於對文字的理解，一個層次圖，一塊小白板，幾隻筆，真的這麼容易把問題描述清楚麼？

作到人性化的溝通，須要咱們在平時就進行培養。寫出大部頭的架構書，有的時候並無用VISIO畫出的簡單架構圖好理解。人對圖形理解遠遠大於對文字的理解，直觀簡單的UML圖能夠極大的方便程序員理解架構師的意圖。

其次，能夠召開小範圍的技術人員會議，你們一塊兒來討論，一塊兒理解架構師真正的意圖。甚至就是一塊小白板，幾支筆就能把問題擺清楚，講明白，統一意見後的團隊必然幹勁十足，再不會出現互相推諉的狀況。

架構師就至關於一支球隊的主教練，如何將本身佈置的戰術交到執行的球員，也就是開發人員的腦殼裏，是關乎勝利的關鍵。那麼怎樣才能成爲一名能說會道的程序員呢？

在通常人的印象裏，程序員都是一羣略顯呆滯，溝通能力不強的技術狂人。邏輯思惟非同常人，但就是倒不出來。有些人經過找女友做爲旁證，連經濟適用男中的定義原型都是IT人士，月薪4000以上，不善言談，最後娶一剩女爲妻。看來我等程序員，真的只能被人如此定義了。雖然說架構師技術層面上的東西與前例不可同日而語，可是也看到溝通能力上，程序員還有很大的發展空間。

2.7 系統性的思考
權衡利弊，只有合適沒有喜歡
總結：系統性地思考：平衡取捨能力確保架構在現有資源約束下是最合理的，理想最終照進現實。

合格的架構師都是好的戰略家，前瞻性眼光是他們起碼的要求，而系統性的思考則是將這些前瞻性眼光落地的必備素質。

架構既看重前瞻，又看重落地，落不了地的架構只是空中樓閣，因此，如何將架構落地，考量的就是一名合格架構師的綜合素質和系統思考的能力。

由於架構的規劃和落地依附於現有的環境因素不少且不可重現，因此，合格的架構師要可以儘量多的將對架構有過多權重影響的因素考量進來，而後作權衡，抓住重點因素，最後集中兵力重點突破。

好比，是採用傳統的Monolith架構體系，仍是時下風靡的微服務架構體系，你要可以從團隊人員層次和能力，組織和公司的發展示狀，時機等重點因素中作出權衡，你無法經過數據建模的手段去完成這個工做，你能依靠的，只有你的綜合素質和系統思考能力：

從時機（Timing）上說，若是單個應用結點就能夠知足業務發展需求，那麼，就沒有必要上微服務，不然反而憑空增長了整個交付鏈路的負擔；

若是團隊的成員能力還不足以支撐起微服務體系相關的全部工具化，服務化和平臺化建設，那麼微服務架構也不是最合適的方向；

若是公司業務還處在四處拼殺，生死未卜的時候，公司的現狀也不會容許你去搞各類完善的基礎性建設，活下來纔是第一位的；

對於架構師來講，你要關注的不是「點」，而應該關注的是儘量多的「點」，進而是鏈接點的線，到面，甚至到體。

3、研發人員發展的技術路線

1. 技術人員職位與等級介紹

2. 技術人員職責

2.1 高級程序員（管理本身）
（1）負責核心複雜功能的實現方案設計、編碼實現
（2）負責疑難BUG分析診斷、攻關解決

2.2 研發經理（管理一個團隊）
（1）團隊任務管理：開發工做量評估、開發任務分配
（2）團隊生產質量提高：代碼審覈、開發風險識別/報告/協調解決
（3）團隊生產力提高：代碼模板研發與推廣、最佳實踐規範總結與推廣、自動化研發生產工具研發與推廣
（4）團隊專業力提高：招聘面試、新人指導、領導覆盤總結改進

2.3 技術總監（管理多個團隊經理）
（1）組建平臺研發部，搭建公共技術平臺，方便上面各條產品線開發。
（2）經過技術平臺、經過高一層的職權，管理和協調各個產品線組。如今每一個產品線都應該有合格的研發Leader和高級程序員了。

2.4 架構師（專一某個平臺的技術架構規劃）
須要分離管理族和專業族。整個研發團隊可能已經超過100來人了，須要有人專一來作架構規劃、設計、平常維護。不能讓研發總監和研發Leader又作管理又作技術一股腦都扔給他們。
（1）架構分析：從功能性需求中識別出須要增長的非功能性需求，好知足性能、可擴展、解耦/集成、安全、可運維、高可用、易部署、易更新。而且識別完非功能型需求，還要作技術選型、技術架構風險識別、技術實現工做量評估
（2）架構設計與實現：非功能性模塊的架構設計、接口設計、代碼實現。因此須要的是有代碼實現能力還要有架構思惟的工程師，不須要畫PPT的工程師
（3）業務架構設計與實現：須要對跨系統的接口進行識別、實現、維護，須要對能寫成公共代碼類庫的進行分析、識別、接口設計、實現、變動維護。
（4）重構：架構師須要常常作Bug分析、非模板性和公共類庫代碼檢查，以發現代碼腐爛程度，以發現還有哪些代碼沒有作很好的架構與精心的代碼設計。因此重構是常常性維護髮生的，不是攢到某一刻動大手術，甚至推翻重作，那就不叫重構了。

2.5 CTO (軟件產品和技術是統一管理的.是商業、產品、技術、管理、團隊相平衡的綜合統管)
（1）業績達成：洞察客戶需求，捕捉商業機會，規劃技術產品，經過技術產品領導業務增加，有清晰的戰略規劃、主攻方向，帶領團隊實現組織目標
（2）前沿與平臺：到這個研發規模規模級別了，必定要有專門的團隊作技術應用創新探索和前沿技術預研。並且要和技術平臺團隊、應用研發團隊造成很好的聯動做用，讓創新原型試點可以很平滑的融入商業平臺再讓應用研發線規模化的使用起來。大量的前沿探索都死在了內部，作完試點就停滯了，這就須要CTO作好總體的銜接推進工做。
（3）研發過程管理：站在全局立場來端到端改進業務流程，爲業務增加提供方便
（4）組織與人才建設：公司文化和價值觀的傳承；研發專業族團隊梯隊建制建設、研發管理族團隊梯隊建制建設；建立創新激發機制，激發研發人創新向前發展，激發黑馬人脫穎而出

3. 專業技術人員掌握知識體系

3.1 優秀程序員
成爲優秀程序員，須要學好的知識：
（1）面向對象編程、UML畫圖、設計模式、代碼重構
（2）經常使用ORM工具
（3）MVC,WCF,XMl, JQuery ，SQL以及性能優化
（4）FrameWork一些深刻的知識
（5）高性能代碼，好比靜態化，MemCached等手段。
（6）最好也瞭解一些其餘語言，好比Java，PHP等。

3.2 DBA
成爲DBA，須要學好的知識：
（1）經常使用數據庫，MSSQL、MySQL、Oracle，性能調優熟練，備份、負載均衡、集羣、容災熟練
（2）大數據量處理熟練
（3）各類數據庫監控軟件

3.3 運維
（1）各類Web負載均衡的硬件，好比F5，軟件，好比Nginx等原理和配置
（2）反向代理加速，好比SquID等
（3）操做系統，Linux是必須懂的，各類好的工具都在Linux下。
（4）各類性能監控軟件。

3.4 項目經理
（1）溝通和理解能力。
（2）該行業和本公司的業務邏輯。
（3）軟件工程的知識。
（4）質量控制、進度控制、人員組織等。

4、架構師知識體系

1. 通用技能表

1.1 作事方法論：目標、方法、執行
我是誰
思惟方式，不將就認真作事的人
如何作事
（1）總體把握，找到方法論（解決方案），
（2）思路：分而治之，優先排列，計劃進行（排期完成）。
（3）及時溝通，反饋，敢於承擔責任
（4）團隊意識

成長
（1）和優秀的人在一塊兒
（2）不斷學習充電

完成定義
（1）瞭解基礎原理，自測經過，及時跟蹤反饋問題，文檔更新
（2）作一個靠譜的人：凡事有交代，件件有着落，事事有迴音。

1.2 思惟結構
《金字塔原理》
《結構化思惟》
《系統思惟》

1.3 文檔能力
熟練使用word、excel、ppt

1.4 協做
相似TAPD的在線協同平臺
微信
例會

1.5 溝通能力

1.6 業務能力
熟悉公司和行業的一些業務邏輯

1.7 計劃推動
質量控制、進度控制、人員組織、資源協調。具體能作到如下幾點
（1）可以有效的組織各種資源，經過說服、協調等方式獲得相關部門或人員的支持，以使計劃順利的推行下去；
（2）說服力、協調力、推進力、監控與反饋

1.8 項目管理能力
（1）架構評審
（2）代碼規範
（3）代碼 Review
（4）看板管理
（5）SCRUM
（6）敏捷開發
（7）極限編程（XP）
（8）結對編程
（9）FMEA管理模式

2. 專業技能表

2.1 基礎知識
（1）計算基礎
（2）計算機原理
（3）數據結構和經常使用算法
（4）操做系統:進程,線程,內存
（5）網絡
（6）TCP/IP協議
（7）TCP/IP網絡模型
（8）HTTP協議原理
（9）網絡IO模型
（10）Socket網絡編程

2.2 編程語言
好比：
（1）java基礎類庫
（2）JVM原理和調優
（3）併發處理
（4）多線程
（5）異常
（6）經常使用框架
（7）經常使用框架
（8）異常處理機制

2.3 程序設計
（1）高質量編碼能力:
（2）重用性
（3）低耦合
（4）可擴展性
（5）可維護性
（6）高性能
（7）安全性高
（8）面向對象編程:
（9）MVC編程思想
（10）掌握建模語言和建模工具：UML
（11）面向對象思想
（12）設計模式:
（13）基礎設計模式和設計原則:單一職責、開放封閉原則等.
（14）經常使用設計模式
（15）重構

2.4 研發能力
（1）熟悉瀑布模型：需求->需求分析->設計->開發->測試->上線->運維/運營
（2）調試和解決問題能力
（3）敏捷思想：快速迭代，任務細分，wiki更新

2.5 安全知識
（1）web安全：xss，sql注入，ddos攻擊
（2）安全維度：漏洞，風險，事件
（3）https協議

2.6 操做系統知識
熟悉常見操做系統和比較其區別，好比Linux、Windows系統

2.7 運維能力
（1）監控
（2）持續集成：jenkins
（3）自動化運維工具：ansible，saltstack
（4）虛擬化：kvm,vm
（5）容器docker
（6）雲技術openstack
（7）DevOps

2.8 數據庫
（1）基礎理論
（2）數據庫設計的三大範式
（3）數據庫原理
（4）數據庫優化
（5）數據庫引擎:

2.9 經常使用應用軟件
Web server
（1）Nginx
（2）OpenResty
（3）Apache Httpd
（4）Tomcat:架構原理,調優方案
（5）Jetty
消息隊列
（1）RabbitMQ
（2）RocketMQ
（3）ActiveMQ
（4）Kafka
（5）Redis 消息推送
（6）ZeroMQ
數據庫中間件
（1）DBproxy
（2）Haproxy
軟件負載均衡
（1）幾種負載均衡算法：輪詢、權重、負載、最少鏈接、QoS
（2）DNS負載均衡
（3）Nginx
（4）LVS+Keepalived實現負載均衡
（5）HAProxy
（6）Haproxy+Keepalived+MySQL實現讀均衡負載

2.10 性能
（1）性能優化方法論
（2）容量評估
（3）CDN 網絡
（4）鏈接池
（5）性能調優

2.11 大數據知識
（1）Hadoop
（2）Storm
（3）Kafka Stream

2.12 工程化管理
（1）maven
（2）git
（3）svn
（4）jenkins

3. 架構基礎知識

3.1 架構演進
（1）初始階段：LAMP,部署在一臺服務器
（2）應用服務器和數據服務器分離
（3）使用緩存改善性能
（4）使用集羣改善併發
（5）數據庫地讀寫分離
（6）使用反向代理和cdn加速
（7）使用分佈式文件和分佈式數據庫
（8）業務拆分
（9）分佈式服務

3.2 架構模式
（1）分層：橫向分層：應用層，服務層，數據層
（2）分割：縱向分割：拆分功能和服務
（3）分佈式
分佈式應用和服務
分佈式靜態資源
分佈式數據和存儲
分佈式計算
（4）集羣：提升併發和可用性
（5）緩存：優化系統性能
（6）cdn
方向代理訪問資源
本地緩存
分佈式緩存
（7）異步：下降系統的耦合性
（8）提供系統的可用性
（9）加快響應速度
（10）冗餘：冷備和熱備，保證系統的可用性
（11）自動化：發佈，測試，部署，監控，報警，失效轉移，故障恢復