本文永久链接 – https://tonybai.com/2025/09/30/good-taste-in-software-engineering

大家好，我是Tony Bai。

在软件工程领域，我们习惯于用“技术能力”（Technical Skill）来衡量一位工程师的优劣。他是否精通并发模型？能否写出高性能的代码？对底层原理的理解有多深？这些能力可以通过学习和重复练习来获得，是我们评价体系中的“硬通货”。

然而，github工程师Sean Goedecke在他最新的博文中，提出了一个新的观点：决定工程师成长上限的是“技术品味”（Technical Taste）。他认为，“品味”与“能力”是两个正交的维度。你可以技术能力很强，但品味很差；也可以技术尚在发展，但已具备良好的品味。就像一个美食家，即使自己不会烹饪，也能分辨出食物的好坏。同样，一个有品味的工程师，在能亲手构建一个复杂系统之前，就已经知道自己喜欢什么样的软件。在文章中，他还特意以Go的一些语法特性举例，来诠释什么是工程品味。

在这篇文章中，我们将一起拆解“技术品味”这个看似玄妙的概念，学习如何识别自己和他人身上的“坏品味”（比如对“最佳实践”的盲从），并探索一条培养“好品味”的实践路径，帮助我们Go开发者在日常的权衡与决策中，做出更成熟的选择。

“品味”不是“对错”，而是“价值观”的排序

文章以一个经典的例子开场：for循环 vs. map/filter。

许多来自函数式编程背景的开发者会认为，使用map/filter的代码“看起来更美”，因为它们通常涉及纯函数，易于推理，还能避免一类的迭代器bug。这似乎是一个关乎“正确”与“错误”的技术问题。

然而，Go语言的设计者们，出于“有原则的理由”，并没有在语言核心中原生内置map/filter。在Go中，一个简单的for循环：

• 性能上更易于推理：没有高阶函数调用的开销。
• 更灵活：可以轻松扩展到更复杂的迭代策略（如一次处理两个或多个元素）。

这个分歧的本质是什么？Goedecke一针见血地指出：这不是一个关于技术能力高低的争论，而是一个关于“工程价值观”（Engineering Values）优先级排序的差异。

• 偏爱map/filter的工程师，可能将“表达力”和“数学上的优雅”排在了更高的位置。
• 偏爱for循环的Go语言设计者们，则将“性能透明度”和“实现的直接性”置于首位。

成熟的工程师，能够理解并承认这种差异源于价值观的不同，而非技能的缺失。

什么是工程中的“好品味”？

几乎所有软件工程决策都是一次权衡（tradeoff）。

你很少能在两个选项中找到一个绝对更优的。你总是在不同的工程价值观之间做艰难的取舍，比如在“性能”和“可读性”之间，或者在“开发速度”和“正确性”之间。

不成熟的工程师会固执己见，认为“X永远比Y好”。而成熟的工程师则会评估双方的优劣，并思考：“在当前这个特定的项目中，X的收益是否大于Y的收益？”

因此，Goedecke对“技术品味”给出了一个精辟的定义：

Taste is the ability to adopt the set of engineering values that fit your current project.
(品味，是为当前项目选择一套恰如其分的工程价值观的能力。)

你的个人技术偏好，构成了你的基础“品味”。而“好品味”，则是在这个基础上，根据项目所处的真实环境（团队能力、业务阶段、性能要求、交付压力等），灵活调整你的价值观优先级的能力。

如何识别“坏品味”？—— “最佳实践”的诅咒

“坏品味”最常见的表现形式，就是僵化（inflexibility）。

I will always distrust engineers who justify decisions by saying “it’s best practice”.
(我永远不信任那些用“这是最佳实践”来为决策辩护的工程师。)

没有任何工程决策是在所有情境下的“最佳实践”。

当你听到有人用这个词时，往往意味着他正在将过去某个项目的成功经验（那套当时恰好适用的价值观），僵化地、不加思考地套用到一个全新的问题上。

• 一个在金融科技公司追求“五个九”可用性的工程师，如果将同样的价值观带到一个需要快速迭代验证想法的初创公司，坚持为内部仪表盘构建跨区域部署，那就是“坏品味”。这会让项目变得复杂无比，难以理解，拖慢了产品发布的速度，甚至导致了失去市场的机会。
• 一个习惯于用Ruby元编程“炫技”的开发者，如果在一个追求长期可维护性的Go项目中，滥用reflect来实现类似的动态能力，那也是“坏品味”。

Goedecke用了一个绝妙的比喻：品味差的工程师就像一块坏掉的指南针。在一块特定的磁场里（比如他之前工作的领域），这块坏指南针可能恰好能指向北方，让他看起来非常高效。但一旦环境变化（换了项目或公司），这块指南针就会立刻将团队引向错误的方向。

如何培养“好品味”？—— 拥抱灵活性与真实世界

培养技术能力有明确的路径：读书、练习、看代码。而培养“技术品味”则更为神秘。Goedecke给出的建议是：

1. 涉猎多样化的项目：在不同类型、不同阶段、不同需求的项目中工作。密切关注在这些项目中，哪些部分做起来很“容易”，哪些又异常“艰难”。
2. 聚焦于灵活性：刻意避免形成关于“编写软件的唯一正确方式”的强烈、普适性的观点。始终保持开放，愿意倾听和理解那些与你价值观相悖的观点。
3. 拥抱真实世界的混乱：“好品味”无法在玩具问题或技术问答中得到检验。你必须投身于一个真实的、充满了各种混乱约束的实际问题中，才能锻炼你在多重约束下做出最佳权衡的能力。

小结：从理解“品味”，到成为更好的Gopher

综上所述，Sean Goedecke为我们揭示了一个深刻的层次：“技术品味”是超越“技术能力”的、衡量工程师成熟度的关键标尺。 文章的核心不在于掌握多少工具，而在于面对具体问题时，能否为之匹配一套恰如其分的工程价值观。这正是成熟与僵化、权衡与教条、情境与普适之间的分水岭。一个工程师的成长上限，或许就取决于他/她能否从固守个人偏好，进化到为项目选择最佳价值排序的“好品味”阶段。

这套关于“品味”的哲学，在Go的语境中显得尤为贴切，甚至可以说，它完美地解释了Go语言及其社区文化的形成。

Go语言本身，就是其设计者们“好品味”的结晶。他们没有盲目追随当时其他语言的风潮，而是为“构建大型、可维护的网络服务”这一特定问题，选择了一套恰如其分的工程价值观——将简单性、可读性和性能透明度置于极高的优先级。

这门语言的设计，反过来也在塑造着我们的“品味”。它通过“做减法”，有意地减少了语言的“魔法”，迫使开发者回归到问题的本质，进行更多的第一性原理思考，而不是依赖于复杂的框架或语法糖。在Go社区所推崇的“务实主义”、“显式优于隐式”，以及对“最佳实践”的天然警惕，本质上都是一种对情境化“好品味”的追求。

只有理解了为什么Go是现在这个样子，我们才能在使用这门语言时，做出同样充满“品味”的、与项目需求相匹配的决策，从而真正发挥出Go语言的全部威力，成为一名真正成熟的软件工程师。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/04/21/go-project-design-antipatterns

大家好，我是Tony Bai。

在软件开发这个行当里，“最佳实践”、“设计模式”、“标准规范”这些词汇总是自带光环。它们总是承诺会带来更好的代码质量、可维护性和扩展性。然而，当这些“圣经”般的原则被生搬硬套到Go语言的语境下时，有时非但不能带来预期的好处，反而可能把我们引入“歧途”，滋生出一些看似“专业”实则有害的“反模式”。

最近我也拜读了几篇国外开发者关于Go项目布局和设计哲学的文章，结合我自己这些年的实践和观察，我愈发觉得，Go社区中确实存在一些需要警惕的、流行的设计“反模式”。这些“反模式”很多人都或多或少的使用过，包括曾经的我自己。

在这篇文章中，我就总结一下我眼中的Go项目设计“七宗罪”，希望能帮助大家在实践中保持清醒，做出更符合Go精神的决策。

第一宗罪：为了结构而结构——过度分层与分组

表现： 项目伊始，不假思索地创建pkg/、internal/、cmd/、util/、model/、handler/、service/ 等层层嵌套的目录，美其名曰“组织清晰”、“符合标准”。

危害：
* 违背简洁： Go 的核心哲学是简洁。不必要的目录层级增加了认知负担和导航成本。
* 过早抽象/耦合： 在需求尚不明确时就划分 service、handler 等，可能导致错误的抽象边界和不必要的耦合。
* pkg/ 的迷思： pkg/ 是一个过时的、缺乏语义的约定，Go官方在Go 1.4时将Go项目中的pkg层次去掉了，Go官方的module布局指南中也使用了更多有意义的名字代替了pkg。
* internal/ 的滥用： 它是 Go 工具链的一个特性，用于保护内部实现不被外部导入。但如果你的项目根本不作为库被外部依赖，或者需要保护的代码很少，强制使用 internal/ 只会徒增复杂性。
* cmd/ 的误用： 除非你的仓库包含多个独立的可执行文件，否则将单一的main.go放入cmd/毫无必要。

解药： 保持扁平！从根目录开始，根据实际的功能或领域需要创建有意义的包。让结构随着项目的增长有机演化，而不是一开始就套用模板。

注：笔者当年也是pkg的“忠实粉丝”，新创建一个项目，无论规模大小，总喜欢先将pkg目录预创建出来。现在是时候根据项目的演进和规模的增长来判断是否需要”pkg”这个有点像“namespace”的目录了，即当你有多个希望公开的库时，是否用pkg/作为一个顶层分组，这个是要基于项目的实际情况进行判断的。

第二宗罪：无效的“美化运动”——无价值的重构与移动

表现： 为了让代码看起来“更干净”、“更符合某种设计模式”或“消除Linter警告”，在没有明确收益（修复 Bug、增加功能、提升性能、解决安全问题）的情况下，大规模地移动代码、修改变量名、调整文件结构。

危害：
* 浪费时间精力： 投入大量时间做无意义的表面文章。
* 引入风险： 任何修改都有引入新 Bug 的风险，没有价值的修改更是得不偿失。
* 增加 Code Review 负担： 团队成员需要花费时间理解这些非功能性的变更。
* 违背价值驱动： 软件工程的核心是交付价值，而不是追求代码的“艺术感”。

解药： 坚持价值驱动的变更！在做任何结构或代码调整前，严格拷问自己：这个改动解决了什么真实的、当前存在的问题？它的收益是否能明确衡量并大于风险？

第三宗罪：接口的“原罪”——过早、过度的抽象

表现：
* 在只有一个具体实现的情况下，就为其定义接口。
* 定义庞大、臃肿的接口，包含过多方法。
* 为了“可测试性”而无脑地给所有东西加上接口。

危害：
* 不必要的抽象： 接口是为了解耦和多态。在不需要这些时引入接口，只会增加代码量和理解成本。
* 弱化抽象能力： “接口越大，抽象越弱”（来自Go谚语）。大接口难以实现和维护，它变得模糊，难以理解哪些方法是真正必要的，也失去了其作为“契约”的精准性。
* 阻碍演化： 过早定义接口可能锁定不成熟的设计，后续修改成本更高。
* 测试的借口： Go拥有强大的测试工具（如表驱动测试），很多时候并不需要接口来实现可测试性。为测试而引入的接口可能扭曲生产代码的设计。

解药：
* 拥抱具体： 先写具体实现。
* 发现接口，而非设计接口： 只有当你确实需要多种实现（包括测试中的Mock，但要谨慎对待），或者需要打破循环依赖时，才考虑提取接口。
* 保持接口小巧、正交： 遵循接口隔离原则。

第四宗罪：“大杂烩”的诱惑——utils/common/shared 黑洞

表现： 创建一个名为 utils、common、shared 或 helpers 的包，把各种看似“通用”的函数、类型塞进去。

危害：
* 职责不清： 这些包缺乏明确的领域或功能归属，成为代码的“垃圾抽屉”。
* 依赖洼地： 随着项目增长，这些包往往会依赖越来越多的其他包，同时也被越来越多的包依赖，极易引发循环依赖或成为构建瓶颈。
* 降低内聚性： 本应属于特定领域的功能被剥离出来，破坏了原有包的内聚性。

解药：
* 就近原则： 如果一个“工具函数”只被一个包使用，就把它放在那个包里（可以是私有的）。
* 功能归类： 如果一个“工具函数”被多个包使用，思考它真正属于哪个功能领域，为其创建一个有意义的新包（例如 applog 而不是 logutil）。
* 思考依赖方向： 真正通用的基础库（如自定义的 string 处理、时间处理）应该处于依赖关系图的底层，不应依赖上层业务逻辑。

注：坦白说，其他几项“罪过”或许还只是部分开发者的“偶发行为”，但这“第四宗罪”——随手创建 utils 或 common 包——恐怕是我们绝大多数人都曾犯过，甚至习以为常的“通病”。笔者也是如此:)。

第五宗罪：对 DRY 的“迷信”——为了“不重复”而引入不当依赖

表现： 为了避免几行相似代码的重复，强行提取公共函数或类型，并为此引入新的包依赖，有时甚至导致复杂的依赖关系或循环依赖。

危害：
* 错误的抽象： 有时看似重复的代码，在不同的上下文中可能有细微的差别或独立演化的需求。强行合并可能导致错误的抽象。
* 不必要的耦合： 为了共享几行代码而引入整个包的依赖，增加了耦合度，可能比少量重复代码的维护成本更高。
* 违背 Go 谚语： “A little copying is better than a little dependency.”（一点复制代码胜过一点点依赖）。Go 社区鼓励在权衡后接受适度的代码重复，以换取更低的耦合度和更高的独立性。

解药：
* 批判性看待重复： 看到重复代码时，先思考它们是否真的是“同一件事”？它们的演化趋势是否一致？
* 权衡成本： 引入依赖的成本（耦合、潜在冲突、维护负担）是否真的低于复制代码的成本？
* 优先考虑简单： 在不确定时，保持简单，适度复制代码通常更安全。

注：这种事儿，恐怕咱们自己或者团队里都遇到过不少：就为了用里面那一两个小函数，咔嚓一下，引入了一个庞大无比的依赖库。

第六宗罪：盲目崇拜与跟风——“伪标准”与“最佳实践”的陷阱

表现：
* 不加批判地复制某个“明星项目”或所谓的“Go 标准项目布局”（如已被社区诟病的golang-standards/project-layout）。
* 将其他语言（如 Java, C#）的复杂模式生搬硬套到 Go 项目中。
* 将任何 Linter 规则或所谓的“最佳实践”奉为圭臬，不考虑具体场景。

危害：
* 脱离实际： 别人的“最佳实践”是基于他们的特定问题和上下文演化而来的，未必适合你的项目。
* 扼杀思考： 放弃了基于自己项目需求进行独立思考和决策的机会。
* 违背Go文化： Go 推崇实用主义和具体问题具体分析，而非僵化的教条。

解药：
* 保持独立思考： 理解每个模式或实践要解决的原始问题是什么，它是否在你的项目中真实存在？
* 以我为主，兼收并蓄： 学习和借鉴，但最终决策要基于你自己的项目需求、团队情况和对 Go 语言的理解。
* 质疑“最佳”： 没有万能的“最佳实践”，只有在特定上下文中的“较好实践”。

注：确实，很多Go初学者（甚至一些老手，包括我自己）都曾长期困惑甚至“抱怨”：官方为何不给出一个项目布局的指导呢？这个呼声持续多年后，Go官方终于在2023年发布了一份官方布局指南。这份指南无疑是我们理解官方思路、开始设计Go项目布局的一个重要起点。

第七宗罪：与“引力”对抗——忽视 Go 的依赖约束

表现：
* 设计出隐含循环依赖的架构（例如，某些复杂的 ORM 模式，或者 Service 层与 Repository 层相互调用具体类型）。
* 当遇到 import cycle not allowed 错误时，不从根本上调整结构，而是通过滥用接口、全局变量或 init() 函数等“技巧”来绕过编译错误。

危害：
* 与语言对抗： Go禁止循环依赖是其核心设计之一，旨在强制形成清晰的、可管理的依赖关系图 (DAG)。试图绕过它，本质上是在与语言的设计哲学对抗。
* 隐藏的复杂性： 用“技巧”解决循环依赖，只是将问题扫到地毯下，使得真实的依赖关系变得模糊不清，增加了维护难度。
* 错失优化机会： 循环依赖往往是代码职责不清、耦合过度的信号。解决循环依赖的过程，本身就是一次优化架构、厘清职责的好机会。

解药：
* 拥抱 DAG： 理解并尊重 Go 的依赖规则，将其视为架构设计的“向导”。
* 分析依赖： 当出现循环依赖时，深入分析其根源，理解是哪个环节的职责划分或耦合出了问题。
* 结构性解决： 优先使用移动代码、提取新包（向上或向下）等结构性方法来打破循环。接口解耦是可用手段，但不应是首选或唯一手段。

小结：回归常识，拥抱简洁

Go语言的设计哲学是务实和简洁。许多所谓的“最佳实践”和“复杂模式”，在Go的世界里可能水土不服。识别并避免上述这些“反模式”，需要我们：

• 保持批判性思维： 不盲从，不跟风，时刻追问“为什么”。
• 坚持价值驱动： 让每一个设计决策都服务于解决真实问题。
• 深刻理解Go： 尊重其核心约束（如无循环依赖），发挥其优势（如简洁性）。
• 拥抱演化： 从简单开始，让架构随着需求的明确而有机生长。

希望这篇“七宗罪”的总结能给大家带来一些警示和启发。你是否也曾在项目中遇到过这些“反模式”？你认为还有哪些Go设计中需要警惕的“坑”？欢迎在评论区分享你的看法和经验！

也别忘了点个【赞】和【在看】，让更多Gopher看到这篇“反模式”的总结！

避开这些设计“反模式”是迈向Go高手的关键一步。如果你渴望更深层次地理解Go语言精髓，与顶尖Gopher交流切磋，并紧跟Go+AI前沿动态…

那么，我的 「Go & AI 精进营」知识星球 正是你需要的！在这里，你可以沉浸式学习【Go原理/进阶/避坑】等独家深度专栏，随时向我提问获
得解析，并与高活跃社区成员碰撞思想火花。

扫码加入，开启你的Go深度学习与精进之旅！