我們知道，一個好的「品味（taste）」對于做好 AI 產(chǎn)品，很重要。但對于技術(shù)，「品味」也同樣重要。

對于工程師來說，技術(shù)的品味與技術(shù)能力是兩碼事。有人可能技術(shù)能力強但品味差，或者技術(shù)弱但品味好。培養(yǎng)一個「好」的技術(shù)品味，有時會讓結(jié)果超出原有的技術(shù)能力。

那么，略顯「玄妙」的技術(shù)品味的核心是什么？硅谷資深工程師 sean goedecke 給出的答案是：「為當(dāng)前項目選擇適配的工程價值觀」的能力。

因為在軟件工程領(lǐng)域，絕大多數(shù)的決策，核心都是在不同目標(biāo)之間進行權(quán)衡。很少會遇到一個選項在所有方面都絕對優(yōu)于另一個選項的情況。這時候，有一個好的工程價值觀就特別重要。

如何建立一個好的工程價值觀，都在 sean goedecke 的這篇經(jīng)驗帖里了。

sean goedecke：Github 高級工程師

個人主頁介紹：https://www.seangoedecke.com/my-engineering-values-2025/

原博客鏈接：https://www.seangoedecke.com/taste/?utm_campaign=what-is-good-taste-in-software-engineering-6267&utm_medium=email&utm_source=seangoedecke

超 14000 人的「AI 產(chǎn)品市集」社群！不錯過每一款有價值的 AI 應(yīng)用。

邀請從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準(zhǔn)的AI產(chǎn)品曝光渠道

你可以技術(shù)能力強但品味差，或者技術(shù)弱但品味好。就像我們通常所說的「品味」一樣，技術(shù)品味有時會超過你的能力：就像不用會做飯也能分辨食物好壞，你可以在具備構(gòu)建軟件的能力之前就知道你喜歡什么樣的軟件。你可以通過學(xué)習(xí)和重復(fù)來發(fā)展技術(shù)能力，但良好品味的養(yǎng)成方式則更加「玄妙」一些。

以下是判斷技術(shù)品味的幾個參考方向：

• 在你眼中，什么樣的代碼「看起來優(yōu)雅」？什么樣的代碼「看起來粗糙」？

• 哪些設(shè)計決策會讓你由衷覺得出色的，而哪些只是「勉強合格」？

• 哪些軟件問題會讓你格外困擾，甚至在工作之外還惦記著？哪些問題你能輕松拋在腦后？

在我看來，品味的核心是「為當(dāng)前項目選擇適配的工程價值觀」的能力。

01
為什么品味不等于能力？

難道上述的判斷方向不正是技術(shù)能力的一部分嗎？比如，「看起來優(yōu)雅的代碼」不就是優(yōu)質(zhì)代碼本身嗎？我并不這么認(rèn)為。

舉個例子：對我個人而言，用map和filter實現(xiàn)的代碼，看起來比for循環(huán)更簡潔優(yōu)雅。人們很容易覺得，這是我在工程判斷上「直白且正確」的體現(xiàn)，畢竟map和filter通常基于純函數(shù)，這類函數(shù)更易推導(dǎo)邏輯，還能避免一整類「差一錯誤」（off-by-one）的迭代漏洞。我甚至?xí)乱庾R覺得，這不是品味問題，而是我正確而其他工程師錯誤的情況。

但實際情況要復(fù)雜得多。像 Golang 這樣的語言，出于原則性考量，完全沒有map和filter功能。從性能角度來看，for循環(huán)的迭代邏輯更易評估，并且也更直接地擴展到其他迭代策略（比如一次取兩個項）。我對「支持map和filter的理由」的重視程度，遠高于「支持for循環(huán)的理由」，這也是我很少寫for循環(huán)的原因。但如果因此就說「偏愛for循環(huán)的工程師能力更弱」，那就太傲慢了。很多時候，這些工程師具備我沒有的技術(shù)能力，他們只是在意的優(yōu)先級和我不同而已。

換句話說，我們的分歧本質(zhì)上是價值觀的差異。我曾在《我不懂如何開發(fā)軟件，你也不知道》（https://www.seangoedecke.com/confidence）這篇文中提到過這個觀點：即使技術(shù)大辯論確實有明確的答案，也沒有一個在職的軟件工程師能夠知道這些答案是什么，因為一個人在職業(yè)生涯中只能積累有限的經(jīng)驗。我們都或多或少都依賴自己的個人經(jīng)驗，依賴自己特有的一套工程價值觀。

02
技術(shù)品味的本質(zhì)是什么？

軟件工程中的幾乎每一個決策都是一種權(quán)衡。你很少會遇到「一個選項絕對優(yōu)于另一個」的情況，相反，每個選項都有其優(yōu)勢和短板。很多時候，你必須在不同工程價值觀之間做艱難取舍：比如超過某個臨界點后，要提升性能就難免會損害代碼的可讀性。

作者注：當(dāng)然，情況并不是總是這樣。有時也會出現(xiàn)雙贏的局面，讓你能夠同時提升幾個通常相互沖突的價值維度。但多數(shù)時候，我們無法奢求這樣的好事。

在我看來，真正理解這一點，是軟件工程領(lǐng)域「成熟度」的最大標(biāo)志。不成熟的工程師對自己的決定很固執(zhí)。他們認(rèn)為做 X 或 Y 總是更好的。成熟的工程師往往更愿意考慮決策的兩面，因為他們知道兩個方面都有不同的好處。關(guān)鍵不在于決定技術(shù) X 是否比 Y 更好，而在于在這個特定情況下，X 的好處是否超過了 Y。

換句話說，不成熟的工程師對自己的品味過于固執(zhí)。他們知道自己喜歡什么，但錯誤地將這種喜好視為一個原則性的工程立場。那么，是什么定義了一位特定工程師的品味呢？

在我看來，一個人的技術(shù)品味，由他最看重的那套工程價值觀構(gòu)成。比如：

• 彈性（Resiliency）：如果基礎(chǔ)設(shè)施組件故障（服務(wù)宕機、網(wǎng)絡(luò)中斷），系統(tǒng)還能正常運行嗎？能否在無需人工干預(yù)的情況下恢復(fù)？

• 運行速度（Speed）：軟件的運行速度與理論極限差距有多大？核心流程中是否存在非必需的運算步驟？

• 可讀性（Readability）：軟件是否一目了然，新工程師能否快速上手？函數(shù)是否簡潔、命名是否清晰？系統(tǒng)文檔是否完善？

• 正確性（Correctness）：系統(tǒng)是否可能出現(xiàn)無效狀態(tài)？通過測試、類型檢查、斷言等手段，系統(tǒng)的安全性是否足夠高？測試中是否用到模糊測試（fuzzing）等技術(shù)？極端情況下，是否通過 Alloy 等形式化方法驗證了程序正確性？

• 靈活性（Flexibility）：系統(tǒng)是否能輕松擴展？做出變更的難度有多大？如果需修改某個功能，要涉及程序中的多少模塊？

• 可移植性（Portability）：系統(tǒng)是否依賴特定運行環(huán)境（如微軟 Windows、亞馬遜 AWS）？如果需部署到其他環(huán)境，是否無需大量改造就能實現(xiàn)？

• 可擴展性（Scalability）：如果流量增長 10 倍，系統(tǒng)會崩潰嗎？增長 100 倍呢？系統(tǒng)是否必須過度配置資源，還是能自動擴展？哪些瓶頸需要通過工程改造解決？

• 開發(fā)效率（Development Speed）：如果要擴展系統(tǒng)功能，多久能完成？大多數(shù)工程師都能參與開發(fā)，還是必須依賴領(lǐng)域?qū)＜遥?/p>

除此之外，還有很多其他工程價值觀，如：優(yōu)雅性（elegance）、現(xiàn)代性（modern-ness）、開源使用（use of open source）、維持系統(tǒng)運行的貨幣成本（monetary cost）等等。所有這些都很重要，但沒有哪個工程師會同等地關(guān)心所有這些事情。你的品味，取決于你把哪些價值觀排在優(yōu)先位置。比如：

• 如果你更看重「運行速度」和「正確性」，超過「開發(fā)效率」，那你可能更偏愛 Rust 而非 Python；

• 如果你更看重「可擴展性」超過「可移植性」，那你可能會主張大力投入，充分利用托管平臺（如 AWS）的特有功能和工具；

• 如果你更看重「彈性性」超過「運行速度」，那你可能會希望將流量分配到不同的區(qū)域。

作者注：正如前文所述，不同的項目自然需要遵循不同的價值準(zhǔn)則。但負(fù)責(zé)這些項目的工程師們終究需要在某處劃定界限，而劃定界限的依據(jù)，是他們自身的品味。

這些價值觀還可以進一步細(xì)化。比如兩位同樣重視「可讀性」的工程師，可能因「一位偏愛簡短函數(shù)」而「另一位偏愛簡短調(diào)用棧」產(chǎn)生分歧；兩位同樣重視「正確性」的工程師，也可能因「一位依賴全面測試套件」而「另一位依賴形式化方法」持有不同觀點。但核心邏輯不變：值得關(guān)注的工程價值觀有很多，且它們之間常存在沖突，因此每個工程師都必須有所側(cè)重。

03
如何識別「壞品味」？

我說過，所有的工程價值觀都很重要。即便如此，糟糕的品味依然存在。在軟件工程領(lǐng)域，糟糕的品味意味著你偏好的價值觀并不適合你正在從事的項目。

我們大多數(shù)人都有與這類工程師合作的經(jīng)驗。他們加入項目后，就極力推崇某樣?xùn)|西：形式化方法、用 Golang 重寫代碼、Ruby 元編程、跨區(qū)域部署等等。只因為這些方法在他們過去的工作中奏效過。無論是否適合當(dāng)前項目，他們都會極力主張采用，僅僅是因為「這是他們喜歡的方式」。不知不覺中，不知不覺中，你就在確保你的內(nèi)部指標(biāo)儀表板有五個九的可靠性，而代價是讓任何初級工程師都無法理解它。

換句話說，大多數(shù)壞品味都來源于「僵化」。我永遠不信任那些通過說「這是最佳實踐」來為決策辯護的工程師。沒有任何工程決策在「所有場景下」都是「最佳實踐」。你必須根據(jù)當(dāng)前面臨的具體問題，做出最適合的選擇。

這一點帶來的有趣結(jié)果是：品味糟糕的工程師，就像壞掉的指南針。要是你恰好站在正確位置，它或許還能指向北方；但一旦你開始移動，它就會帶你偏離方向。同樣，很多品味糟糕的工程師，在「自己的偏好與項目需求匹配」的特定領(lǐng)域里，可能表現(xiàn)得相當(dāng)出色?？梢坏Q項目、換工作，或項目性質(zhì)發(fā)生變化，問題就會立刻暴露。沒有哪個工作能長期不變，尤其是在 2021 年后這個充滿變數(shù)的時代。

04
如何識別「好品味」？

相比技術(shù)能力，好品味要難識別得多。因為技術(shù)能力可以通過具體的指標(biāo)來衡量，而好品味的本質(zhì)是「為特定技術(shù)問題選擇適配的工程價值觀」的能力。因此，判斷一個人是否有好品味并不容易：你無法通過「玩具問題」（toy problems）或「技術(shù)常識提問」測試，必須結(jié)合一個真實問題，以及問題背后所有復(fù)雜的現(xiàn)實背景才能判斷。

如果你的項目成功了，你可以說自己有好品味。如果你沒有對項目的設(shè)計做出有意義的貢獻（也許你只是在做任務(wù)工單），但你認(rèn)同的的項目進展順利，你不認(rèn)同的項目磕磕絆絆，也可以說自己有好品味。

重要的是，你需要經(jīng)歷一系列不同類型的項目。如果只有一個項目，或者反復(fù)進行同一種類型的項目，你可能只是適合那個項目。即使你經(jīng)歷了許多不同類型的項目，這也并不能保證你在不太熟悉的專業(yè)領(lǐng)域同樣具備好品味。

作者注：我確實認(rèn)為好品味在某種程度上是可以遷移的。關(guān)于這一點，我個人經(jīng)驗不多，但我想，如果你在 A 領(lǐng)域能夠展現(xiàn)出靈活性和對細(xì)節(jié)的洞察力，那么在 B 領(lǐng)域，你很可能也能做到同樣出色。

05
如何培養(yǎng)良好品味？

這很難給出確切的標(biāo)準(zhǔn)答案，但我建議你：

1. 多嘗試不同類型的工作，仔細(xì)觀察哪些項目（或項目的哪些部分）做起來輕松，哪些部分是困難重重的；

2. 注重靈活性，盡量避免對軟件開發(fā)的正確方式形成絕對化認(rèn)知。

我自己的好品味也是慢慢積累起來的，但這并不意味著它一定需要長期沉淀，我相信有些人可以快速養(yǎng)成。就像其他領(lǐng)域有超越經(jīng)驗的天才一樣，編程領(lǐng)域也一定有品味遠超自身經(jīng)驗的天才。

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker