抛掉顾虑，放手一搏：不要让条条框框束缚你

最新推荐文章于 2022-01-04 17:33:03 发布

原创最新推荐文章于 2022-01-04 17:33:03 发布 · 470 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#敏捷开发 #项目管理 #编程语言 #github #人工智能

全文共1710字，预计学习时长5分钟

图源：unsplash

笔者曾在一个极注重学术的技术主管手下工作。平时，他要么就在重写那些耗时数日甚至数周完成的功能代码，力图精益求精，要么就在阅读有关设计模式和代码库原则的博文。

我们本该在三个月前就上线应用程序的首个版本，但超期却依旧一无所成。当团队其他成员忙于为首个版本构建和上线功能时，他却在不断编写和重写、修改文件结构，坚持不懈地追求完美。数周过去了，应用程序却还未面世，我们的首席技术官（CTO）终于得知了此事。

应用程序发布后，这位技术主管从公司离职，笔者被提拔到了他原本的位置。随后，怪事发生了：笔者最初是想延续前任技术主管的作风。这倒不是说要重写代码，而是坚持完美主义。

不久之后，笔者正在为企业客户开发一个单点登录（single sign on）功能。笔者开始冥思苦想编写某个小函数的“最佳”方法以及它应该在哪里运行。这个函数大概最多只有5行。

“它应该是一个自由函数（free function）吗？它应该在自己的文件中，还是与其他单点登录代码混合在一起呢？”它应该作为某个单一显式函数（single exposed function）的一个类（class）吗？既然它这么小，我能否将其附加在单点登录的另一部分中，而不必担心它自己如何运行呢？”

笔者延续了前任技术主管的思维模式，并且痛苦地意识到，这并未带来任何实际成果，也没有给公司客户带来任何好处。

笔者去了工程部副总裁（VP）那里，想询问他对这一小函数的看法。笔者已经准备好和他进行一次讨论，就像和前任技术主管反复商讨过的那样。然而谈话很简短。他的回答彻底颠覆了笔者的工作方式和对代码的看法。

他说了这么一句话：“这都无伤大雅，尽管放手一搏吧。”

笔者茅塞顿开。现在，笔者终于成为了一名合格的技术主管，带领着自己的团队。团队上下都不赞同之前学究式的、被外界意见所左右的完美主义。为什么还要去担心我们的代码是否符合无关人士的看法呢？

外界的看法是不断改变的。笔者是“Better Programming”栏目的编辑，对这一点再清楚不过。别人所写的博文虽能够在理论上有所帮助，但从根本上来说对企业无足轻重。我们的唯一目的就是让产品上线。从那次谈话以来，我改变了领导团队的方式。

“先记录下问题，产品上线后再仔细研究”成了我的准则。我们都清楚哪些是必须完成的事情。我们需要开发功能、保证质量、修复漏洞，这样才算完工，然后着手开发下一个功能。我们也列出了一个清单，记录了那些留待之后考虑的问题。

应用程序上线后，代码虽然称不上“完美”，但也没有因此发生任何灾难性的事情。

拖延的本质是畏惧。我和副总裁之间的简短交谈令我意识到了这一点。就代码库的标准以及团队和公司的最佳做法达成一致当然是可以的。但如果因为团队成员的代码必须遵循某个固执己见的工程师的偏好，从而导致工作进展缓慢，那么这势必会推迟产品的上线时间。

因此，不论诸位读者目前是在学习编程还是已经入行，都应多花些时间用于实际行动，而非瞻前顾后，被工程上的条条框框束缚住手脚。