老曹：面向全棧的技術(shù)管理
研發(fā)管理有著廣義和狹義的定義，總的來說，研發(fā)管理就是在研發(fā)體系基礎之上，借助信息平臺進行的團隊建設、流程設計、績效管理、風險管理、成本管理、項目管理和知識管理等活動。 簡單來講，研發(fā)管理是面向結(jié)果，過程敏捷的一種實踐。作為一名技術(shù)管理者，既需要培養(yǎng)團隊的ABC，又需要管理你的老板，保持團隊的新陳代謝，因為一切都是人的競爭。
全棧，不是全能，和所選擇的技術(shù)棧甚至業(yè)務棧相關(guān)。例如以LNMP(Linux + Nignx + MySQL+ PHP)，那么掌握了這四種技能，算不算一個全棧工程師呢?個人覺得可以的。全棧工程師就是技能涵蓋了系統(tǒng)中所采用的技術(shù)棧。但是隨著技術(shù)棧的變化，例如引入了緩存Memcache乃至其他分布式緩存，那原來的全棧工程師還是全棧么?全棧是否要隨之變化呢?這是一種動態(tài)性演進，從而衍生出了所謂全棧架構(gòu)師的概念。
面向全棧的技術(shù)管理試圖從采用系統(tǒng)思維的方式來探討研發(fā)管理尤其是技術(shù)管理的可行性和方法。從系統(tǒng)的角度看，包括時間，空間 和人三個維度。對于研發(fā)而言，人是核心競爭力，可以把技術(shù)棧劃分為面向空間的技術(shù)和面向時間的技術(shù)，然而時空又是密不可分的。
這是個人設想的全棧技術(shù)棧，面向空間的技術(shù)就象庖丁解牛，是對問題本身的分解和實現(xiàn);面向時間的技術(shù)，主要是效率，開發(fā)的效率，程序運行的效率等等。
面向全棧的技術(shù)管理主要是通過系統(tǒng)性的思維方式解決技術(shù)研發(fā)管理的問題。這是典型的九宮格矩陣，從時間和空間的維度提出了系統(tǒng)思考的維度?？梢钥s放系統(tǒng)的概念范圍，例如到模塊的層面，會發(fā)現(xiàn)很多有意思的結(jié)論。
全棧的動態(tài)根源主要有兩方面的原因，商務驅(qū)動和技術(shù)驅(qū)動都會導致架構(gòu)設計的優(yōu)化。商業(yè)需求是個大話題，超出了很多技術(shù)人的領(lǐng)域，這里主要看研發(fā)中技術(shù)管理的全棧思維方式。用一句高大上的詞，就是技術(shù)前瞻性。 如何考量技術(shù)的前瞻性，可以借鑒TRIZ的方法。
TRIZ 是工程領(lǐng)域的神人阿奇舒勒提出的，關(guān)于TRIZ的相關(guān)知識推薦創(chuàng)新算法一書。
TRIZ 中直接可以借鑒的就是技術(shù)系統(tǒng)的9個演進方向，可以指引我們對系統(tǒng)架構(gòu)的演進思考。
技術(shù)的完備性是思考的第一因素，我們的系統(tǒng)是完備的么?如何定位我們系統(tǒng)架構(gòu)的完備性?沒有監(jiān)控的系統(tǒng)是完備的么?Bob 大叔的Clean Architecture 給出一種完備系統(tǒng)的參考。
有始就有終，每個系統(tǒng)或者每種技術(shù)都有者自己的生存周期，或者自己成長的S曲線。技術(shù)選型的時候需要對所選技術(shù)所處的階段予以考慮。
系統(tǒng)自身的動態(tài)性包括三個方面，第一就是移動性，從互聯(lián)網(wǎng)到移動互聯(lián)網(wǎng)，從web到手機APP， 不是一種偶然，而是技術(shù)系統(tǒng)發(fā)展的必然。柔和性說明系統(tǒng)的可塑性強，簡單地說，可重用性是柔和性的一種具體體現(xiàn)?？煽匦钥煞裼成涞脚渲没蛘邊?shù)化么?
系統(tǒng)的傳遞性強調(diào)了通信的重要性，上圖給出了大神AliStair 的六邊形架構(gòu)，指出了對外接口的作用，被當作了微服務架構(gòu)的理論基礎。引申一下，為什么會有“Social for Anything” 呢?
子系統(tǒng)的不均衡正是差異性的具體表現(xiàn)，每個子系統(tǒng)都有著自己的進化曲線， 這是我們關(guān)注系統(tǒng)瓶頸的一種思路。
回顧上面的九宮格系統(tǒng)思維，最高層就是超系統(tǒng)。主機托管IDC資源逐漸演變?yōu)镮AAS，負載均衡、集群服務等進化為PAAS， 應用軟件進化為SAAS，后臺的服務進化為BAAS，連數(shù)據(jù)報表類的服務都在往DAAS上演進，所謂的平臺化或者構(gòu)建生態(tài)系統(tǒng)都是在向超系統(tǒng)的演化。
九宮格系統(tǒng)的最底層是子系統(tǒng)，子系統(tǒng)在向微觀場的方向演進，正像“社會化大分工不斷細化”那樣，職責的原子化，顆粒度的細化等。舉個例子，使用高效資源中的SSD 硬盤， 鑒于SSD的高效，衍生了RocksDB等匹配的存儲引擎。更普遍的是，就是現(xiàn)在如日中天的微服務。
協(xié)調(diào)性直接影響的是系統(tǒng)的效率。流程，工具，子系統(tǒng)，最重要的是人與系統(tǒng)直接的匹配，也是大家熟知的康威定律。
系統(tǒng)架構(gòu)設計的時候，我們往往強調(diào)以終為始。所謂終，延展一下就是心目中的理想系統(tǒng)。系統(tǒng)的組成是復雜的，架構(gòu)的約束存在著自身的矛盾，提高理想度中有用對無用的比值是提高核心約束的過程，將部分功能轉(zhuǎn)移是一種借力打力。
如何匹配系統(tǒng)演進的方式呢，這可能是就是全棧小團隊的用武之地。全棧團隊也有著狹義廣義的說法，但基本都是業(yè)務線分割，高度自治，覆蓋技術(shù)棧支持DevOps的小團隊，自身就是一個完備的系統(tǒng)。
全棧團隊的管理包括《老曹眼中的敏捷開發(fā)》中的ABC，如何促進團隊的動態(tài)流動，通過敏捷過程完成連續(xù)性交付，同時提高DevOps及工具支撐。
敏捷過程往往會帶來一些副作用，例如技術(shù)債務。技術(shù)債至少可以分為6類，甚至可以更細。我們能算一算每項技術(shù)債的利息么?
馬丁大叔的《重構(gòu)》是一種經(jīng)典，但代碼層面的重構(gòu)并不適合架構(gòu)或者系統(tǒng)層面的重構(gòu)，因為重構(gòu)的前提條件在系統(tǒng)層面往往是不成立的。因此，refactor 會演變成refine。
全棧團隊的分享是提高系統(tǒng)流動性的有效方法?？梢杂袌F隊內(nèi)部的周期性分享，專業(yè)的技術(shù)技能培訓，內(nèi)部社區(qū)的建立，投身外部社區(qū)等等，讓團隊做自己的主人。
以上，是分享的全部內(nèi)容。研發(fā)管理或者技術(shù)管理的分享一般都會充滿爭議，管理本身就是面向結(jié)果的實踐。因為時空的變化，人員的不同，很多的成功和最佳實踐往往無法復制，我們企圖探索一些可以實踐的不變的東西，但只是，在路上。
【本文來自51CTO專欄作者“老曹”的原創(chuàng)文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
