从Dash iOS开源说起,不要过于追求完美代码

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

  

(Dash iOS源码截图)

前段时间知名的苹果平台文档工具Dash作者开源了它的iOS版本,这是Dash被突然从App Store下架,双方扯皮,直到现在的后续结果。对于这件事情我们不多做评价,不过开源是人们乐于见到的。Dash iOS版本开源后,获得了一些开发者的赞美,但没想到的是,它的代码引起了一些争议。

 

 

在以往开发者的印象里,开源意味着展示自己,意味着对代码有追求,Dash可以说粉碎了这个看法。但就像图拉鼎所说,代码写得如何,并不妨碍它在商业上的成功。

你对追求***代码有什么看法呢?

我们找到伦敦一位资深程序员Daniel Irvine分享的文章,他认为不应该追求***代码。

引言

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

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

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

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

不要被教条束缚

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

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

减少你对代码设立的标准

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

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

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

我曾经所在的团队,对编码标准有过如下规则:“功能不得超过7行代码”。事后看来,这个规则,还不如没有。虽然我仍然赞同这个观点,但这一规则还是激起了很多混乱和争辩。人们需要不断地想着它。团队里的一些人从不相信这个规则。总之,我们团队花了大量时间和精力,来维持这个规则。

你想想啊,那些时间如果用来结对编程或是一起改进代码该是多好啊。所有的规则都有一定的代价,尽管有了这些规则,你可能仍然会有意见分歧。

虽然我仍然按照简短代码的规则来写代码——通常少于七行——但我不屑于依照这些规则来写代码。

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

不要被pull请求套牢

我通常会迅速合并pull请求,即使它对代码有很大的改动。这样做有两个原因。***是等待PR修改十分煎熬,会打消团队成员的积极性。第二点更微妙,基本代码保持可延展性是非常重要的:意义、准备和期待去改变。但是,“***pull需求”文化阻碍了这一点。它促进了代码在主分支是“黄金”,并不应该再次改变的概念。如果我们允许不***代码成为主干,那我们会鼓励更高的变化率。团队学会总是提出:“我看的代码足够干净吗?”

这有点违背直觉:允许主程序写入不***的代码。实际上,它可以提升程序的质量。

那么,审查pull请求的更好的方法是什么?

我的策略是这样的。我会首先通读整套变更,标注任何可能重要的事情。然后优先排列他的反馈,限制最多三条建议。其它的就不管了。

我很少就风格问题进行评论,比如放错的空格或缩进参数列表。如果代码是可延展的,有人可能在以后会清理它。同时,这些风格问题并不会给任何人带来伤害。

放眼望世界

对于任何多于几十行的代码,***只是旁观者的感觉。如果你期望每个人以完全相同的方式解决问题,那么你就犯了错误。如果你对代码有着宏伟的愿景,那么你将会感到失望。

为你的队友提供他们认可的设计和代码的空间,并鼓励每个人在系统设计时平等的发挥作用。

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

程序员应该每天花一些时间,回顾并反思自己的开发技术的发展。为自己和团队,思考每天的效率。这个月的工作可能下个月不再做。团队技能的增长是从新手到专家,这一点尤为如此。所以,要确保你少走弯路,因为最初的弯路要比他人提供的帮助都多。

责任编辑:庞桂玉 来源: 移动开发前线
相关推荐

2009-12-04 09:41:22

Linux桌面Linux

2017-09-25 21:00:44

代码开发完美

2019-04-15 13:18:38

开源AWS云供应商

2009-07-17 16:38:40

2010-09-16 10:46:47

2017-09-08 11:52:00

ThinkSystem

2015-01-20 11:30:48

完美代码代码

2009-11-25 17:09:58

无线路由使用

2012-03-19 21:06:52

Android

2012-10-16 09:56:18

扫地僧励志帝开源社区

2019-11-14 13:33:56

Python数据Excel

2018-01-29 09:42:27

创业技术团队

2017-06-14 16:41:02

2010-05-05 09:52:06

Unix BSD

2010-05-24 17:23:41

Linux SNMP

2021-03-07 22:38:10

Git 架构代码

2010-11-24 11:15:40

Qualcomm实施云计算

2012-06-26 12:14:05

容错服务器stratus

2009-07-27 14:28:46

2015-12-15 15:27:37

NginxHTTP网络协议
点赞
收藏

51CTO技术栈公众号