快速技術成長:提煉和總結專案中的技術重難點

琴水玉發表於2024-08-04

踏著重難點前進。

引語

在“程式設計師工作中的理性與感性活動及所需的技能素養 ”一文中,談到程式設計師軟體開發中的常見活動及所需需要的技能素養;在“談談程式設計師應當具備的技術思維”一文中,談到了程式設計師在其職業生涯中需要具備的技術性思維;在“程式設計師做什麼有利於技術能力的成長”一文中,談到了程式設計師提升技術能力的常用方法和途徑;在“如何突破技術瓶頸”一文中,談到了程式設計師如何突破在一定階段的技術瓶頸。

最近,我又發現了一種能夠快速提升技術的方法,就是提煉和總結專案中的技術重難點。專案中的技術重難點,通常是一次專案中的最大收穫點,也是下次面試中你能夠突出的亮點。功夫在平時。

一個專案,大部分情況可能都是平淡無奇的碼程式碼牆,有時則可能會有一些挑戰,這就是專案中的技術重難點。能否及時攻克這些重難點,設計方案是否可靠,決定了專案的成敗和是否會返工,也有助於個人技術能力的提升和技術經驗的積累,和後續待遇的上漲。

那麼專案中技術重難點有哪些呢? 從自己的職業生涯中提煉出如下一些,與讀者分享。


專案中的技術重難點

開發新系統

面試官看到你的簡歷時,很難說想看到你的工作經驗只是一直維護老系統,而是希望能看到有新系統新專案開發。新系統新專案,往往意味著新的技術棧、先進的技術應用。無論是負責系統整體方案、架構設計和技術選型、新語言的掌握應用、新技術棧、還是作為團隊開發負責人,都是亮點。

比如我參與一個入侵系統新系統開發。一個團隊採用新的理念、新的設計方案來改寫原來的系統。所有模組都重新實現了一遍。當然也有借鑑原有系統的好的做法,但更多的是新的做法。

新系統的開發,可以將你的簡歷亮點一次拉滿。

技術重難點:架構設計和整體方案、模組設計與開發、團隊領導力、新技術棧、新語言應用。

效能最佳化

效能最佳化是第二個能夠抓住面試官的亮點。

搭建效能實驗,使用效能工具來分析效能、定位熱點區域、遇到的困難、找到辦法去提升效能,積累效能最佳化經驗,是一個很重要的技術提升點。

當面試官問到這一點時,可以透過 STAR 簡潔地回答某個專案的背景、問題、困難、方法、成果;能夠系統地說出效能最佳化的常用手段;能夠說出遇到的問題及解決方案,基本上就過關了。

日常面試中,很多候選人能夠說出幾點,但會比較散,不夠系統。如果有 5-7 年工作經驗,還表達得不夠有條理不夠系統化,那麼這種回答就是普通水平的。

技術重難點:效能問題及解決方案;效能手段及經驗。


大資料量

大資料量是效能最佳化之上的一個較大的技術挑戰。

你所負責的專案或系統中,業務資料量級有多大,增量有多少,如何應對。小資料了有小而美的做法,大資料量有更好的技術手段。

是否要分表、分庫、分片,遇到哪些開發難題、如何解決、如何部署上線,都需要記錄下來。

技術重難點:大資料量、儲存擴充套件能力、效能。

瞬時大併發流量

瞬時大併發流量,是另一個較大的技術挑戰。與大資料量這種逐漸累積的型別不同,瞬時大併發流量只出現很短的一段時間,卻能對系統帶來很大的衝擊,甚至使系統直接崩潰。

怎麼應對瞬時大併發流量,有一整套高併發方案。服務治理、限流、熔斷降級、負載均衡、CDN、冗餘、全鏈路壓測、應急方案等。即使自己的業務中暫時用不到,也可以去深入瞭解下,作為技術進階的一層階梯。

技術重難點:高併發、系統穩定性最佳化。


新演算法設計

新演算法設計往往是一種有樂趣的技術挑戰。

同時,要在實際系統中應用新演算法,還需要加入各種工程考量。比如多正則規則命中文字內容高亮展示。除了設計出演算法外,還需要考慮各種複雜的正則、正規表示式超時、多行匹配的情況。

技術重難點:演算法設計、工程考量。


結構變更

從一對一到多對多,往往需要對原有程式碼結構進行較大的改造,從而滿足對靈活性和效能的要求。

比如做網路封禁,從一個主機封禁一個IP,到多個主機封禁多個IP,採用併發批次的結構來改造原有單個處理的結構。

結構變更,在程式碼設計上,是一種挑戰。對個人思維能力、技術和設計能力提升有一定幫助。

技術重難點:設計模式、結構重構。


API 設計

前端有自己的邏輯組織結構。後端如果僅僅只按照自己的想象給前端提供的介面,可能自以為是通用的,但實際上用起來很難用。

比如IP詳情最佳化,涉及與前端的互動。在不同場景下,前端需要展示IP不同的樣式,同時在某種情形下,需要能夠展示IP對應的主機列表。這個問題,要考慮前端介面易用性,後端可能得遇到一個需求就改一次;如果只考慮後端介面通用性,則前端就寫得很難看。

如何兼顧 API 介面的友好性和通用性,確實也是一種型別的挑戰。

技術重難點:API 介面設計。


後端系統互動

除了提供 API 與前端互動,後端系統常常還需要其它系統互動、跟各種大資料系統對接。比如對接大資料演算法元件、檢測引擎等。制定合理的資料格式和安全便捷的通訊方式,就是技術重難點。此外,還需要考慮各種容錯處理。

技術重難點:資料格式制定、通訊方案、容錯處理。


系統整合

需要構建業務監控系統。此時,並不需要你精通什麼原理,而是評估各種系統,善於把已有系統的能力組合起來,為我所用。

技術重難點:評估系統,系統整合


技術預研

偶爾,可能會遇到技術預研的事情。不是有了方案立即去開發,而是要先去探索嘗試各種方案利弊如何,是否滿足專案需求,做一些技術預研與技術選型。比如,入職一月後做虛表機制探索,後面應用到 K8S 日誌審計檢測裡。

預研結果,往往是透過一個表格來彙報的。需要滿足哪些指標、有哪些實現方式,每一種實現方式在各個指標上的表現如何,最終根據實際情況權衡出一個比較適合的實現來。

技術重難點:技術預研、技術選型、預研結果報告。


中介軟體改造

中介軟體改造,有時需要對中介軟體做一些原始碼修改,以滿足專案中的特定要求,有時需要做出中介軟體的某種功能平替。這個過程中,往往需要解決很多小的技術問題,而這些小的技術問題中,可能會出現比較***鑽的。

比如近期做的信創改造,用 kafka 實現 redis 的 pub sub 機制,並滿足容器場景下的應用。從介面互動到實現方案到細節打磨,都有受益。

中介軟體屬於較底層的層面,且影響面通常很大,因此中介軟體改造是一種難度偏大的技術挑戰。如果你能搞定,相信你一定會感覺到內功又上一層樓。

技術重難點:中介軟體原始碼、技術小難題攻克。


複雜流程設計與改造

有時,你需要在已有的複雜流程中加入一些功能,或者改造流程使之更簡潔更高效。難的不是加功能,而是現有流程實現中通常插根針都比較難,並且常常涉及到較大的影響面。此外,複雜流程很容易出現難查的 bug, 尤其是有大量互動或高併發情況下。

比如做惡意程序服務端解殼處理流程,就總結出構建複雜流程的方法論:“分解-抽象-封裝-複用-組合-關聯-重構”。任意複雜的流程,都可以採用這個方法論構建出來。

技術重難點: 結構重構,影響範圍大,保證改動不影響原有功能,疑難問題排查。


技術重構遷移

如果你加入到一個已經度過初創期的團隊,那麼很可能會遇到系統需要技術重構的事情。也就是原系統之前因為難以承載業務複雜度的增長和業務量的增長,而需要作出一些技術性的重構。換技術棧。

比如在阿里雲入職後將 Flex 遷移到 Java ,在有贊剛入職不久的訂單匯出重構(php 遷移到大資料棧),接下來的交易系統重構(用領域驅動模型改寫),還有進入青藤雲之後的入侵系統重構(檢測流程的元件編排,Java 遷移到 Go)、降噪系統遷移重構。

系統重構,難的是架構設計和部署遷移。架構設計,需要滿足未來幾年的業務需求;而部署遷移,難的是不造成線上故障。

技術重難點:架構設計(效能、穩定性、可用性、擴充套件性、定製性、部署等)、部署(灰度、分流)、資料遷移。


全模組開發

一個人完成一個功能的所有涉及模組的開發。

比如服務端入侵的一個功能開發,涉及檢測配置、系統規則下發、告警檢測流程、告警列表、告警詳情、事件列表、事件總覽和分析板、告警歸併、自定義規則、加白處理、元素響應及處置。

這需要一個人對現有系統有相當的理解和掌握,有整體觀和全景視角。同時也需要系統設計得足夠通用靈活,這樣一個人做起來也不費事。可能搞定這個功能的一個模組也就是一兩行配置而已。

可以說,這是一種較大的挑戰型別。

技術重難點: 全域性視角、熟悉系統各個模組的實現、熟悉系統技術棧。


設計方案不周到的坑

有時,設計方案考慮不周到,就會踩一些坑。

比如程序元素的唯一標識用 PGUID,但是會出現同一個元素在不同告警裡出現,而客戶端因為業務的不同,上報的欄位有細微差異,就會導致程序元素的某些資訊被反覆覆寫,查不到自己所新增的那個欄位的值。

實際上,這個就是程序元素唯一標識設計不太合理或者說缺乏程序擴充套件資訊導致。程序元素應當包含一個擴充套件資訊,這個擴充套件資訊包含一個告警ID到特有欄位的對映(這個也可以記錄在告警表裡)。這樣,通用資訊不會受影響,而擴充套件資訊也不會被覆寫。

記錄這些教訓,也是積累了系統設計方面的經驗。

技術重難點:設計方案的坑


疑難問題排查

開發過程中,有時也會遇到一些疑難問題排查,比如臨界問題、併發問題、時間差問題、資料不一致問題等。

疑難問題排查,可以鍛鍊一個人“心細如針、明察秋毫”的細心的特質。

技術重難點:臨界問題、併發問題、時間差問題、資料不一致問題等各種問題型別。


科學地提升

相較於平平無奇地完成一個又一個需求(嗯,像不像接客?),採用科學的方法快速提升,更見效果。

咱們來看奧運健兒,他們為了衝鋒世界冠軍之座,顯然不是一個事情低水平重複做,而是採用一定的科學方法和量化指標,不斷訓練、測量、反饋、提升、再訓練、再測量、再反饋、再提升。這樣子螺旋式提升的。

那麼,在做軟體開發的過程中,要快速提升自身技術能力,也需要有意識地去提煉專案中的重難點,藉助這些重難點的磨鍊,讓自己的能力更上一層樓,而不是在一個個平庸的需求開發裡原地踏步。

我把入職青藤雲安全的三年的專案重難點總結出來之後,就覺得自己還是有了不少提升的。如果我把前兩家公司的專案重難點都總結出來,就能看到一個清晰的技術提升路線。


小結

本文分享了自己在職業生涯中遇到的大大小小各種技術挑戰。正是解決這些技術挑戰,促進了能力的提升。要想快速提升,不能簡單地重複已有的事情,而是有意識地去識別專案中的重難點,思考和解決他們,最終把方法和經驗都記錄下來。日積月累,總有一天,你會發現自己不負時光,更上一層樓。


相關文章