[轉]一線技術人應該關注的四種思維能力

一、引言

作爲長期奮戰在一線的技術人,我深刻體會到如下幾個思維能力對技術人成長的重要性,熟練運用這幾種思維可以幫助我們快速的進入到新的領域,在分析、定位和解決問題上有很大幫助。

1)抽象思維:幫助我們快速抽取面對問題的關鍵要素和本質,可以是其他能力的“元能力”
2)分層思維:幫助我們拆解問題,分而治之,劃清問題和職責邊界
3)歸納思維:幫助我們從個性問題中抽象出問題的一般規律和得出共同結論
4)結構化思維:幫助我們沉澱自己的知識樹,逐步系統性的思考問題

 

二、抽象能力

1.什麼是抽象能力

提到抽象,程序員第一反應可能是 abstract,抽象能力的官方解釋是這樣的“抽象是從衆多的事物中抽取出共同的、本質性的特徵,而捨棄其非本質的特徵的過程。抽象表達的是一種思維方式,用來反映事物的本質和規律的方法,抽象強調的是關注要素,隱藏額外細節”。

抽象能力是每個人自有的一種天生能力,可以讓我們把一些相似的東西集中概括起來,暫時忽略他們之間的差異。當我們遇到從未見過的事物時,如果能夠運用“抽象能力”去尋找記憶中的知識與現有的事物之間的聯繫,作爲解決問題的關鍵要素,那麼我們解決問題的效率將會大大上升,比如當我們碰到下圖中左側這個動物的時候,我們不知道它具體是什麼動物,但是因爲我們腦海裏有一個貓科動物的抽象(如右側),所以通過尋找記憶中的知識,我們可以知道它是貓科動物的一種,而不會直觀的把它當成一匹馬。

 

 

 

2.抽象能力的重要性

抽象能力在我們的工作中非常重要,甚至能決定一個人能力水平的上限,一個抽象能力強的人,往往能從複雜的現象中直擊事物的本質。這也就是我們生活中常見到的一些人總是能抓住事情的重點、總能看到別人看不到的,或者碰到問題能夠快速給出有效解決方案或思路。

 

3.抽象能力決定你是否能比別人快速掌握技能

作爲一線程序員的核心本職工作是編程,編程的本質也是爲了解決生活中的實際問題而存在的,通過抽象能力把現實中的內容的本質和特性抽象出來,然後抽象到系統模型上應用於工作中,通過編程的方式來解決一類問題,這也就是“設計源於生活、紮根生活,最終爲生活服務”。


舉一個例子,阿里西溪園區有一個做麻辣香鍋的檔口,比較好奇麻辣香鍋是怎麼做的,正好檔口的加工過程是開放式的,所以我就站在那邊等餐邊觀察他們的加工過程,下面是一個完整的流程:

麻辣香鍋有 4 個工人,每個工人負責固定的實操,整個麻辣香鍋的加工過程按照一個固定的流程扭轉,各個工人之間交接的內容標準固定,比如上圖:
工人 1: 負責的實操:稱重、收銀(刷工卡)、擺放(有序擺放) ,工人 1 完成擺放最後一個操作後,會把商品放到一個筐中交給工人 2;
工人 2: 負責的實操:取件(有序取件)、分類(蔬菜和肉類分開)、煮熟、裝碗,工人 2 按照上述流程完成自己的工作後,將加工好的商品放到一個碗中交給工人 3;
工人 3: 負責的實操:取件、加料、炒熟、換碗,工人 3 將工人 2 加工後的商品按照上述流程完成炒熟的加工,炒熟後給到工人 4;
工人 4: 負責的實操:取件、加配料、妥投(叫號),工人 4 負責對最後的商家做錦上添花的配料加工。

完成所有的實操之後,工人 4 通過叫號的方式客戶上門自取的方式完成妥投.,整個工作流程中不需要單獨有個工人來指揮調度(無狀態,不需要記錄當前的調度節點及進度),他們會按照既定流程完成本職工作。

在回到我的工作中,我的工作內容有一部分跟協同關係比較大,協同這部分的本質和一個麻辣燙的加工過程非常相似,區別在於一個是人之間的協同,一個是作業節點之間的協同,下面給一個協同調度流程示例:

 

 

 

共性抽象:

這兩個看似不相關的東西其實有相同的共性,麻辣燙的每個工人等同於我們的實操節點,他們的工作等同於生成倉作業單、下發倉作業單、倉出庫等,倉出庫-->創建配作業單等同於工人 2[裝碗]之後交給工人 3,倉出庫就觸發了一個協同事件,觸發了工人 3 的作業,倉出庫的包裹就是交接的碗(交接物),通過這個我們把現實中的事物本質抽象成了調度協同的基本模型,包含[協同模版]、[協同節點]、[協同事件]、[工序]、[交接物],然後通過編程系統這個能力,藉助於此解決了當時域內最大的痛點:協同調度模版的爆炸式膨脹和無法動態編排的問題。因爲我們把“調度協同的本質”共性抽象實現了一下,所以天然收割了一波技術紅利,第一次把正逆向調度協同業務都融合進來,同時也複用到了 2C 和 2B 的其他業務域中。

下面是我們的調度升級版後的配置化頁面:

本次升級也支持了調度模版的多版本控制、生效規則、審批發布流程等,也從以前一箇中心化的調度升級到無狀態去中心化的服務協同,降低了系統依賴、提高健壯性。

 

4.抽象能力是將複雜問題簡單化的重要方法

 《史記》有云:“大樂必易,大禮必簡。”意思是說.“大”的音樂一定是平易近人的;“大”的禮儀則一定是簡樸的。世界的表現雖然複雜,但方法的本質卻是簡單。面對紛繁複雜的萬事萬物,迎接不斷出現的新情況新問題,說難也難,說易也易,關鍵看你能否把握事情的本質,複雜問題簡單化是提高我們生活工作效率的正要途徑,通過抽象思維把複雜問題簡單化的例子有很多,比如:

a)曹衝稱象

 孫權送來了一頭大象,曹操想要知道大象的重量,詢問他的屬下這件事,但他的手下都不能說出稱象的辦法。曹衝說:“先把象放到大船上,在水面所達到的地方做上記號,然後將大象牽下來,再讓船裝載其它東西,稱一下這些東西,那麼比較下就能知道了。

b)地鐵線路圖

 即使不標出各個站點之間相隔的具體距離,也沒有標出它們的具體位置,僅僅只是提取了必需的信息,就能將整個複雜的地鐵體系簡單地表現出來。我們只要有地鐵路線圖,就可以知道要怎樣去各個站。

c)系統交接

再舉一個最近發生在身邊的例子,前幾天的一個系統交接會上,交接過程中總感覺有些遺漏,基於我自己記憶中的知識,我判斷交接清單至少包含如下幾個內容:
1)系統架構圖、核心領域模型
2)核心業務流程、時序
3)上下游系統依賴、核心聯繫人、協議方式
4)中間件基礎資源依賴、基本賬號
5)系統操作頁面、入口
6)以往大促保障手冊、應急預案、資損盤點
7)系統基礎監控、業務監控地址
8)遺留線上 Bug 清單和 Owner 分配
9)代碼權限以及核心 L0 入口

其實上面都是基於對一個系統本來該有的內容的一個抽象,所有的業務系統都具有相同的特徵,日常的抽象積累可以讓工作更輕鬆更簡單,不至於束手無策、手忙腳亂,抽象思維讓我們只關注了要素隱藏了很多細節,按照上面這 9 個大類要素深入進去,我們面對的就是無窮的細節,細節是決定成敗的關鍵。

 

三、分層思維

除了抽象,分層也是我們應對和管理複雜性的基本思維武器。日常生活中的一些分層的例子,比如我們經常所去的大商超,店鋪的分佈也是有分層的思維,比如負一層一般是小喫檔口/停車場,一層一般是化妝品/香水/黃金首飾店鋪,二樓是女裝、三樓是男裝、四樓是兒童/母嬰用品,在往上就是餐廳和電影院、健身房等,通過分層思維,商超將一些共性的東西劃分到一起,讓管理和客戶消費更輕鬆(如一般晚上只有電影院的那層關門最晚,其他樓層相對較早,管理上可以重點保障該樓層的用電和安保。),類似用到分層思想的東西非常多,比如新華字典收錄了 8000 字,通過按照漢語拼音的順序完成所有漢字的分層,同時提供一個目錄用於快速檢索。這樣一個複雜的問題就簡單化了。在系統架構和設計中,分層思維也是常用的一個思維方式,比如:

 

 

 

 

 

 在我負責的系統架構設計上,分層思維也是比較常用的一個思維方式,比如:

1.業務能力管理[業務邏輯的分層管理]

 

 

 

 如上圖,業務需求管理上我們採用三層架構的方式來進行業務管理,其本質是採用分層的思想,劃分成三層,基礎層、行業層、商家層,每一次有不同的定位和職責。

a. 基礎層
主要沉澱業務的共性和一些基礎標準和規範定義,並提供一些默認實現。

b. 行業層
主要沉澱業務的特性的內容,在基礎層的基礎上疊加一些特性內容形成具體的行業,不同行業之間也是一個分層思維,通過不同的行業分層管理行業間的差異。

c. 商家層
主要沉澱業務的個性的內容,在行業層的基礎上疊加一些個性內容形成具體的業務身份,不同業務身份之間也是一個分層思維,通過不同的業務身份來管理他們之間的差異。

 

2.系統架構設計[系統模塊的分層設計]

 比如在數據中心的系統架構設計上,劃分不同層次、不同的層次職責邊界清晰。

 

通過分層的思維設計,每一層有自己的基本定位和職責邊界,逐級往上提供基礎能力。

a. 數據基礎層
主要解決多數據源快速接入,數據快速形成一個寬表,核心面臨的挑戰是數據的質量和穩定性這方面,因爲數據實時性的提高必然帶來一致性的挑戰,對上層提供基礎數據支撐。

b. 數據服務層
主要解決業務數據的快速服務化的問題,沉澱數據開發平臺來支撐,配套的服務測試、發佈審批流程以及支撐多數據源接入,對上層提供數據資產服務。

c. 數據視圖層
主要解決數據資產服務的權限管理問題,控制了什麼人能看到什麼資源以及看到哪些數據範圍,對上層開放,支持 appkey 的多資源訂閱。

d. 數據 APP 層
主要解決數據開放管理的問題,通過 appkey 來訂閱,目前已經支撐異常中心、小時達實時指揮中心、算法等衆多消費場景。

 

通過這四層架構分層設計,實現了數據來源於業務又迴歸到業務這一過程。

我們在運用分層思維的時候也離不開抽象能力,利用抽象能力去提取他們的共性忽略差異細節。

 

 

四、歸納思維

很多時候,我們習慣了碰到問題,都希望能快速的解決,而快速解決的方法很多隻能是做表面工作,從表面解決,從表面上下功夫,頭痛醫頭腳痛醫腳,不追究發病的病根,看似很快,實則隱患不少,待問題再出現的時候代價會更大,其實最快的解決問題是從根本上解決問題,雖然這樣前期不能最快解決問題,投入的精力也會很多,但是投入的成本低,在沒有形成頑疾的時候,提前介入,一勞永逸。

“物有本末,事有始終,知所先後,則近道矣。”,當我們瞭解了一件事情的來龍去脈,掌握了事情的本末結構 就基本探究到了事情的本來面貌,歸納思維讓我們可以從一個個具體的事例中,推導出它們的一般規律和共通結論的思維。幫助我們尋找問題的根因,從而對症下藥解決問題。歸納思維的方法有很多在此不做討論,生活中運用到歸納思維的例子有很多。天空烏雲密佈,燕子低飛,螞蟻搬家等現象時,我們會得推斷說天要下雨了。還有很多比如立冬晴一冬凌,立冬陰一冬溫等等。歸納思維應用於工作中,可以幫助我們通過個別問題歸納推演出一類問題的共性和規律,採取合理的方案解決問題,舉幾個身邊的例子:

1.開發人員運維投入成本的問題

 部門成立初期由於業務上的變化較大,爲了支撐業務,底層數據模型的做了一次升級,新增了部分數據模型,兄弟團隊或者業務運營同學經常會丟一個單子過來讓開發同學人工幫忙查單據狀態、物流進度、單據關係等,這個造成了值班的開發同學編碼時間經常被打斷,效率下降,所以我們歸納推演了下分析問題的本質是【運維工具上的缺失】,基於此問題根因孵化了<火尖槍>和<乾坤圈>,降低了開發同學的運維投入的問題。

2.火尖槍

 根據任意單號快速查詢全鏈路數據的工具,實現從交易場到物流場全鏈路數據一鍵查詢。

3.乾坤圈

 通過單據的生命週期和單據之間的關係管理沉澱了"AAR"模型,實現任意單號/關鍵字全鏈路日誌搜索並按照實際發生時間鏈式展示。

4.業務快速分析的問題

爲了更好的支撐業務接得快、改的少、讓系統更加高可用,FY22 財年針對目前系統架構做了一次升級,本次升級和以往不同的是:技術和業務支撐同步進行且有人員資源上的問題,抽調了一部分負責數據和異常較多的同學來參加架構升級,所以一個問題就出現了:對線上業務的瞭解和差異分析。這個瞭解不單獨是知道業務是什麼,要知道線上的業務所有細節,包括這個業務下的一個開關在做什麼。這個對於當時參加的同學和架構來言都是一個很大的挑戰。通過歸納總結,我們把一些好的案例規整以後產生出了一個業務梳理大綱,按照這個大綱去梳理業務,同時持續完善這個大綱。讓所有同學都可以先有一個大的視角來看,忽略一些細枝末節。梳理的業務大綱如下:
1.通用資料庫
2.作業模版分析
3.業務身份分析
4.實操節點(倉、運、配等)接入方式分析
5.調度協同分析
6.售中逆向分析
7.售後逆向分析
8.財務/庫存分析
9.核心業務流程分析
10.數據庫關鍵字段分析
11.廣播消息彙總
12.業務分析彙總
13.線上示例單據&消息整理
14.關鍵報文
15.單據屬性對比
16.領域消息對比
17.架構升級新增測試點
18.特別測試場景提醒
19.自測案例

持續的歸納總結,不僅是讓工作做的更好更輕鬆,更多的是對自己不斷產生出滾雪球的收益,所以從這個需求/這個問題排查開始,多問幾個爲什麼。

 

五、結構化思維

先來看下下面這些數字,然後在 10 秒內說出所有數字和字母:
2, 4, f, 8, n, 4, 2, 3, 7, d, b, a, h, e, k, m, i, 3, g, j, 9, 6, 5, 1, 1, 0, c, l

面對這樣一堆沒有任何規律的數字,如果要記下來是不是有點難?如果我們把這些數字的內容調整下,變成下面這樣:
0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, g, h, i, j, k, l, m, n

是不是清晰了很多?
其實這涉及到了結構化思維:當人接收到大量雜亂信息時,處理複雜信息的能力有限,但是更偏愛有規律的東西。我們每天工作生活中都會接收到大量信息,如何把這些信息吸收並結構化爲我所用就需要構建自己的知識樹。比如上面的業務梳理大綱的例子,其實我們就構建了一個自己的知識樹,通過它我們可以檢索我們需要的信息,好的知識樹可以借鑑,但是每個人都有自己的一個思維方式,如果沒有內化成自己的或者不是自己構建的知識樹無法熟練的使用。

結構化思維指從整體思考到局部,是一種層級分明的思考模式。簡單來說就是借用一些思維框架來輔助思考,將碎片化的信息進行系統化的思考和處理,從而擴大思維的層次,更全面地思考。沒有結構化的思維是零散混亂無條理的想法集合,而結構化思維是一個有條理有層次,脈絡清晰的思考路徑,讓這些點連成了線,舉一個常用的問題解決方法思維框架:

 

 

 

 按照這個思維框架,很多問題的解決都可以用的上,比如上面舉過的一個數據中心的例子,應用這個思維框架後,基本思維路徑如下:

 

 

 

六、總結

一線技術人每天面臨的都是寫需求、改缺陷、查工單,加班,長此以往。有時候不妨跳出來以一個旁觀者的身份看一看自己,做一個需求前多問幾個爲什麼?寫一段代碼前先理一下邏輯思路,需求發佈以後想一下怎麼運維(最好的是讓沒做過這個需求的人也知道怎麼處理工單,打破知識壁壘和人員壁壘),在這個域沉澱的東西如何複用到另外一個域。我們面臨的業務是變化的但是做事的方法是有共性的,如何沉澱這些共性的做事方法纔是做業務需求帶來的最大成長。

低頭走路,擡頭看天,長路漫漫,不忘初心 -- 自勉

 

 

原文出處:https://mp.weixin.qq.com/s/Gnzf2WGACexmvCwmIInn_g

公衆號阿里巴巴中間件

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章