以前几个月，我老是在问本身类似的问题：为什愦我们总在苛求完美的代码?因为内部项目须要，从新捡起编码义务之后，我发觉悟们组内(也可能是大年夜多半软件开辟世比赛的大年夜多半人)花费了大年夜量时光在规整编码规范、模式和测试代码，但这真的有须要么?

作闻敉件开辟机构，我们须要持续地进行预算、时光和特点的均衡。这种均衡的结不雅是，很多特点须要修改，或者干脆不做了，可能原因是耗时过长或者成本太高。大年夜另一个方面来说，工程师平日认为项目特别赶，出来的代码平日都不完美。我信赖对于任何软件研发机构来说，这个近况都是很明显的。

上个月，我跟我们的一位客户(CEO)谈话，他们的 CTO 和主程请求我们赞助他们重构一部分代码。在不作稳重大年夜修改的前提下添加新功能几乎弗成能，并且没有人半数体代码实现很懂得。尽管今朝运行一切优胜，这部分项目初始代码大年夜技巧角度来看就是一团乱。这位客户(CEO)问我为什么须要重构，大年夜他的角度来看，代码今朝没有任何问题，只是须要宣布新功能可以再快一点。

我想这种情况下，两边都很有事理。开辟者们欲望用最新的技巧写出完美的代码，写完美的文档，每小我都可以懂得到具体实现，大年夜而可以便利测试和后续的保护进级。而另一方面，其它人却只是欲望快速经济地完成功能，大年夜而他们可以推出新功能或者倾销给更多客户。

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

忘掉落将来，为如今而编码

大年夜多半产品公司经历了几个阶段。每个阶段都须要对“完美”的意思有不合的看法。我们可以长时光地评论辩论哪些阶段是存在的，但为了本文，我将仅仅(just)区分为：概念验证代码、 MVP 代码和经久保护代码。并分别举例解释。

在为产品制订新的设法主意时，花费任何时光编写可扩大的、周全测试的并相符最新编码标准的代码是没有意义的。目标是供给一个概念原型，例如连接几个 API 或测验测验一个新的接口设法主意。当实现目标之后，任何人都不太可能再次深刻这个代码。

大年夜多半人在构建最小可行的产品时，都高估了对优质代码的需求。每个创虻公司的最重要的工作是宣布在一个漂亮的、功能完美的产品。该产品的后台工作道理并不重要。直到你的 MVP 真正获得存眷，你可以着手处理劣质代码，甚至手工做些工作来证实你拥有一个合适的产品/市场。只有在你肯定应用它，并且客户开端流入时，你应当开端关怀代码，如不雅没到这一步，你其实仅仅(just)写了一次性的代码罢了。

大年夜零开端写项目时，必定要花点心思。无论是写新项目，照样重写旧项目，都要规范地写代码。比如说，代码风格要清爽、要有可读性、要服从年夜必定的代码规范。然则然则，必定要当心，不要 过早优化 你写的代码。写的时刻尽管想下一?要实现的需求是什么，而不是边写边纠结怎么缓存资本、怎么弄个复杂的数据构造来储存数据之类的工作，还有别动不动就担心履行效力。你代码越简单，其他那些要接办你代码的人就越感激你。刚开端写项目时，这些很重要;今后给客户写项目时也一样重要，毕竟说不定哪天客户就要你把项目交给他们来持续写呢。

把这些带入实践中

并不存在完美的代码

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

客户的需求，八门五花。可写代码时用的库其实却更甚。有些库是我们本身写的，也有一些是第三方的。有时刻看一个项目标代码，还确切可能会发明它混淆了不合人的代码;比如说，本身的团队先写点代码给项目开个头，之后交给客户的团队写一会。最后呢，却竽暌怪由我们本身来收尾。

由此可见，每个项目标代码风格，以及用到的技巧、实现办法等都可以很不一样。你的项目，或许在宣布时堪称完美。然则，经由膳绫擎所说的┞封种把项目丢来丢去的过程之后，我猜最后肯定经常会有人嫌其他团队写的代码有问题，那这种项目显然就不完美了啊。

实际就是如斯，想杀青某件事，弗成能会有什么完美的办法。至于编程，固然我这么说可能会感到有点奇怪，但它压根就不是一门严谨的学科。你想编程实现某个需求，往往话苄很多办法。到最后你或许会发明，这些办法，其实都行得通。

处理不完美的代码

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

让一小我去写项目，如不雅这人发明项目里用了一堆过时了的代码，或者是用了 MVP 架构，又或者是项目写了良久良久，那这人肯定很想把全部项目给重写了，如许才感到全部项目尽在控制，如鱼得水，而不是看着就头疼。不过呢，重写大年夜项目一向都不是啥功德，成天流于情势写框架，却白白浪费了写营业逻辑的时光，这很没须要的。有些工作可以不消管它，别太纠结。然则呢，如不雅你重写的代码相符我下面说的┞封些标准，那你重写也不是啥坏事的说：(节录自 这篇文┞仿 )

1. 重写的代码真能实现需求么?
2. 代码真的┞俘确无误，并且效力还不错么?
3. 在 遇参预处理缺点 时可以做到不崩溃，或者 安然地停止履行 么?
4. 试起来轻易不?
5. 如不雅要修改代码，能尽量又简荡竽暌怪安然不?

这最后一条标准大年夜噶?鲱难做到的，毕竟要做到模块分别和抽象化，还要写测试代率攀来确保相符预期效不雅;并且代码若还有修改，只要修改响应的一部分测试代码就行，如许才可以加倍轻松地调试和修改代码。

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

每个礼拜我都邑和有好设法主意的人交谈，但他们欲望用很小的预算来实现他们的设法主意。当他们问我实现他们的设法主意须要花费若干时，我的答复是在 10k 至几十亿之间，所以根本上是把这个问题抛回给对方，问他们欲望花费若干。根据他们的答复，我会试图清跋扈地向他们解释他们可以等待什么：概念证实、MVP(Minimum Viable Product – 最简化可实施产品)或拥有经久可用代码的产品。

　　推荐阅读

　　数据分析与可视化，你靠什么搞定？

事实注解，大年夜数据技巧的┞方略意义不在于控制宏大年夜的数据信息，而在于对这些含有意义的数据进行专业化处理。可以说数据分析是决定计划过程中的决定性身分，也是大年夜数据时代发挥>>>详细阅读

本文标题：代码真的有必要写到完美吗？

地址：http://www.17bianji.com/lsqh/34826.html

 1/2    1