[[343284]]

今天這篇文章準備整理下我原來談過的和技術(shù)人員相關(guān)的思維方面的話題，整個內(nèi)容實際上包括兩個方面。其一是我們可以從開發(fā)和技術(shù)中借鑒哪些思維方式；其二是技術(shù)人員本身不要受限于技術(shù)中，而應(yīng)該跳出盒子培養(yǎng)價值驅(qū)動下的經(jīng)營思維。

從編程思維談起

編程思維的本質(zhì)究竟是什么？

談編程不可避免的要談到編程語言，而編程語言之所以出現(xiàn)，其最終的目的仍然是 提供一種抽象方法來解決現(xiàn)實中的問題 ，問題本身的復(fù)雜程度往往取決于抽象的種類和質(zhì)量。

從匯編語言的出現(xiàn)解決了最初的抽象，而類似c或fortran語言出現(xiàn)則可以看做是對匯編語言的進一步抽象。這一步抽象的完成其實是很重要的一個進步，即我們在解決問題的時候不再需要關(guān)系復(fù)雜的機器模型或機器碼，而是可以更多的關(guān)注問題和解決方案本身。

在這個階段，從 編程本身來說最核心的還是算法和數(shù)據(jù)結(jié)構(gòu) 。這也是任何程序最重要的兩個基本要素。既把問題域本身涉及到的數(shù)據(jù)映射到合適的數(shù)據(jù)結(jié)構(gòu)，把通過程序解決問題的過程映射為具體的算法邏輯。

那么編程實際的難點在哪？

不是算法本身或數(shù)據(jù)結(jié)構(gòu)本身，而是 當(dāng)你拿到問題域的時候知道如何理解和分解問題，并將其映射到最適合的算法或數(shù)據(jù)結(jié)構(gòu)上 。這個映射其實本身不是程序解決的問題，還是人腦在思維，程序本身僅僅是在實現(xiàn)自動化的過程。

那么程序在算法實現(xiàn)過程中最基本的是什么？

我們看不同的程序片段可以看到的還是if/else，或者for/while，然后才是數(shù)據(jù)或數(shù)據(jù)類型定義。而前者即寫任何一個程序中最重要的控制邏輯。那么編程里難的實際上不是控制語句本身，而是在把問題域分解后知道如何理解判斷邏輯，如何將問題域中重復(fù)的東西抽象為循環(huán)，如何從問題域中抽象出數(shù)據(jù)結(jié)構(gòu)。

一個人編程能力本身的好壞，或者說編程思維能力，重點其實是體現(xiàn)在這種映射能力，也可以稱這種映射能力為數(shù)學(xué)建模能力。

舉個例子來說，如果一個問題你已經(jīng)知道了可以映射到構(gòu)建二叉樹，然后通過遍歷的方式來解決了，那么可以說然后一個掌握了語言語法的人都可以寫出程序來。那么實際編程思維或能力的強弱則在于前面談到的映射和建模。

對現(xiàn)實世界的抽象理解，從抽象歸納到演繹泛化

面向?qū)ο笏枷牒兔嫦驅(qū)ο缶幊陶Z言的出現(xiàn)，可以說也是編程思維本身的第二次重大提升。

即原有的編程語言可以看到我們關(guān)注更多的已經(jīng)是抽象后的解決方案，而面向?qū)ο蟮木幊陶Z言則首先關(guān)注的是通過類，通過繼承，通過接口定義等首先對現(xiàn)實世界進行很好的抽象描述，其次才是如何去解決問題?，F(xiàn)實世界中所有的一切都是對象，而面向?qū)ο笳Z言中的類本身就是對現(xiàn)實世界中對象的很好的抽象。

對于面向?qū)ο蟮暮诵奶卣髡劦谋容^多的是封裝，繼承和多態(tài)。這些可能比較偏技術(shù)詞匯，那么再簡單點來說面向?qū)ο缶幊趟季S其核心則是 找到問題域中的對象，將其抽象為類，識別類應(yīng)該有的屬性和方法特征，同時去理清類和類之間的關(guān)聯(lián)和交互關(guān)系，將問題本身的解決過程映射到類和類之間的方法交互上。

如果從這個意義上來說，好像也不是很復(fù)雜，那么實際面向?qū)ο缶幊痰碾y點實際在為了保持代碼足夠的健壯性，可維護性，可擴展性而做出的各種抽象，包括接口的提取和組合，控制或邏輯類的增加等，這些本質(zhì)已經(jīng)轉(zhuǎn)換到技術(shù)域類本身。

另外編程里面有一個重要的思想即是復(fù)用 ，從最簡單的函數(shù)，到模版庫，類庫，再到更上層的公共組件等，都在體現(xiàn)復(fù)用的思想，而復(fù)用本身的目的則主要是提升開發(fā)效率，提升可維護性和代碼的可讀性等。復(fù)用可以理解為編程過程中的編程思想更加恰當(dāng)。

編程的思想是自動化 ，不要簡單的理解為編程語言能夠幫助你解決建模和映射的難題，編程的自動化更多的還是體現(xiàn)在機器可以自動化的進行大量計算和運算，而這個運算是通過我們的程序進行的。程序中體現(xiàn)的一個重點我更喜歡把它理解為循環(huán)，從抽象中去發(fā)現(xiàn)一種可自動化的循環(huán)，這種循環(huán)的處理正是程序的強項。

任何人都應(yīng)該有這種自動化的編程思維，即懶人思維，重復(fù)的事情一定不要手工重復(fù)完成。

架構(gòu)思維

前面談了編程思維，里面談到了抽象，復(fù)用，自動化等關(guān)鍵內(nèi)容。

接著再談下架構(gòu)思維，對于架構(gòu)思維本身仍然是類似系統(tǒng)思維，結(jié)構(gòu)化思維，編程思維等諸多思維模式的一個合集。由于架構(gòu)的核心作用是在業(yè)務(wù)現(xiàn)實世界和抽象的IT實現(xiàn)之間建立起一道橋梁，因此架構(gòu)思維最核心的就是要理解 業(yè)務(wù)驅(qū)動技術(shù)，技術(shù)為最終的業(yè)務(wù)服務(wù)。要真正通過架構(gòu)設(shè)計來完成業(yè)務(wù)和技術(shù)，需求和實現(xiàn)，軟件和硬件，靜態(tài)和動態(tài)，成本和收益等多方面的平衡。

分解是最基礎(chǔ)的 ，架構(gòu)的重點就是要對復(fù)雜問題進行分而治之，同時保證分解后的各個部分還能夠高內(nèi)聚，松耦合，最終又集成為一個完整的整體。分解核心是定義問題，因此架構(gòu)首先仍然需要理解清楚需求。

集成是配合分解完成的動作 ，最終分解完成的各個組件或子系統(tǒng)，通過合適的接口設(shè)計，最終還能夠集成為一個完整的整體，分解僅僅是加速開發(fā)和降低問題復(fù)雜度，如果分解后的內(nèi)容無法集成在一起，那么分解就沒有任何意義。

分解+集成可以理解為架構(gòu)最核心的思考方式和方法。

動態(tài)+靜態(tài)： 一直是我強調(diào)的重要思維模式，架構(gòu)思考里面一定要注意這兩者的結(jié)合，即涉及到流程，用例等動態(tài)分析內(nèi)容，又涉及到數(shù)據(jù)，類等靜態(tài)建模內(nèi)容，而是兩者要高度協(xié)作起來完成整個架構(gòu)思考。

復(fù)用是另外一個重要的思維 ，也可以理解為SOA參考架構(gòu)的核心思考模式，包括最近談的最多的業(yè)務(wù)能力組件化，組件能力服務(wù)化，平臺+應(yīng)用，共享中心建設(shè)，共性能力下沉等都是談的復(fù)用的概念。即使你架構(gòu)設(shè)計一個小系統(tǒng)，你也需要將各個模塊需要用的共性功能抽取為可復(fù)用的共性組件。

分層相對重要，架構(gòu)在設(shè)計中要考慮分層，而核心仍然是資源+服務(wù)+應(yīng)用的三大層 ，分為這三層仍然是SOA參考架構(gòu)的核心思想。對于平臺+應(yīng)用更多只是上面分層模式的一個變形。分層的目的是通過分層既理清了整個應(yīng)用的構(gòu)建過程，又保證了各層之間的獨立設(shè)計和松耦合。

模式匹配： 可以講是所有思維模式里面的一個重點，而架構(gòu)設(shè)計中的模式匹配就是要將最終的業(yè)務(wù)域問題匹配到對應(yīng)的技術(shù)實現(xiàn)上面。即根據(jù)業(yè)務(wù)需求來挑選最適合的技術(shù)，而不是用主流和最先進的技術(shù)去反推業(yè)務(wù)。

抽象是架構(gòu)思維里面的一個重點 ，這里面包括了兩個層面的內(nèi)容，一個是常說的歸納方法，即各種類似場景的實現(xiàn)見的太多了，自然就歸納了一個規(guī)則或方法出來供以后的設(shè)計用。但是抽象更加重要，即將非類似場景中的共性內(nèi)容也總結(jié)出來，進一步抽象為類似的東西，以更加方便的適應(yīng)變更和各種變化。

結(jié)構(gòu)化思維是架構(gòu)思維必須具備的 ，最常用的兩種結(jié)構(gòu)就是二維的表格和樹模型，通過結(jié)構(gòu)化思維引入了維度和XY概念后，可以幫助我們更好的分析和比對，結(jié)構(gòu)化決策等。對于多維模型，我們也要有意識的將其轉(zhuǎn)換為多個平面二維模型，方便我們進行分析。

迭代思維是架構(gòu)思考中需要考慮的另外一個重要內(nèi)容 ，沒有最優(yōu)的架構(gòu)，只有不斷進化的架構(gòu)，只有最適合的架構(gòu)。因此架構(gòu)本身也在隨著業(yè)務(wù)需求的變化不斷的迭代和演化，而不是追求用最新的技術(shù)一步到位。

最后即我們常說的系統(tǒng)思維 ，系統(tǒng)思維是架構(gòu)思維中最重要的思維模式，一個架構(gòu)師必須要有充分的全局思考的能力，做好前面談到各種平衡，追求整體的最優(yōu)化而不是單個目標的最優(yōu)。

從架構(gòu)思維到大架構(gòu)觀培養(yǎng)

要成為架構(gòu)師，大量的項目和設(shè)計編碼積累是必須的，而且這種編碼積累還不能是簡單重復(fù)，還是必須得有抽象，復(fù)用等各種思維，不斷重構(gòu)的設(shè)計意識。走的路多了，各種業(yè)務(wù)到實現(xiàn)的匹配方式驗證的多了，各種大型項目經(jīng)歷和解決復(fù)雜問題多了，你自然就有了這種能力。

一個架構(gòu)，很多時候并不是說創(chuàng)新或?qū)W習(xí)能力就有多強，而是他們的實踐經(jīng)驗積累的知識庫很強大，見多才能夠識廣，大量的模式匹配庫隨時可以使用，而對于一般人你經(jīng)常發(fā)出的感慨就是我怎么沒有想到那里去？知識經(jīng)驗庫很值錢，但是這個是長期大量的實踐換來的，投入的是大量的時間和金錢成本。

經(jīng)驗庫的積累一定是知識理論到實踐，再到總結(jié)復(fù)盤，再到抽象形成在自己腦海里面的。這個過程本身就是循序漸進，反復(fù)迭代，并沒有什么捷徑可走。

而今天談大架構(gòu)觀，那么首先還是說的架構(gòu)思維，對于架構(gòu)思維即前面談到的 分解，集成，抽象，復(fù)用，組合，系統(tǒng)化等多方面的思維能力 ，這些思維能力都相當(dāng)重要，但是本質(zhì)都是我們看待和理解事物的方式。

大架構(gòu)觀本質(zhì)就是我們?nèi)绾慰创屠斫庖粋€產(chǎn)品，那么最終這個產(chǎn)品的實現(xiàn)就是按照你理解或建模的方式進行開發(fā)和產(chǎn)出。所有產(chǎn)品后期可能出現(xiàn)的問題都可能是我們理解出現(xiàn)了問題。

架構(gòu)首先要解決的是 產(chǎn)品內(nèi)部組件如何高效協(xié)同，產(chǎn)品和外圍系統(tǒng)間如何高效協(xié)同并滿足業(yè)務(wù)和用戶需求的問題 。這就是最基本的功能性需求，架構(gòu)必須要搭建這種業(yè)務(wù)場景和需求和最終產(chǎn)品實現(xiàn)之間的橋梁。這么多年下來，我們還是發(fā)現(xiàn)，很多人對架構(gòu)的理解有很大的偏差。

即我會用多層框架了就是J2EE架構(gòu)師，會用SpringCloud了就是微服務(wù)架構(gòu)師，會Hadoop了就是大數(shù)據(jù)架構(gòu)師，這是對架構(gòu)一個巨大的誤解。能夠基于開源項目或框架來搭建一個基礎(chǔ)開發(fā)平臺確實是一個架構(gòu)師應(yīng)該具備的基本能力，但是這個能力僅僅是架構(gòu)能力很小的一部分，因為技術(shù)框架不是業(yè)務(wù)需求，而實現(xiàn)在技術(shù)框架上的業(yè)務(wù)功能組件才能夠滿足業(yè)務(wù)需求。

在業(yè)務(wù)需求沒有最終實現(xiàn)前，技術(shù)框架本身并沒有得到充分的驗證，也沒有和最終的業(yè)務(wù)需求匹配，這種空框架搭建并沒有很高的技術(shù)含量。

或者說 大部分人將架構(gòu)理解為技術(shù)架構(gòu)，而忽視了業(yè)務(wù)抽象和建模能力 ，但是脫離業(yè)務(wù)的技術(shù)架構(gòu)，連自己都無法驗證最終架構(gòu)原型對現(xiàn)實業(yè)務(wù)的支撐能力，即架構(gòu)師最終設(shè)計的東西無法自己進行實證，這本身就是一個要命的事情。架構(gòu)師變成了紙上談兵，設(shè)計的模型變成了空中樓閣，這顯然不是我們想要的。

一個好的架構(gòu)師，應(yīng)該是給出在當(dāng)前業(yè)務(wù)場景和需求下，最合理的架構(gòu)模型設(shè)計 ，而不是什么理想化的模型，什么網(wǎng)上順手搬來的現(xiàn)成架構(gòu)模型。架構(gòu)師追求的不是理想化，而是當(dāng)下最合理。

我們?nèi)绾畏治龊屠斫猱a(chǎn)品，這里的大架構(gòu)觀的一個重點就是能夠深入細節(jié)又能夠跳出盒子的雙重思維， 既能夠宏觀全局又能夠微觀局部，既能夠分解又能夠集成回去 。既追根究底又不求甚解，置身產(chǎn)品之中又能夠跳出產(chǎn)品做用戶視角的思考。要具備這種架構(gòu)能力，需要的是業(yè)務(wù)建模，業(yè)務(wù)到技術(shù)分解轉(zhuǎn)化能力，隨時都是業(yè)務(wù)和需求導(dǎo)向，技術(shù)為需求服務(wù)。沒有盲目的技術(shù)堆積，只有合理的技術(shù)采用。沒有理想化的模型，只有驗證過的技術(shù)。

一個好的架構(gòu)一定是 同時解決功能性架構(gòu)和非功能性架構(gòu)兩方面的問題 。

而非功能性架構(gòu)包括了可靠性，性能，高可用性，高擴展性等多方面的內(nèi)容。這些都需要架構(gòu)師在搭建模型的時候進行考慮，好的架構(gòu)就是穩(wěn)如泰山，靈活擴展，具備彈性的以不變應(yīng)萬變的能力。好的架構(gòu)就是充分考慮到各種異常邊界，并發(fā)峰值，安全攻擊等場景下，系統(tǒng)仍然能夠平穩(wěn)可靠運行。

不論出現(xiàn)任何的突發(fā)情況，產(chǎn)品都能夠靈活應(yīng)對，這往往就是靠的架構(gòu)師設(shè)計產(chǎn)品時候的架構(gòu)能力。就如建造一座高樓，外部上看上去都一模一樣，但是有的高樓刮大風(fēng)都能夠吹倒，但是有些高樓卻能夠扛住10級地震，這要的就是內(nèi)功積累，否則就是繡花枕頭。

越是復(fù)雜的業(yè)務(wù)，往往構(gòu)建的業(yè)務(wù)系統(tǒng)和架構(gòu)設(shè)計也就越復(fù)雜，但是對于架構(gòu)師而言一定要意識到， 任何架構(gòu)的復(fù)雜性都應(yīng)該作為黑盒，屏蔽在架構(gòu)設(shè)計內(nèi)部 。即架構(gòu)的復(fù)雜性應(yīng)該在架構(gòu)設(shè)計的時候被隱藏掉，通過粗粒度的接口將這種復(fù)雜性屏蔽在內(nèi)部。即對于最終的開發(fā)人員往往并不需要關(guān)心這些復(fù)雜性，而只是按照架構(gòu)原則和開發(fā)指南進行開發(fā)即可。這本身也是架構(gòu)設(shè)計的一個重要考慮點。

大架構(gòu)觀，本質(zhì)就是我們分析和理解事物的思維觀 。

而架構(gòu)本身解決的是從業(yè)務(wù)需求到技術(shù)實現(xiàn)間的關(guān)鍵銜接，而這個銜接的呈現(xiàn)是模型，解決的關(guān)鍵問題是抽象。大架構(gòu)觀，既需要我們通過分解和集成來理解事物的組成和內(nèi)部運作協(xié)同機制，更加重要的是需要我們跳出盒子來看待整個事物或產(chǎn)品的運行。

從開發(fā)和技術(shù)實踐中可以借鑒哪些思維？

在前面我一直在強調(diào)思維中最重要的是模式匹配，今天接著這個話題展開談下從開發(fā)和技術(shù)實踐中類似SOA，面向?qū)ο蟮燃夹g(shù)思想中可以借鑒的思維方式。

從緊耦合到松耦合(解耦的最終目的是靈活組裝和匹配）

在軟件設(shè)計開發(fā)里面，我們經(jīng)常會談到松耦合和解耦，其原因就是今年保證各個模塊充分自治，受外部其它模塊影響最小。而在SOA架構(gòu)里面如果談到松耦合，其核心的原因是松耦合是進行靈活組合和編排的基礎(chǔ)。

思維的最終目的是解決問題，當(dāng)我們面對一個具體的問題解決后，就有了問題和解決方法：

問題A-》解決方法A

那可能在我們頭腦里面就存儲了這么一個關(guān)系，即遇到問題A用解決方法A去解決。

如果我們頭腦里面都是去存儲這種信息，那就是我們說的緊耦合，試想一下問題成千上萬，我們得存儲多少解決方法和知識點？這種窮盡和大量記憶存儲的方法顯然是不現(xiàn)實的。那我們實際要做什么呢？即將解決方法分解為細粒度知識點。

問題A-》解決方法A（知識點A1, 知識點A2,知識點A3）

即任何問題的解決都是已有的知識點的組合和組裝。問題和知識點之間是完全松耦合的，而解決方法只是知識點的靈活組合而已。我們只要有了最基本的知識點，就不怕任何形式的問題。

就類似我前面談售前技術(shù)建議書一樣，客戶的招標要求千差萬別，但是你只要有了（業(yè)務(wù)方案，技術(shù)方案，部署方案，實施方案，運維，人員，案例，報價單模板）等基礎(chǔ)知識點，你就可以應(yīng)對所有的售前方案，你唯一需要做的就是將客戶的招標要求或需求分解為一個個的需求點，同時將這些需求點映射到你已有的知識點上。

通過解耦，我們沒必要去存儲和記憶大量粗粒度的解決方案內(nèi)容，我們只需要關(guān)系問題能否分解到已有的知識點上，只需要培養(yǎng)知識點如何根據(jù)問題進行組裝和編排的能力即可。也正是這個原因，任何一個問題解決后，你都要思考有哪些可復(fù)用的知識點可以入你的知識庫，而不是將該問題的解決方法入庫存儲。

從靜態(tài)到動態(tài)（動態(tài)的目的是知其然并知其所以然）

第二點我們想談的是從靜態(tài)到動態(tài)，因為最近我們在做PPT匯報材料評審的時候發(fā)現(xiàn)一個關(guān)鍵問題，即靜態(tài)內(nèi)容多，而動態(tài)內(nèi)容少，講最終結(jié)果多而講分析過程少。

在講PPT制作的時候我曾經(jīng)談到過，對于PPT的呈現(xiàn)只有兩類，一類是動態(tài)呈現(xiàn)（階段，流程，活動，演進），一類是靜態(tài)呈現(xiàn)（組成，架構(gòu)）等。而這兩類呈現(xiàn)必須相互結(jié)合，相對來說動態(tài)呈現(xiàn)更加重要，只有動態(tài)呈現(xiàn)能夠說明一個事物實際內(nèi)部各個組件之間是如何運作的，而只有了解了內(nèi)部運作你才可能洞悉事物內(nèi)部機理。

從PPT的呈現(xiàn)回到我們思維邏輯上也是同樣的道理。

當(dāng)我們?nèi)チ私馊魏我粋€事物的時候，一定要注意前期我們可能只是了解下事物的結(jié)構(gòu)和組成，但是如果你真想去深入了解事物，那么就必須從這種靜態(tài)的組成轉(zhuǎn)變到對動態(tài)的組成過程的研究。即事物是如何動態(tài)發(fā)展演進到當(dāng)前這個結(jié)構(gòu)的？只有這樣你才能夠洞悉事物內(nèi)部各個組件之間是如何協(xié)調(diào)運作的。

我們平時太注重結(jié)果，而忘記了對這種科學(xué)思考過程的關(guān)注。而實際上再好的結(jié)果本身都不具備可復(fù)制性，而只有科學(xué)的思考過程和方法本身是可以復(fù)制的。你得出一個好的結(jié)果不代表你就很牛逼，中間有很多偶然性；但是當(dāng)你自我論證是通過很好的方法和過程，得出了這么一個結(jié)果，那這種過程本身就具備了舉一反三能力。

原來我寫過一篇文章，談搜索引擎之毒，為啥這樣談？所有千奇百怪的問題，你到互聯(lián)網(wǎng)一搜馬上就搜索到答案并解決掉了，那么這個時候你不會再去深究回答者是如何進行問題分析和思考而得出答案的，即你隨時搜索到了答案，但是你沒學(xué)會是思考和解決問題的方法。

從靜態(tài)答案到去尋找答案是如何分析出來的，本身也是靜態(tài)到動態(tài)的過程。

從泛化到抽象（抽象的目的是最小化記憶，并提供為了演繹的入口）

在互聯(lián)網(wǎng)時代，當(dāng)前人和人比較的一定不是記憶能力，而是問題分析和解決能力。而這個能力里面最重要的一點就是 當(dāng)你拿到問題后，你知道從哪里入手去解決，即問題的入口在哪里。

我原來談到過，互聯(lián)網(wǎng)是一個海量的知識庫，每個人都可以獲取到，你自己的電腦里面可能也有一個你自己歸納整理好的大的經(jīng)驗庫。這么多信息一定是不需要記憶的， 需要記憶的僅僅是能夠通達知識的索引。 通俗點來講就是當(dāng)問題來了的時候，你知識在哪里拿到最能解決問題的資料。

泛化和抽象，實例和類都是偏IT領(lǐng)域的一些詞匯。但是這些詞對于思維領(lǐng)域同樣適用。你平時看到的東西，實踐的東西，學(xué)習(xí)到的知識都很多，你需要做的就是進行歸納和抽象，形成你自己的概念模型，形成自己能夠記憶的最小知識集，這個知識集最后就是索引信息。

有了索引我們就能夠按圖索驥。

索引類似于軟件設(shè)計中最高的抽象層次，即接口的定義。接口中只有方法，沒有具體的實現(xiàn)。而索引就是這個道理，我們只需要知道不同的問題究竟應(yīng)該用什么的方法來解決，這個方法究竟是怎么解決的？我們不需要記憶，我們只需要找到我們存儲或網(wǎng)上存儲的資料即可。

不同場景下不同的問題究竟應(yīng)該用什么樣的方法解決，正是我們在思維里面談到過的，對于一個人最有價值的能力，即模式和方法論。所有的實踐我們都在積累我們自己的模式庫和匹配庫。

比如你原來做開發(fā)工作，轉(zhuǎn)到做軟件需求和業(yè)務(wù)顧問工作，你的模式庫做一次更新。你從做財務(wù)域的顧問，轉(zhuǎn)到做供應(yīng)鏈域的顧問，你的模式庫做二次更新，后續(xù)再轉(zhuǎn)域無任何問題。

一生二，二生三，三生萬物，但是萬物沒法全部窮舉和了解，我們要做的是記憶1這個索引。

橫切思維-聚合本身帶來價值

對于AOP即是指可以通過預(yù)編譯方式和運行期動態(tài)代理實現(xiàn)在不修改源代碼的情況下給程序動態(tài)統(tǒng)一添加功能的一種技術(shù)。AOP實際是GoF設(shè)計模式的延續(xù)，設(shè)計模式孜孜不倦追求的是調(diào)用者和被調(diào)用者之間的解耦,提高代碼的靈活性和可擴展性，AOP可以說也是這種目標的一種實現(xiàn)。

AOP編程的核心意圖是將日志記錄，性能統(tǒng)計，安全控制，事務(wù)處理，異常處理等代碼從業(yè)務(wù)邏輯代碼中劃分出來，通過對這些行為的分離，我們希望可以將它們獨立到非指導(dǎo)業(yè)務(wù)邏輯的方法中，進而改變這些行為的時候不影響業(yè)務(wù)邏輯的代碼。

對于橫切思維，我們還是給一個簡單的定義：

即在分析諸多事物的生命周期發(fā)展過程中，分析端到端流程業(yè)務(wù)的流轉(zhuǎn)過程中，在關(guān)鍵的階段點進行攔截形成有價值的聚合點，通過聚合點來實現(xiàn)各類統(tǒng)一管控和增值服務(wù)。

橫切思維需要徹底打破我們傳統(tǒng)動態(tài)單事物動態(tài)發(fā)展觀察視角，從單事物到事物群，充分去識別共性，將共性進行抽象和聚合，形成有價值的服務(wù)能力。

我們可以來看下橫切思維模式具體有哪些實踐

01-在項目型或強矩陣型組織中的橫向管理協(xié)同

在一個強矩陣管理下，可以看到對于UI，架構(gòu)，測試等各種資源全部歸屬到產(chǎn)品線和項目，這些資源完全是按照產(chǎn)品生命周期進行聯(lián)動也最敏捷響應(yīng)客戶需求。但是也可以看到容易導(dǎo)致的就是各個產(chǎn)品線的UI不統(tǒng)一，架構(gòu)和設(shè)計標準不統(tǒng)一等各類問題。因此需要考慮橫向建立各類跨產(chǎn)品線貫通的工作小組，類似UI工作組，TPG工作組等來實現(xiàn)共性資源的整合和復(fù)用，一個是標準化，一個是避免各類重復(fù)投入。

02-全生態(tài)鏈的運營服務(wù)類平臺構(gòu)建和運營

在互聯(lián)網(wǎng)里面，我們可以看到很多全生態(tài)鏈構(gòu)建和運營的平臺，類似的供應(yīng)鏈端到端服務(wù)平臺，電商類平臺，二手車交易平臺等。而這些服務(wù)平臺里面可以看到在對各方資源進行整合后，其核心不再是簡單的賺取簡單的交易或服務(wù)費用，而是在資源整合后，橫向切分后充分挖掘有價值的能力聚合點。

類似你做供應(yīng)鏈運營服務(wù)平臺，你可以推出統(tǒng)一的大宗交易集采，你做58同城你可以推出你自己的58到家自營服務(wù)。你做二手車交易，你可以推出你自己的信貸或保理平臺等等。即通過資源整合后，充分去發(fā)掘整個生態(tài)鏈里面的關(guān)鍵節(jié)點并進行橫切，來聚合和形成自營的服務(wù)能力。

03-企業(yè)各種類型的服務(wù)共享中心

對于企業(yè)來說，各類共享服務(wù)中心是一直以來的一個熱點，類似人力資源共享中心，財務(wù)共享中心，采購共享中心等，而所有共享中心建立本質(zhì)就是將原來企業(yè)類的涉及到的各類流程中的共性資源抽取出來，充分分析后形成可共享的服務(wù)能力再開放出去提供服務(wù)。

共享可以是簡單的對已有能力的聚合，但是更多是類似云化的思路，即對已有能力進行徹底剝離，在剝離后充分重構(gòu)形成完整的統(tǒng)一能力提供。這才是共享中心最終的價值體現(xiàn)。

思維轉(zhuǎn)變-從技術(shù)驅(qū)動到經(jīng)營和價值驅(qū)動

最后再談下技術(shù)人員思維轉(zhuǎn)變，或者說叫從技術(shù)到管理，從技術(shù)走到項目經(jīng)理或產(chǎn)品經(jīng)理的時候你應(yīng)該有的一些思維轉(zhuǎn)變。對于技術(shù)人員在技術(shù)上專注和精進本身是沒有問題的，但是如果技術(shù)人員沉迷在技術(shù)里面那么很難真正走向管理或成為一個打造好產(chǎn)品的產(chǎn)品經(jīng)理。

培養(yǎng)客戶驅(qū)動和經(jīng)營意識

個人理解首先要培養(yǎng)的就是客戶驅(qū)動和經(jīng)營意識，做任何東西首先要考慮的是是否是真正客戶想要的，還是說為了自己的技術(shù)興趣要去學(xué)習(xí)和研究。

對于我們經(jīng)?？吹降囊粋€情況就是，我們的技術(shù)組件和技術(shù)開發(fā)框架選擇不斷的在追逐新技術(shù)不斷的在變化，但是客戶需求或并發(fā)往往并沒有到必須使用這些先進技術(shù)框架的程度。同時由于技術(shù)框架不斷的變化，導(dǎo)致我們的業(yè)務(wù)系統(tǒng)穩(wěn)定性反而下降，這就是我們常見的一種技術(shù)驅(qū)動。

客戶需要的產(chǎn)品沒有做好，但是技術(shù)人員自己新技術(shù)學(xué)了不少，公司出現(xiàn)啥問題了自己反而可以很容易跳槽到新的好公司。這種技術(shù)人員總結(jié)來說完全是為了個人利益而損害了公司本身的產(chǎn)品和經(jīng)營。

其次是我們說的經(jīng)營意識，如果你要轉(zhuǎn)產(chǎn)品經(jīng)理或項目經(jīng)理，你一定要有經(jīng)營意識，就是我們研發(fā)的產(chǎn)品究竟有沒有客戶買單，究竟能不能賺錢，你研發(fā)的產(chǎn)品技術(shù)再先進，功能再強大，如果沒有最終的客戶，沒有訂單，那么仍然是沒有任何產(chǎn)品價值可言。唯一的用處仍然僅僅是研發(fā)人員自己獲得了技術(shù)經(jīng)驗和技術(shù)積累。

所以我們研發(fā)的功能一定要去思考是否真正是客戶需要的，是否有真實的客戶需求。所有功能的新增和改進，都不能為了技術(shù)而技術(shù)。包括我們經(jīng)常談到的微服務(wù)架構(gòu)轉(zhuǎn)型也一樣，及時做架構(gòu)轉(zhuǎn)型也是實際企業(yè)業(yè)務(wù)發(fā)展情況下傳統(tǒng)的IT架構(gòu)無法滿足，需要我們技術(shù)架構(gòu)做出改變，而不是為了迎合新功能，新技術(shù)。

完全自研和拿來主義

對于技術(shù)人員，最容易犯的毛病就是為了體現(xiàn)自己的技術(shù)能力，總是希望所有的東西都要自己從頭到尾做一套，很多時候不屑于采用已經(jīng)的成熟的開源解決方案或已有的一些成熟產(chǎn)品。

在一個稍微大型一點的公司我們經(jīng)常就會看到，技術(shù)同樣一個技術(shù)，類似消息或緩存，往往不同的開發(fā)團隊都有自己的解決方案和定制化技術(shù)組件。為何出現(xiàn)這種情況？技術(shù)人員最常說的就是其他團隊的技術(shù)組件不能滿足我們的個性化需求，因此我們要重頭自己搞一套。

那么為何不能是提出個性化需求，然后由對方進行優(yōu)化和改進呢？

實際上如果真正能夠做到技術(shù)平臺和組件的通用化和復(fù)用，一個公司必須由類似TPG的平臺型技術(shù)組織和團隊，專門來做這件事情，構(gòu)建企業(yè)組織范圍內(nèi)共享的技術(shù)平臺和組件，而且在企業(yè)內(nèi)給出強制性的要求和約束，對于技術(shù)組件選擇必須從公司組件庫中選項，對于技術(shù)組件類需求必須提交到TPG進行統(tǒng)一評估等。

技術(shù)人員思維的另外一個轉(zhuǎn)變就是我們說的拿來主義，有現(xiàn)成的東西一定不要去從頭到尾去搞，特別是技術(shù)走到后期更多的能力應(yīng)該是在架構(gòu)和技術(shù)組件整合上面，而不是單個技術(shù)組件的研發(fā)。因為這樣是最快，最敏捷的能夠交付技術(shù)平臺和產(chǎn)品的思路。

市場機會往往稍縱即逝，技術(shù)團隊需要的就是在最短的時間拿出對應(yīng)的可用產(chǎn)品，然后在可用產(chǎn)品的基礎(chǔ)上不斷的迭代和優(yōu)化。而不是用很長的時間才交付一個客戶已經(jīng)跑掉的，無人問津的自認為完美產(chǎn)品。比如我們提出要在1個月內(nèi)給出一個快速上線的迭代產(chǎn)品，那么這個就是業(yè)務(wù)目標的強約束，沒有任何可以商量的余地，那么技術(shù)人員要思考的就是在這個約束下進行研發(fā)和交付。

做好研發(fā)和市場的協(xié)同

技術(shù)人員需要做好研發(fā)和市場的協(xié)同。當(dāng)有了經(jīng)營意識的時候我們就需要考慮我們的產(chǎn)品如何進行市場策劃和推廣，如何進行新功能和亮點的宣傳，如何拓展相關(guān)的渠道和合作伙伴，在這個過程中需要準備哪些產(chǎn)品介紹，宣傳材料，售前PPT等文檔材料等。

市場工作實際和研發(fā)工作本身也是迭代交替進行的，任何一個產(chǎn)品都不可能是完全研發(fā)出來后我們才去考慮如何進行市場推廣。因此市場策劃推廣和產(chǎn)品研發(fā)工作必須并行，而且需要市場和策劃宣傳先行，從市場項目機會到最終落單本身也有一個比較長的周期，因此只有這樣兩者才能夠配合協(xié)同起來。

而我們的技術(shù)人員往往有時候很難理解，為何產(chǎn)品沒做出來就開始進行市場宣傳已經(jīng)具備這個功能，這也是典型的沒有市場和經(jīng)營意識的表現(xiàn)。

用最適合的技術(shù)來解決問題而不是最好的技術(shù)

一個好的技術(shù)人員，或者說技術(shù)走向管理的時候一個重要的思維變化就是不能還是原來的技術(shù)狂熱型，技術(shù)本身是沒有價值的，技術(shù)的價值一定是附屬在產(chǎn)品上，讓產(chǎn)品產(chǎn)生了價值。但是產(chǎn)品是否真正有價值并不一定體現(xiàn)在技術(shù)先進性上，而是體現(xiàn)在功能是否滿足客戶需求上面的。

任何一個產(chǎn)品運營或者售賣，首先考慮的是在滿足客戶需求的情況下賺取最大化的利潤，技術(shù)發(fā)展太快，不存在最先進最好的技術(shù)，只存在面對當(dāng)前客戶需求和場景最適合的技術(shù)。

任何選擇技術(shù)上的超前性往往帶來的問題都是投入更大的研發(fā)成本和精力，其次就是新技術(shù)往往并不是最穩(wěn)定的技術(shù)反而導(dǎo)致產(chǎn)品不穩(wěn)定，這些都是技術(shù)人員需要思考和綜合衡量的地方。