【CSDN 編者按】這是一位開(kāi)發(fā)者從軟件工程師到架構(gòu)師、創(chuàng)業(yè) CEO、再到售前崗位的職業(yè)回顧。他沒(méi)有空談概念，而是結(jié)合真實(shí)經(jīng)歷，分享了在 CI/CD、測(cè)試體系、GitOps、架構(gòu)演進(jìn)、文檔管理、團(tuán)隊(duì)協(xié)作等方面踩過(guò)的坑與反思。對(duì)于正在一線(xiàn)開(kāi)發(fā)、架構(gòu)設(shè)計(jì)或帶團(tuán)隊(duì)的工程師來(lái)說(shuō)，這些故事或許能讓你少走彎路，也能幫你更快建立起屬于自己的“工程方法論”。

原文鏈接：https://lukasniessen.medium.com/lessons-learned-in-my-10-years-it-carreer-swe-software-architect-startup-ceo-presales-97b5c6bd25ae

作者 | Lukas Niessen 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

在我的職業(yè)生涯中，我先后做過(guò)軟件工程師、軟件架構(gòu)師、創(chuàng)業(yè)公司的創(chuàng)始人兼 CEO，也干過(guò)售前崗位。一路走來(lái)，踩過(guò)不少坑，也積累了一些經(jīng)驗(yàn)。

坦白說(shuō)，這些教訓(xùn)并不是什么“新發(fā)現(xiàn)”，很多都能在書(shū)里找到。但對(duì)我而言，真正的價(jià)值在于——它們不是抽象概念，而是我親身經(jīng)歷過(guò)、付出過(guò)代價(jià)之后總結(jié)出來(lái)的。

CI/CD 不只是“更快”

在一家初創(chuàng)公司時(shí)，我們一直在討論要不要給代碼倉(cāng)庫(kù)加一條 CI/CD 流水線(xiàn)。大家都知道這算是最佳實(shí)踐，能省時(shí)間，也能真正實(shí)現(xiàn)持續(xù)集成和持續(xù)交付。否則，每次提交代碼都要手動(dòng)跑測(cè)試、構(gòu)建、Lint、部署，簡(jiǎn)直不可想象。

但是，大家也覺(jué)得“搭流水線(xiàn)會(huì)花點(diǎn)時(shí)間”，于是總是拖延。直到有一天，我們?cè)谏钜故謩?dòng)部署時(shí)，負(fù)責(zé)的小伙伴把一個(gè)配置參數(shù)填錯(cuò)了，結(jié)果導(dǎo)致用戶(hù)的個(gè)人資料功能掛了好幾個(gè)小時(shí)，直到我們緊急打補(bǔ)丁才恢復(fù)。

這次經(jīng)歷讓我明白：CI/CD 不僅是為了節(jié)省時(shí)間，更是為了減少人為錯(cuò)誤。當(dāng)然，這個(gè)道理在書(shū)本上早就寫(xiě)過(guò)，但當(dāng)你親身經(jīng)歷一次事故，感受就完全不同了。

測(cè)試是為了“可演進(jìn)性”

還是在那家初創(chuàng)公司，由于趕時(shí)間上線(xiàn)，我們一開(kāi)始幾乎沒(méi)有寫(xiě)測(cè)試。大家都心知肚明這會(huì)是“技術(shù)債”，但當(dāng)時(shí)覺(jué)得頂多就是線(xiàn)上偶爾冒幾個(gè) bug，修一修也就算了。

直到后來(lái)我們才發(fā)現(xiàn)，測(cè)試的價(jià)值遠(yuǎn)不止“抓 bug”。它真正的作用在于：讓系統(tǒng)可以演進(jìn)下去。

想象一下，當(dāng)你需要修改一年前寫(xiě)的某段代碼時(shí)，你根本無(wú)法保證不破壞什么。即使有文檔，你也不可能完全掌握當(dāng)時(shí)的上下文和所有依賴(lài)。于是，大家都變得“不敢碰舊代碼”。

最后的教訓(xùn)就是：只有完整的測(cè)試體系，才能讓人有信心重構(gòu)和演進(jìn)系統(tǒng)。這也是為什么像 Martin Fowler、Michael Feathers 這些作者會(huì)把“沒(méi)有測(cè)試的代碼”直接定義為“遺留代碼”。

后來(lái)我做咨詢(xún)工作時(shí)，又在架構(gòu)層面再次遇到了同樣的問(wèn)題。如果沒(méi)有驗(yàn)證架構(gòu)設(shè)計(jì)的測(cè)試（比如 fitness function），架構(gòu)就很難隨著業(yè)務(wù)演進(jìn)。為了解決這個(gè)問(wèn)題，社區(qū)有一些工具，比如 Java 的 ArchUnit，而我甚至還寫(xiě)了一個(gè) TypeScript 版本的：ArchUnitTS。

Push-basedGitOps ≠ 真正的 GitOps

簡(jiǎn)單回顧一下 GitOps：它強(qiáng)調(diào)把Git 作為唯一事實(shí)來(lái)源，不僅管代碼，還管基礎(chǔ)設(shè)施、配置和部署流程。

GitOps 有兩種方式：

• Push-based：代碼合并后，由流水線(xiàn)把改動(dòng)推送到集群；

• Pull-based GitOps：集群自己從 Git 拉取最新配置并同步。

很多人認(rèn)為 Push-based GitOps 并不算真正的 GitOps，我以前沒(méi)太當(dāng)回事，直到踩了坑。

我們的微服務(wù)架構(gòu)跑在 AWS EKS 上，基礎(chǔ)設(shè)施用 Terraform 管理。正常情況下，分支合并到主干后，CI/CD 會(huì)自動(dòng)合并改動(dòng)。但某次 DevOps 工程師休假，線(xiàn)上出現(xiàn)性能問(wèn)題，于是后端開(kāi)發(fā)臨時(shí)用kubectl edit手動(dòng)調(diào)高了內(nèi)存限制，問(wèn)題解決了。

一周后，DevOps 回來(lái)部署安全補(bǔ)丁，更新了 Helm 模板，合并進(jìn)主干，流水線(xiàn)自動(dòng)跑。結(jié)果幾分鐘后，之前有內(nèi)存泄漏的服務(wù)又崩了，因?yàn)榕渲帽贿€原成了 Git 倉(cāng)庫(kù)里的舊值——我們一開(kāi)始完全搞不懂為什么“一個(gè)安全補(bǔ)丁”會(huì)導(dǎo)致線(xiàn)上掛掉。

這次事故讓我認(rèn)識(shí)到：Push-based GitOps 隱含著巨大的風(fēng)險(xiǎn)，因?yàn)槿魏巍笆謩?dòng)修改”最終都會(huì)被覆蓋。后來(lái)我們切換到了 Pull-based GitOps，用 ArgoCD 來(lái)實(shí)現(xiàn)，這樣不僅避免了配置被覆蓋的問(wèn)題，還提升了安全性（倉(cāng)庫(kù)本身不再擁有對(duì)集群的過(guò)多權(quán)限）。

其他一些教訓(xùn)

有些沒(méi)那么長(zhǎng)的故事，但也同樣值得記錄：

• 文檔要寫(xiě)明 “為什么”

干凈的代碼（Clean Code）也好，自解釋代碼也好，很多人都推崇“少寫(xiě)注釋”。但再干凈的代碼，也解釋不了“為什么要這么做”。比如為什么選這個(gè)算法、這個(gè)架構(gòu)，而不是另一個(gè)？我們?cè)诔鮿?chuàng)公司時(shí)，文檔不少，但很少寫(xiě)“原因”。結(jié)果就是——人都走了，或者時(shí)間久了，沒(méi)人記得當(dāng)初的決策邏輯。后來(lái)我們才意識(shí)到，像 Architecture Decision Record（ADR）這樣的形式，其實(shí)非常重要。

• 《人月神話(huà)》是真的

項(xiàng)目越復(fù)雜，新人上手越難，溝通成本越高。加人并不一定加速，反而可能變慢——這個(gè)道理，直到自己帶團(tuán)隊(duì)才切身體會(huì)。

• 今天犯錯(cuò)比明天犯錯(cuò)好

決策越早做，代價(jià)越小。哪怕錯(cuò)了，盡快獲得反饋、快速修正，總比拖到后面讓整個(gè)系統(tǒng)受牽連要好。

• 關(guān)注業(yè)務(wù)價(jià)值，而不是炫技

技術(shù)不是堆棧越新越潮越好，最終要看業(yè)務(wù)產(chǎn)出。比如，很多公司盲目追逐微服務(wù)，結(jié)果搞得比單體更復(fù)雜。如果一個(gè)單體能跑得好，那它就是更優(yōu)解。

• 產(chǎn)品驅(qū)動(dòng)增長(zhǎng)，而不是短期收益

我創(chuàng)業(yè)時(shí)最大的感悟之一就是：不要為了“快贏”而犧牲長(zhǎng)期價(jià)值。好的產(chǎn)品和服務(wù)，才能帶來(lái)更長(zhǎng)遠(yuǎn)的增長(zhǎng)。

• 怎么帶團(tuán)隊(duì)？敏捷 + 文化

對(duì)我來(lái)說(shuō)，帶團(tuán)隊(duì)最有效的方法就是：敏捷（擁抱變化而不是死守計(jì)劃），再配合“主人翁文化”和“反饋文化”，同時(shí)把技術(shù)愿景清晰傳達(dá)出去，這樣團(tuán)隊(duì)的戰(zhàn)斗力才能發(fā)揮到極致。

【活動(dòng)分享】2025 全球機(jī)器學(xué)習(xí)技術(shù)大會(huì)（ML-Summit）北京站將于 2025 年 10 月 16-17 日在北京威斯汀酒店舉辦。大會(huì)共 12 大主題、50+ 海內(nèi)外專(zhuān)家，聚焦大模型技術(shù)和應(yīng)用變革。詳情參考官網(wǎng)：https://ml-summit.org (或點(diǎn)擊原文鏈接）。