代码简洁性之道:软件设计原则与开发体验优化

本文探讨代码简洁性的核心原则,分享Google在开发者体验方面的实践经验,分析代码质量评估的主观性特征,并讨论现代LLM在代码质量判断上的局限性,为构建高质量软件系统提供深刻见解。

代码简洁性第二版发布

2012年8月22日 作者:Max Kanat-Alexander

六月,我发布了《代码简洁性》的第二版修订。有些人可能已经知道,但我觉得应该让其他人都了解这个信息。

最重要的变化是,本书现在能更快地深入软件设计的法则和规则。它以完全重写的前言开始,讲述了我如何开发《代码简洁性》中的原则,以及为什么您可能对这些原则感兴趣。然后是更短的第一章,将旧版第一章的所有内容浓缩到几页中,跳过了旧的第二章(关于某物成为科学的漫长讨论),直接进入法则部分。

特别是如果您读过原始版本,我非常希望听到您对新修订版起始内容的反馈!

-Max

附言:如果您从O’Reilly购买了电子书,您可以免费获得每个新修订版,而且可能还会有比这个更多的修订!如果您从其他地方获得了电子书,书内有一个小链接可以让您以相当便宜的价格"升级"到O’Reilly版本,这样您也可以免费获得这个修订版和所有未来的修订版。我对您获取书籍的任何特定方法都没有偏见,但O’Reilly版本绝对是获取新修订版的最佳方式。

代码复杂度的主观本质

我几乎每周都参加Google代码健康小组的周会,从2011年一直到2015年左右我们停止定期周会。这是一个非常棒的会议,有一个核心小组几乎总是参加,加上每周一些想要在代码质量、测试或重构方面获得帮助的临时参与者。

大多数时候,会议作为关心代码质量并希望在自己领域采取行动的人的支持小组运作。他们会来抱怨他们如何关心但难以让别人关心。我们会支持他们,说我们真的很关心,他们应该继续努力,然后他们会回到自己的领域做出伟大的事情。实际上,令人惊讶的是,该会议的许多参与者后来成为了Google最资深的技术负责人。

然而,几乎每周都会有人来问我们同样的问题:“我如何客观地测量代码复杂度?“周复一周,我们会给他们同样的答案:“没有办法做到,请不要这样做。”

这个小组的负责人代表了代码质量和重构领域一些世界上最有经验的工程师,随着时间的推移,我们都得出了相同的结论:代码复杂度测量不起作用。所有尝试创建量化指标(圈复杂度、统计静态分析失败、确定内聚和耦合的算法)都失败了——它们引导团队走上错误的道路,并没有解决真正阻碍开发者的重要问题。

最终,我明白了为什么这些指标不起作用,而且永远不会起作用。因为代码"简单"的定义是:易于阅读、理解和正确修改。“阅读"和"理解"在那里本质上是主观的。只有人类能告诉你某物是否易于阅读。

LLM在代码质量判断上的局限性

有些人希望现代LLM能在这方面提供帮助。当我看到时我愿意相信,但现在这实际上是所有模型都持续表现糟糕的领域:告诉你是否产生了高质量的输出。它们在发现特定问题并以代码审查形式提供具体指导方面表现不错。但它们完全缺乏经验丰富的软件工程师在构建真正简单软件系统方面的判断力。无论你如何告诉它们"要简单"或"编写好代码”,它们就是无法做到。

所以这仍然是事实:代码质量本质上是主观的,如果你想理解它,你需要关于它的主观数据。这是我见过唯一有效的东西。

Google优秀开发者体验的秘诀

Google为什么有如此出色的开发者体验?它只是在这方面花了比任何人都多的钱吗?

嗯,是的,如果你把花在Google基础设施上的所有人力成本加起来,Google可能在开发者体验上花的钱比任何人都多。但这实际上不是Google在这方面成功的核心原因,因为Google开发者体验的早期并没有涉及大量工程师。它实际上涉及相对较少的有能力的工程师,他们随着时间的推移相当缓慢地构建工具。Google一些最受喜爱的工具最初总共只有三四人构建。

关键是这些工程师被允许专注于开发者基础设施的基础工作,无论需要多长时间才能做好。每个人都在朝着开发者体验的长期全局最大值构建,而不是短期即时需求。非常好的工程师被赋予自由去问诸如"完美的构建工具应该是什么样子"这样的问题,然后尝试构建它。源代码控制、代码审查、编程语言基础设施、CI、IDE、常用库以及开发者体验的许多其他部分也是如此。当然,有时我们在过程中构建了糟糕的东西,但公司足够关心做好它,以至于我们(通常)会回去修复它,最终。

Google开发者体验和速度的关键是对软件工程基础的这种关注。这也不仅仅是在开发者工具团队中,而是贯穿整个公司——Google的工程师比我在任何其他地方见过的都更关心代码质量、测试等。

软件工程基础的重要性

行业中其他地方的技术领导者最常犯的错误之一是没有关注所有这些工程基础。代码库可维护吗?您是否有需要高效构建可靠、高质量软件的基本工具?是否有系统确保新软件工程师能够快速上手项目,并随着时间的推移提高他们的技能?等等。

相反,我经常看到领导者坚持在破碎的基础上紧急解决即时问题,没有任何真正在未来解决这些基础的计划。这有点像酒店建造者看到所有其他酒店都有很棒的顶层套房,然后坚持团队建造美丽的顶层套房,而建筑却有裂缝的地基和漏水的管道。修复那个地基可能很困难,但如果你不修复,你肯定会后悔。

基础有时感觉抽象或不重要,因为它们不是您被要求交付的即时产品。但让我告诉您,如果您想能够交付任何东西,基础才是最重要的。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计