完美的代码是一种错觉

2016-12-16   出处:https://8thlight.com  作/译者:Daniel Irvine /亚然  

大多数程序员文化都是建立在完美代码的理想基础上的:代码,不仅是可工作的,还是干净和优雅的。我们自豪于构建巧妙办法来解决疑难的问题。但是,这种完美主义可能会不利于团队的成功,因为完美主义往往会导致个人的分歧。

在全球范围内没有公认什么才是完美的理想的代码。每个人都对代码有一个不同的审美,我们每个人对此都有自己的想法。如果我们都是完美主义者,欲望会驱使着我们让代码看起来是我们所希望的那样,那么我们最终会与我们的队友陷入分歧。我们将会彼此互相抗争让代码变成我们各自想要的样子。

作为一个经验丰富的程序员,我发现避免团队冲突的一个有效的办法是停止对完美代码的关注。下面是一些例子,讲述如何将这个概念应用到你自己的工作中。

不要被教条束缚

对代码的唯一的要求就是它的运行。一个简单的验证就是,如果它能完全的测试覆盖,那么这些测试就是通过的。除了这一点,每一种质量上的测量都是主观的。

当你阅读别人的代码时,尽量不要去想你喜欢的代码是什么样子的。尽量不要在你的脑海中进行重写。就让它以它的方式存在。

精简你的编码标准短或完全抛弃标准

制表符还是空格?两个空格还是四个空格?同一行还是新的行要大括号?我不知道一个单一的编程语言,是不受这种类型的辩论的。打击这一标准的方法是使用书面编码标准。这给我们的代码带来一致性。

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

定下的规则有时会让我们作茧自缚。

在我曾经工作过的一个团队中,它的编码标准中有以下规则:“任何函数都不应该超过7行代码”,在事后看来,如果没有这个规则,我们的团队会变得更好。尽管我仍然同意这种观点,这一规则引起了很多混乱和争议。这一条规则引起了大量的请求修改的评论,人们需要不断的提醒,一些团队队从来没有相信它。总的来说,我们花了大量的时间和精力维护这一规则。

那时候可能是更多的是请求配对并一起改善代码。维护每一个规则都要有一个代价,并且你可能对这些规则仍然有分歧。

虽然我还有写短的方法,通常不超过七行。让代码有自己的标准,而不是写出规则来。不要让硬性要求束缚自己。

通常,即使有明显的改进,我也会合并请求作出代码。我这样做有两个原因。第一个是等待修正可以阻止其他团队成员。第二个是更微妙的。重要的是,一个代码库应该始终保持可延展性:有意义,准备和期待改变。“完美的代码请求”阻碍了这一点。它促进了在主分支代码是“黄金”的概念,应该不再改变。如果我们允许不完美的代码转化为主,我们鼓励更高的变化率。团队里将总是问这个问题“我看的代码是干净的吗?“

这有点反直观,以不完美的代码为主实际上可以使提高质量。

因此,有什么更好的方法来审查需求呢?

我的策略是,首先了解整组变化,记下任何可能很重要的东西。然后我会优先考虑我的反馈意见,并限制我的意见为至多三个。剩下的一切都是单独留下的。

 我最不可能评论的问题就是,像错位的空白或不缩进参数列表的风格问题。如果代码是可锻造的,有人很可能在未来的一些时间来清理代码。同时,这些风格的问题不会伤害任何人。

扩大视野

对于任何超过几十行代码,完美都是在旁观者的眼睛里的。如果你希望每个人都以同样的方式解决问题,那么你就错了。如果你对所写的代码应该是什么样的有个美好的愿景,那么你会失望的。

给你的队友空间来设计他们觉得合适的代码。鼓励每个人在设计中都是平等的。  

当你的队友写的代码看起来不同于你想要的东西时,不要和他们争论。记住,在你的团队中长期保持健康的工作关系是有价值的。因此,也许牺牲你的个人视野是可以的。

我劝你每天多花一些时间来反思你的开发技术。想想如何更有效的为自己和为团队服务。这个月的工作可能下个月不会再做了。这是从新手到专家特别真实的团队成长技能,所以,一定要不断寻找你的过程中一开始伤害比他们帮助更多的部分。



【英文原文:https://8thlight.com/blog/daniel-irvine/2016/11/11/perfect-code-is-an-illusion.html】

{测试窝原创译文,译者:亚然}

译者简介:亚然,软件测试爱好者,长期从事软件测试工作




欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
158°|1582 人阅读|0 条评论

登录 后发表评论