开源中国

我们不支持 IE 10 及以下版本浏览器

It appears you’re using an unsupported browser

为了获得更好的浏览体验,我们强烈建议您使用较新版本的 Chrome、 Firefox、 Safari 等,或者升级到最新版本的IE浏览器。 如果您使用的是 IE 11 或以上版本,请关闭“兼容性视图”。
代码真的有必要写到完美吗? - 技术翻译 - 开源中国社区

代码真的有必要写到完美吗? 【已翻译100%】

标签: <无>
oschina 推荐于 2个月前 (共 7 段, 翻译完成于 04-17) 评论 33
收藏  
30
推荐标签: 待读

过去几个月,我总是在问自己类似的问题:为什么我们总在苛求完美的代码?因为内部项目需要,重新捡起编码任务之后,我发觉我们组内(也可能是大多数软件开发世界中的大多数人)花费了大量时间在规整编码规范、模式和测试代码,但这真的有必要么?

作为软件开发机构,我们需要持续地进行预算、时间和特性的平衡。这种平衡的结果是,许多特性需要修改,或者干脆不做了,可能原因是耗时过长或者成本太高。从另一个方面来说,工程师通常感到项目特别赶,出来的代码通常都不完美。我相信对于任何软件研发机构来说,这个现状都是很明显的。

pay606
 翻译得不错哦!

上个月,我跟我们的一位客户(CEO)谈话,他们的 CTO 和主程要求我们帮助他们重构一部分代码。在不作出重大修改的前提下添加新功能几乎不可能,而且没有人对整体代码实现很了解。尽管目前运行一切良好,这部分项目初始代码从技术角度来看就是一团乱。这位客户(CEO)问我为什么需要重构,从他的角度来看,代码目前没有任何问题,只是需要发布新功能可以再快一点。

我想这种情况下,双方都很有道理。开发者们希望用最新的技术写出完美的代码,写完善的文档,每个人都可以了解到具体实现,从而可以方便测试和后续的维护升级。而另一方面,其它人却只是希望快速经济地完成功能,从而他们可以推出新功能或者推销给更多客户。

那我们该怎么平衡这两种诉求呢?

清凌渡
 翻译得不错哦!

忘掉未来,为现在而编码

大多数产品公司经历了几个阶段。每个阶段都需要对“完美”的意思有不同的看法。我们可以长时间地讨论哪些阶段是存在的,但为了本文,我将仅仅(just)区分为:概念验证代码、 MVP 代码和长期维护代码。并分别举例说明。

在为产品制定新的想法时,花费任何时间编写可扩展的、全面测试的并符合最新编码标准的代码是没有意义的。目标是提供一个概念原型,例如连接几个 API 或尝试一个新的接口想法。当实现目标之后,任何人都不太可能再次深入这个代码。

大多数人在构建最小可行的产品时,都高估了对优质代码的需求。每个创业公司的最重要的事情是发布在一个漂亮的、功能完善的产品。该产品的后台工作原理并不重要。直到你的 MVP 真正得到关注,你可以着手处理劣质代码,甚至手工做些事情来证明你拥有一个适合的产品/市场。只有在你确定使用它,并且客户开始流入时,你应该开始关心代码,如果没到这一步,你其实仅仅(just)写了一次性的代码而已。

一旦这些辛苦积攒的客户开始流入,你有可能产生一些收入或吸引外部的融资。 现在是开始思考整洁、长期维护的代码的正确时机。这是在介绍中的示例上我们的客户所处的场景。鉴于你受众有可能增长,你需要开始考虑性能、稳定性和可用性。 你的工程团队也将扩大规模。这将迫使你实施编码标准、文档标准和一系列其他流程和实践。你开始需要完美的代码了。

可以看到,在每个阶段示例中我们的代码目标都有所不同,对于“完美”的定义,自然也有所不同。

Tocy
 翻译得不错哦!

并不存在完美的代码

我们都知道,开发软件涉及到多个不同的阶段。所以其实很难断定,到底有什么所谓完美的代码,完全适用于所有的开发阶段。

客户的需求,五花八门。可写代码时用的库其实却更甚。有些库是我们自己写的,也有一些是第三方的。有时候看一个项目的代码,还确实可能会发现它混杂了不同人的代码;比如说,自己的团队先写点代码给项目开个头,之后交给客户的团队写一会。最后呢,却又由我们自己来收尾。

由此可见,每个项目的代码风格,以及用到的技术、实现方法等都可以很不一样。你的项目,或许在发布时堪称完美。但是,经过上面所说的这种把项目丢来丢去的过程之后,我猜最后肯定经常会有人嫌其他团队写的代码有问题,那这种项目显然就不完美了啊。

现实就是如此,想达成某件事,不可能会有什么完美的方法。至于编程,虽然我这么说可能会感觉有点奇怪,但它压根就不是一门严谨的学科。你想编程实现某个需求,往往会有很多方法。到最后你或许会发现,这些方法,其实都行得通。

AzureSora
 翻译得不错哦!

处理不完美的代码

不完美并不等于劣质。去网上搜一下 Pareto principleSufficient Design 就知道为啥了。

让一个人去写项目,如果这人发现项目里用了一堆过时了的代码,或者是用了 MVP 架构,又或者是项目写了很久很久,那这人肯定很想把整个项目给重写了,这样才感觉整个项目尽在掌握,如鱼得水,而不是看着就头疼。不过呢,重写大项目一直都不是啥好事,整天流于形式写框架,却白白浪费了写业务逻辑的时间,这很没必要的。有些事情可以不用管它,别太纠结。但是呢,如果你重写的代码符合我下面说的这些标准,那你重写也不是啥坏事的说:(节录自这篇文章

  1. 重写的代码真能实现需求么?

  2. 代码真的正确无误,而且效率还不错么?

  3. 遇到并处理错误时可以做到不崩溃,或者安全地结束执行么?

  4. 试起来容易不?

  5. 如果要改动代码,能尽量又简单又安全不?

这最后一条标准大概是最难做到的,毕竟要做到模块分离和抽象化,还要写测试代码来确保符合预期效果;而且代码若还有改动,只要修改相应的一部分测试代码就行,这样才可以更加轻松地调试和改动代码。

从零开始写项目时,一定要花点心思。无论是写新项目,还是重写旧项目,都要规范地写代码。比如说,代码风格要清爽、要有可读性、要遵从一定的代码规范。但是但是,一定要小心,不要过早优化你写的代码。写的时候只管想下一个要实现的需求是什么,而不是边写边纠结怎么缓存资源、怎么弄个复杂的数据结构来储存数据之类的事情,还有别动不动就担心执行效率。你代码越简单,其他那些要接手你代码的人就越感谢你。刚开始写项目时,这些很重要;以后给客户写项目时也一样重要,毕竟说不定哪天客户就要你把项目交给他们来继续写呢。

AzureSora
 翻译得不错哦!

把这些带入实践中

每个星期我都会和有好想法的人交谈,但他们希望用很小的预算来实现他们的想法。当他们问我实现他们的想法需要花费多少时,我的回答是在 10k 至几十亿之间,所以基本上是把这个问题抛回给对方,问他们希望花费多少。根据他们的回答,我会试图清楚地向他们解释他们可以期待什么:概念证明、MVP(Minimum Viable Product – 最简化可实行产品)或拥有长期可用代码的产品。

作为程序员,我们应该尝试不那么完美主义,并且牢记保持这一目标。提供价值比我们的代码整洁更重要。只有当你为了长期目标,去追求完美才有意义。

作为首席执行官(CEO),你应该问自己,预算是否适合你的产品所在阶段,并且要牢记预算所提供的限制和机会。有时需要重构。

我相信,只要我们在内部或为客户开始一个新项目时,我们都需要询问代码的完美程度。所以我们可以根据短期和长期的期望来交付产品。

Tocy
 翻译得不错哦!

人们取笑我对 just 这个词的使用。因为我经常会说这句话 “just do it like this” (照这样做就可以了)。然后人们会向我解释说,这没有那么简单,因为我没有考虑到诸多的边缘情况。也许我是有意这样做,只想着 happy path(愉快路径),而忽略了任何可能出错的东西。在本文的上下文中,我决定强调 just 这个词,因为它与文章中讨论的问题高度相关。有时你只需要为愉快路径进行编码。

Tocy
 翻译得不错哦!
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们
评论(33)
Ctrl/CMD+Enter

并不存在完美的代码,也就是说,完美代码是相对的,相对于目前的业务逻辑,相对于目前的产品特征
产品实现优先,代码完不完美无所谓。等有一定的客户量或者有利润空间的时候,再来优化代码。

引用来自“nidongwo-”的评论

产品实现优先,代码完不完美无所谓。等有一定的客户量或者有利润空间的时候,再来优化代码。
话是这么说,但人在不同的角度说的话是善变的,据我接触的人群,95%以上的人等产品发布后,就把代码优化的事给忘记了,又或者是另外一种说法了:都运行了不要在乱动了.
没有追求就没有完美,不要为自己的无能辩护,如果总是强调我们不可能登上月球,也就不会有今天的登月计划,事在人为,前途有障碍,就看你有没有这个心去做这件事

引用来自“durban”的评论

没有追求就没有完美,不要为自己的无能辩护,如果总是强调我们不可能登上月球,也就不会有今天的登月计划,事在人为,前途有障碍,就看你有没有这个心去做这件事
:+1: 顶你
各种方面的妥协、协调才是好的

引用来自“durban”的评论

没有追求就没有完美,不要为自己的无能辩护,如果总是强调我们不可能登上月球,也就不会有今天的登月计划,事在人为,前途有障碍,就看你有没有这个心去做这件事
一个新功能,要求2天后上线,看你能不能有追求
工程师的产品是成本、利润、需求各种因素权衡后的产物,这种权衡的产物不可能是完全的。

引用来自“durban”的评论

没有追求就没有完美,不要为自己的无能辩护,如果总是强调我们不可能登上月球,也就不会有今天的登月计划,事在人为,前途有障碍,就看你有没有这个心去做这件事

引用来自“西红柿幽幽子”的评论

一个新功能,要求2天后上线,看你能不能有追求
2天?晚上必须上,出了问题你负责
对第一段内容中的见解不太认同,又或者只是歪果人对完美的定义不同,对我来说,好的代码规范是避免码农们少踩坑的重要途径。在协作开发的项目组中测试代码更是重中之重,难道要将一些简单的单体错误带到集成测试中才发现修改吗?
语无伦次的文章,狗屎一般的逻辑,其实就是因为菜!代码写的不完美代表着乱、bug多。
这个就像饭店里桌上的菜,客人吃着说好就可以了,至于后厨的食材、卫生状况,门一关谁知道呢
这跟过度的前期设计是一个路子啊
没有完美的代码,不代码不追求完美的代码。二码事!

引用来自“durban”的评论

没有追求就没有完美,不要为自己的无能辩护,如果总是强调我们不可能登上月球,也就不会有今天的登月计划,事在人为,前途有障碍,就看你有没有这个心去做这件事

引用来自“西红柿幽幽子”的评论

一个新功能,要求2天后上线,看你能不能有追求

引用来自“天落s”的评论

2天?晚上必须上,出了问题你负责
哪有那么急!!领导说明天早上他过来时要看。还有特别叮嘱下,不要太劳累了。
如果是写自己的项目,我会花大把的时间去重构,甚至重写好几遍,写慢点也无所谓,重点是享受这个过程。。如果是给公司写,就算了,吃力不讨好。。。

引用来自“nidongwo-”的评论

产品实现优先,代码完不完美无所谓。等有一定的客户量或者有利润空间的时候,再来优化代码。
走上完美的路是条死路
预算总是有限的,时间总是不够的,所以每个人都在写just work的代码,每个人都在做苟且的事情。
然后时间一长,因为惯性作用,只会每个人写的代码越来越苟且,直到有一天有个人大喊“我再也忍不住啦”,开始尝试重构代码。
但是他发现原来的代码质量之差难以想象,重构难度之大超出预期,然后他思考了一下说:“得,我还是忍忍吧”。

作为CEO你以为前人拉屎后人会擦?太天真,根本没人擦,非但不擦,还接着拉。为什么?谁让你一开始就允许有人拉屎,而且还鼓励拉屎。
随着时间的推移,程序员一波一波换,屎越来越多,最终再也没有程序员愿意接这个烂摊子了。
我认为作者从实用和项目阶段出发衡量项目开发方式或代码编写质量是可行的。而且不客气的说,绝大多数的项目都是这样的货色。
再者一般的公司项目的项目能活多久?哪个公司的项目都会重构,作者也说了代码简单最好,做一些必要的文档就好。现在敏捷开发差不多都是这样干的,别看着规范些的很好,实际做到位的能有几个?
顶部