本文转载自公众号“读芯术”(ID：AI_Discovery)。
笔者曾在一个极注重学术的技术主管手下工作。平时，他要么就在重写那些耗时数日甚至数周完成的功能代码，力图精益求精，要么就在阅读有关设计模式和代码库原则的博文。
我们本该在三个月前就上线应用程序的首个版本，但超期却依旧一无所成。当团队其他成员忙于为首个版本构建和上线功能时，他却在不断编写和重写、修改文件结构，坚持不懈地追求完美。数周过去了，应用程序却还未面世，我们的首席技术官(CTO)终于得知了此事。
应用程序发布后，这位技术主管从公司离职，笔者被提拔到了他原本的位置。随后，怪事发生了：笔者最初是想延续前任技术主管的作风。这倒不是说要重写代码，而是坚持完美主义。
不久之后，笔者正在为企业客户开发一个单点登录(single sign on)功能。笔者开始冥思苦想编写某个小函数的“最佳”方法以及它应该在哪里运行。这个函数大概最多只有5行。
“它应该是一个自由函数(free function)吗?它应该在自己的文件中，还是与其他单点登录代码混合在一起呢?”它应该作为某个单一显式函数(single exposed function)的一个类(class)吗?既然它这么小，我能否将其附加在单点登录的另一部分中，而不必担心它自己如何运行呢?”
笔者延续了前任技术主管的思维模式，并且痛苦地意识到，这并未带来任何实际成果，也没有给公司客户带来任何好处。
笔者去了工程部副总裁(VP)那里，想询问他对这一小函数的看法。笔者已经准备好和他进行一次讨论，就像和前任技术主管反复商讨过的那样。然而谈话很简短。他的回答彻底颠覆了笔者的工作方式和对代码的看法。
他说了这么一句话：“这都无伤大雅，尽管放手一搏吧。”
笔者茅塞顿开。现在，笔者终于成为了一名合格的技术主管，带领着自己的团队。团队上下都不赞同之前学究式的、被外界意见所左右的完美主义。为什么还要去担心我们的代码是否符合无关人士的看法呢?
外界的看法是不断改变的。笔者是“Better Programming”栏目的编辑，对这一点再清楚不过。别人所写的博文虽能够在理论上有所帮助，但从根本上来说对企业无足轻重。我们的唯一目的就是让产品上线。从那次谈话以来，我改变了领导团队的方式。
“先记录下问题，产品上线后再仔细研究”成了我的准则。我们都清楚哪些是必须完成的事情。我们需要开发功能、保证质量、修复漏洞，这样才算完工，然后着手开发下一个功能。我们也列出了一个清单，记录了那些留待之后考虑的问题。
应用程序上线后，代码虽然称不上“完美”，但也没有因此发生任何灾难性的事情。
拖延的本质是畏惧。我和副总裁之间的简短交谈令我意识到了这一点。就代码库的标准以及团队和公司的最佳做法达成一致当然是可以的。但如果因为团队成员的代码必须遵循某个固执己见的工程师的偏好，从而导致工作进展缓慢，那么这势必会推迟产品的上线时间。
因此，不论诸位读者目前是在学习编程还是已经入行，都应多花些时间用于实际行动，而非瞻前顾后，被工程上的条条框框束缚住手脚。
要确保自己的代码安全、可靠并且比较高效。但是请记住：可能你的代码效率稍微低了一些，但这无伤大雅，并不会给公司造成什么巨大的影响(至少暂时不会)。这都是小事!放手去做就行了。
工作过程中，你也会对代码做出调整优化。等到产品完成之后再进行反思。如果你的代码不按时上线，反而更可能会让企业付出更大的代价。
