抖音技术能力大揭密!钜惠大礼、深度体验,尽在火山引擎增长沙龙,就等你来! 立即报名>> 了解详情
写点什么

观点:完美代码只是一个幻想

2017 年 1 月 02 日

引言

完美主义者最大的特点就是过度追求一件事情的完美,他们看什么东西都不会完全满意,因此经常陷入深深的矛盾之中,殊不知这个世界上根本就没有绝对的完美,将精力投注到工作中、生活中各个方面,努力改善,乐此不疲。至于吗?程序员中的完美主义者又会怎样呢?

许多程序员文化是建立在完美代码的理想上:代码不仅能够运行,而且也必定是干净、优雅的。我们以巧妙地构建解决难题的对策为傲。然而这种完美主义可能不利于团队的成功,因为完美主义常常导致个人分歧。

然而能得到所有人公认的完美代码标准并不存在。对于完美代码,每个人都有一个略微不同的审美观点,这意味着我们每个人都有自己的想法:什么样的代码看起来完美。如果我们都是由完美主义来驱动——希望我们的代码看起来像我们想要的样子,那么我们最终会与队友发生分歧,因为我们每个人互相反对,只是为了让代码库看起来像我们所想看到的样子。

伦敦一位资深程序员 Daniel Irvine 就在博客分享了他对完美代码的看法以及对策。

当我成长为一个程序员时,我发现有一些小技巧,可以让团队避免因为追求完美代码而发生冲突。下面就让我们来看一看。

不要被教条束缚

对代码库的唯一要求就是,它是可用的。通过一个简单的方法来验证,如果它经过完全覆盖测试并通过,就可以证明是可用的。除此之外,每个测量都是主观的。

当你阅读其他人的代码,不要去想如果是你写的话会怎样。不要试图在你脑海中重写这段代码,让它存在就是它的方式。

减少你对代码设立的标准

用制表定位键(Tab)还是空格键(Space)?两个还是四个空格?为你的左括号设置同一行呢,还是另起一行呢?我不知道如果只有一个单一的编程语言的话,是不是就不会有这种争论?解决这个问题的标准方法就是使用书面编码标准,这会为团队的代码带来一致性。

不幸的是,很难形成完整的编码标准。总是会有灰色区域导致了潜在的分歧,如命名、模式、对象建模技术等。

而且,他们团队定下的规则有时会引火烧身。

我曾经所在的团队,对编码标准有过如下规则:“任何函数不得超过7 行代码”。事后看来,这个规则,还不如没有。虽然我仍然赞同这个观点,但这一规则还是激起了很多混乱和争辩。团队成员在编码的时候不能全心投入,因为需要总是想着这个规则。还有人则走向另一个极端,永远拒绝接受它。总之,我们团队花了大量时间和精力,来保持遵守这个规则。

试想,那些时间如果用来结对编程或是一起改进代码该有多好。所有的规则都有一定的代价,并且,尽管规定事无巨细,团队成员们仍然可能在其它事情上存在分歧。

虽然我仍然尽量保持编写简短的函数和方法——通常少于七行——但我不会让它们成为必须遵守的规则。

让代码库成为自己的标准,而不是写出什么规则。

不要被Pull Request 套牢

我通常会迅速合并Pull Request(略:PR),即使它对代码有很大的改动。这样做有两个原因。第一是等待PR 修改可能阻塞其它同伴的工作流。第二点更微妙,基本代码保持可延展性是非常重要的:这意味着,要时刻准备接受修改。“完美PR”文化阻碍了这一点。它促进了代码在主分支是“黄金”,并不应该再次改变的概念。如果我们转而允许不完美代码进入主分支,那我们会鼓励更高的变化率。团队成员会学会问自己:“我看的代码足够干净吗?”

这有点违背直觉:允许主分支写入不完美代码可以提升项目质量。

那么,审查PR 的更好的方法是什么?

我的策略是这样的。我首先通读整套变更,标注任何可能重要的事情。然后优先给出反馈,最多给三条修改建议给出意见。其它的就不管了。

我很少就编码风格问题进行评论,比如多出的空格,或者没有很好缩进的参数列表。如果代码是可延展的,有人可能在以后会清理它。同时,这些风格问题并不会妨碍程序的运行。

放眼望世界

对于任何多于几十行的代码,是否能称之为完美,取决于观看者的主观印象。如果你期望每个人以完全相同的方式解决问题,那么你就错了。如果你对代码应该是什么样有很高的标准,那么你将会感到失望。

为你的队友提供空间,让他们能按自己的心意设计和编码,并鼓励每个人在系统设计时平等的发挥作用。

当你的团队写出的代码与你想要的不一样时,不要与他们争论。要记住,在团队中保持健康工作关系,长远来看是有价值的。所以也许你要牺牲你个人对质量的愿景。

我鼓励程序员每天花一些时间,回顾并反思自己的开发技术的发展。思考自己和团队每天的效率如何。这个月管用的下个月不一定行得通。特别在团队成员的技能从新手到专家成长的过程中,这一点尤为显著,这一点尤为如此。所以,尽量找出并改掉你身上那些开始给你带来更多伤害,而不是更多帮助的习惯吧。


感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017 年 1 月 02 日 16:001391
用户头像

发布了 339 篇内容, 共 130.6 次阅读, 收获喜欢 856 次。

关注

评论

发布
暂无评论
发现更多内容

架构实战训练营 - 模块四课后作业

Johnny

架构实战营

DDD这样落地

码农戏码

DDD

Netty引导器Bootstrap学习笔记

风翱

Netty 5月日更

实时音视频通讯过程中声音的那些事儿

liuzhen007

音视频 5月日更

测试开发需要掌握哪些技术?

夏兮。

方法论 测试 CI/CD automation 语言 & 开发

从 Netflix 到 Alibaba,Spring Cloud 更好了吗?

博文视点Broadview

面试被问 Spring cloud 上下文,可以这样回答

Damon

spring SpringCloud 5月日更

这5个浏览器工具,让你的上网舒适度提升150%

彭宏豪95

效率 工具 浏览器 脚本 5月日更

MySQL数据库学习笔记(1)

lenka

5月日更

(深入篇)漫游语音识别技术—带你走进语音识别技术的世界

攻城先森

深度学习 音视频 语音识别 5月日更

项目管理学习到的教训

胡迪伦

项目管理

带你认识时域、频域与Android系统Visualizer

Changing Lin

音视频 5月日更

🚀【高并发技术专题】你需要了解的秒杀方案

李浩宇/Alex

高并发系统设计 高并发优化 5月日更

学习笔记之:孩子学习老是跑?日更好“难”

Nydia

学习笔记

Redis - 列表

旺仔大菜包

redis

架构实战营 - 模块 4- 作业

请弄脏我的身体

架构实战营

架构实战营 - 模块 4- 作业

泄矢的呼啦圈

架构实战营

【LeetCode】罗马数字转整数Java题解

HQ数字卡

算法 LeetCode 5月日更

Android 音视频采集那些事

LoveYFan

音视频

没有发生GC也进入了安全点?这段关于安全点的JVM源码有点意思!

CoderW

Java 源码分析 JVM GC

谈一谈“数字资产”

小天同学

思考 数字时代 5月日更 数字文物 数字内容

领域驱动设计101 - 实体

luojiahu

领域驱动设计 DDD

线性表,栈,队列,数组草图

Arvin

实时语音如何过质量关?

cv君

深度学习 AI 算法 质量 语音

什么是线程安全?一文带你深入理解

程序猿阿星

线程安全 信号量 线程同步 互斥锁

架构训练营模块4作业

Geek_649372

架构训练营

后悔:要是当初那样就好了

石云升

思维方式 5月日更 后悔 人生选择

Golang 程序实体

escray

go 极客时间 学习笔记 5月日更 Go语言核心36讲

《01|导读:背景知识对于理解文章究竟有多重要?》内容复习

IT蜗壳-Tango

5月日更

前端开发:Mac电脑安装NVM报错:curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused

三掌柜

5月日更

ES_her0

5月日更

Study Go: From Zero to Hero

Study Go: From Zero to Hero

观点:完美代码只是一个幻想-InfoQ