软件开发中的「技术品味」：如何定义代码的好坏？

今天的文章，想讨论一个软件工程中非常常见、但又有点玄妙的概念——「技术品味」（Technical Taste）。

我们评价一个程序员，通常会看他的技术能力，比如算法掌握得好不好，框架用得熟不熟。但还有一个维度，可能更重要，那就是他的「品味」。

今天，我读到了 Sean Goedecke 写的文章，题为 The Art of Technical Taste in Software Engineering。

他提出了一个很有启发性的观点：技术品味(Technical Taste)与技术能力(Technical Skill)是两回事。

一个程序员可以技术很强，但品味很差；也可以技术尚有欠缺，但品味很好。

这就好比美食。我们很多人都能轻易分辨一道菜是美味还是难吃，但这并不意味着我们自己就是大厨。我们对美食的「品味」可能远超于我们的「烹饪能力」。

同样，在软件开发中，你可能早就知道什么样的软件是好软件，即使你暂时还不具备构建它的能力。

技术能力可以通过学习和重复练习来提升，但技术品味的养成，似乎要神秘得多。

那么，到底什么是技术品味？它又如何影响我们的日常开发？

一、什么是技术品味？

Sean 认为，我们可以通过几个问题来审视自己的技术品味：

• • 什么样的代码在你看来是「优美」的？什么样的代码是「丑陋」的？
• • 哪些技术决策让你感觉特别棒，哪些只是觉得「还行」？
• • 哪些软件问题会让你寝食难安，甚至在下班后还在思考？哪些问题你觉得可以一笑置之？

这些问题的答案，背后反映的不是你的技能水平，而是你的价值取向。因为很多时候，「优美的」代码并不天然等同于「好」代码。

Sean 举了个例子：map/filter 与 for 循环。

从表面上看，这是个纯粹的技术问题。

比如，map 和 filter 与函数结合使用，可以使得代码更容易推理，避免迭代器错误。似乎用 map 的人就是比用 for 的人更正确。

但真的是这样吗？

像 Go 这样的语言，出于其设计哲学的考量，根本就没有内置 map 和 filter。Go 的设计者认为，传统的 for 循环在性能上更容易预测和推理，并且在扩展迭代逻辑（比如一次处理两个元素）时更加直接和灵活。

归根到底，这两种看法，谁对谁错？或许没有标准答案。这恰恰就是品味，或者说价值观的体现。

软件工程中的许多宏大辩论——静态类型 vs 动态类型，微服务 vs 单体，ORM vs 原生 SQL……这些可能永远没有唯一的正确答案。

没有任何一个工程师的职业生涯能够经历所有场景，从而获得「上帝视角」。我们每个人都在很大程度上依赖于个人经验，形成了自己的一套工程价值观。

Sean 给出了一个非常精彩的定义：

技术品味，就是在特定项目中，选择并采纳一套与之相适应的工程价值观的能力。

这个定义的核心在于两个词：「工程价值观」和「适应性」。一个有品味的工程师，不是固守某一种「最好」的实践，而是懂得根据当前项目的具体情况，做出最合适的权衡和选择。

二、什么是工程价值观？

软件工程中的每一个决策，几乎都是一次权衡（tradeoff）。我们很少能在两个选项中，找到一个在所有方面都完胜的。

更多时候，我们是在不同的「工程价值观」之间做取舍。比如，为了极致的性能，我们可能不得不牺牲一部分代码的可读性。

Sean 认为，理解这一点，是衡量一个工程师是否成熟的关键标志。

不成熟的工程师往往是固执的。他们会坚持「永远应该用 X」或者「Y 就是比 X 好」。而成熟的工程师，则愿意倾听和分析每一种选择的利弊，因为他们深知，重要的不是技术 X 是否优于 Y，而是在当前这个特定的场景下，X 的收益是否大于 Y。

换句话说，不成熟的工程师在自己的「品味」上过于僵化。

Sean 认为：一个人的技术品味，由他认为最重要的那一组工程价值观所决定。 他列举了以下几项常见的工程价值观：

1. 韧性 (Resiliency)

当系统某个部分出现故障（例如，一个服务宕机，网络连接中断）时，整个系统是否还能保持基本功能？它能否在无人干预的情况下自动恢复？

典型技术比如微服务架构中的服务熔断、降级、重试机制；跨可用区、跨地域部署；数据备份与恢复策略。

实现高韧性通常意味着系统复杂度的增加。追求极致弹性的工程师，可能会设计出复杂的熔断、降级和重试机制。

2. 性能 (Speed)

这里的性能指软件的运行速度或响应时间。它关注的是代码执行效率，以及在关键路径上是否存在不必要的计算开销。

运行速度的优化涉及到缓存策略、算法优化、底层语言选择、异步处理和并发编程等。

极致的性能优化往往会使代码变得复杂和难以理解，过早优化是万恶之源。追求运行速度的程序员会花费大量时间进行 profiling，甚至会使用一些违反直觉的技巧来压榨性能。

3. 可读性 (Readability)

代码是否易于理解？新工程师上手是否困难？函数是否简短且命名清晰？系统文档是否完善？

追求可读性的工程师，会遵循严格的编码规范，编写大量的注释和文档，推崇「代码即文档」的理念。但有时，为了可读性而进行的过度抽象，反而会隐藏关键的业务逻辑，增加理解成本。

4. 正确性 (Correctness)

系统能否阻止无效状态的出现？代码是否被充分的测试、类型系统和断言所保护？

技术层面涉及到完备的单元测试、集成测试；静态类型系统（如 TypeScript, Rust）；防御性编程；在极端情况下，甚至使用形式化方法如 Alloy 来证明程序的正确性。

追求正确性的工程师，会推崇测试驱动开发 (TDD)，编写覆盖率极高的测试用例，并利用静态类型系统来消除一整类错误。但这会拖慢开发进度。一个简单的功能，可能业务代码只有 50 行，测试代码却有 500 行。

5. 灵活性 (Flexibility)

系统是否易于扩展和修改？当需求变更时，修改的难度有多大？一个改动需要触碰多少个不同的文件或模块？

灵活性涉及到插件化架构；面向接口编程；依赖倒置原则；松耦合的设计。

追求灵活性的工程师，会大量使用设计模式，构建插件式架构，强调模块间的解耦。但过度设计会导致系统变得异常复杂，一个简单的功能需要绕很多层才能实现。

6. 可移植性 (Portability)

系统是否与特定的运行环境（如 Windows 操作系统、AWS 云平台）深度绑定？如果需要迁移到其他环境，工作量有多大？

比如使用跨平台的语言和框架；容器化技术（Docker, Kubernetes）；避免使用特定云厂商的专有服务（Vendor Lock-in）。

追求可移植性的工程师，会倾向于使用容器化技术（如 Docker），避免使用特定云厂商的专有服务。但这也会让他们错失这些专有服务带来的开发效率和性能优势。

7. 可扩展性 (Scalability)

当流量增长 10 倍、100 倍时，系统是否会崩溃？系统是需要预先配置大量资源，还是可以自动伸缩？

比如无状态服务设计；分布式数据库；负载均衡；基于监控指标的自动扩缩容（Auto-scaling）。

追求可扩展性的工程师，会设计无状态服务，使用分布式数据库，并痴迷于系统的水平扩展能力。但这对于一个流量很小、在可预见的未来也不会有大规模增长的应用来说，完全是浪费资源。

8. 开发速度 (Development Speed)

添加一个新功能需要多长时间？是需要领域专家还是普通工程师就能完成？

选择成熟的框架和工具（如 Ruby on Rails, Django）；动态语言（如 Python, Ruby）；完善的脚手架和自动化脚本。

追求开发速度的工程师，可能会选择框架，或者使用低代码平台，甚至在早期阶段牺牲一些代码质量来换取产品快速上线。但这可能会埋下技术债，导致后期维护成本急剧上升。

这些价值观之间常常是相互冲突的。没有哪个工程师会对所有这些价值观给予同等的重视。你的技术品味，就体现在你如何对这些价值观进行排序和取舍。

• • 如果你将「速度」和「正确性」置于「开发速度」之上，你可能会更倾向于 Rust 而不是 Python。
• • 如果你将「可扩展性」置于「可移植性」之上，你可能会选择深度拥抱 AWS 的生态。
• • 如果你将「韧性」置于「速度」之上，你可能会坚持做跨区域部署，哪怕这会增加网络延迟。

这些偏好，共同构成了你的技术品味。

三、如何识别「坏品味」？

读到这里，你可能会问，既然所有价值观都有其合理性，那还存在所谓的「坏品味」吗？

答案是肯定的。

Sean 提出了一个关键的判断标准：坏品味，就是你的价值观偏好与当前项目严重不匹配。

我们身边可能都有这样的同事：他们加入一个项目后，就像传教士一样，热情地推广他们过去项目中成功的经验——可能是形式化方法，可能是重写为 Golang，也可能是 Ruby 的元编程。无论这些技术是否适合当前项目，他们都会极力倡导，因为这是他们所熟悉和喜爱的。

这种行为的根源在于僵化（inflexibility）。

一个有坏品味的工程师，会把个人偏好误认为是普适的工程原则。他们最喜欢说的一句话是：「这才是最佳实践（best practice）」。但事实上，脱离了上下文的「最佳实践」毫无意义。

一个内部使用的、用户量不大的数据看板，有必要追求五个九（99.999%）的可靠性吗？如果为了这个目标，导致系统复杂到只有资深工程师才能维护，初级工程师完全无法参与，这显然就是一个品味很差的决策。

Sean 用了一个非常形象的比喻：有坏品味的工程师就像一块坏掉的指南针。

如果你恰好站在指南针碰巧指向北方的那个位置，它看起来是正常的。但只要你移动位置，它就会立刻把你引向错误的方向。

同样，许多品味差的工程师在特定的领域或项目中可能表现得非常出色，因为他们的个人偏好恰好与项目的需求吻合。但是，一旦他们被调到其他项目，或者项目本身的需求发生了变化，问题就会立刻暴露。

在今天这个快速变化的时代，没有任何一个项目会长期保持不变。僵化的品味，迟早会成为团队的绊脚石。

四、如何培养「好品味」？

与技术能力不同，好品味更难衡量和培养。你无法通过刷 LeetCode 算法题来提升品味，也不能通过考取认证来证明。因为好品味的核心是在真实、复杂的场景下，为特定问题选择正确价值观的能力。

那如何才能培养好的技术品味呢？Sean 的建议可以总结为以下几点：

1. 参与多样化的项目

这是最重要的一点。如果你一直只做同一种类型的项目（比如，一直做企业级后台管理系统），你的价值观体系会变得非常单一。试着去接触不同领域、不同规模、不同生命周期的项目。

• • 参与一个从 0 到 1 的创业项目，你会更深刻地理解「开发速度」的重要性。
• • 维护一个拥有千万级用户的遗留系统，你会明白「可读性」和「韧性」是多么宝贵。
• • 开发一个对性能要求极高的底层库，你会学会如何在「速度」和「正确性」之间进行精细的权衡。

2. 保持好奇心和开放性

不要对任何技术抱有成见。当你看到一个与你习惯相悖的设计时，不要急着否定它，而是去思考：「它为什么要这么设计？它解决了什么问题？它背后遵循了哪些我没有优先考虑的价值观？」

主动去学习你日常工作之外的技术栈。如果你是一个前端开发者，可以去了解一下后端架构；如果你是后端开发者，可以去学习一下 DevOps 和运维。拓宽视野，是打破思维僵局的最好方法。

3. 持续反思和复盘

在每个项目或每个重要功能完成后，花时间去复盘。哪些决策是成功的？哪些是失败的？如果重来一次，你会做出哪些不同的选择？

关注那些让你感到「痛苦」的地方。一个项目让你觉得开发过程很愉快，还是让你觉得步履维艰？痛苦之处，往往是价值观与现实需求不匹配的地方，也是品味提升的最佳契机。

4. 最重要的是：多读、多看、多交流，保持灵活性

多阅读优秀开源项目的源码，看看它们是如何在各种限制条件下做出优雅的权衡。

关注不同公司的技术博客，了解它们的发展历程和技术思考，这比学习单一框架要有价值得多。

多和不同背景的工程师交流，听听他们的思考过程，理解他们为什么会做出那些你不太理解的决策。

努力避免形成关于「如何编写软件」的强烈普适性观点。好的品味不是拥有一套一成不变的黄金法则，而是拥有一个动态的、能适应不同环境的工具箱。

结语

技术日新月异，今天你学会的框架，明天可能就会过时。但「技术品味」是更持久的个人喜好。

换句话说，我们既要思考 How，也要思考 Why，要在日常的编程和设计中，有意识地训练和修炼自己的「代码品味」，而不是只顾着低头看路。

只有这样，才能从码农修炼成架构师，才能在长久的技术生涯中跨越框架更迭的周期。