蓝盟IT小贴士，来喽！
应用程序公布后，这位技术负责人从公司辞职，笔者被提拔到他的原来位置。 之后，笔者最初发生了想继续前任技术主管做法的奇怪事情。 这不是重写代码，而是坚持完美主义。
不久，笔者正在为企业客户开发单点登录功能。 笔者开始思考写某个小函数的“最好”方法及其应该在哪里执行。 这个函数最多只有五行。
“这应该是自由函数(free  function  )吗？ 那个应该在自己的文件里还是和其他单点登录代码混合在一起？ ”。 是否应该用作单个显式函数的类(class  )？ 这么小，不用担心自己怎么工作，可以添加到单点登录的其他部分吗？ ”。
笔者继续前任技术负责人的思维模式，并注意到痛苦。 这没有带来实际成果，也没有给公司的顾客带来任何好处。
笔者想去工程部门副总裁(VP  )那里，听听他对这个小函数的看法。 笔者就像和前任技术负责人反复商量一样，准备和他讨论。 但是，对话很短。 他的回答彻底瞄准了笔者的工作方法和对代码的看法。
他是这样说的。 “这是无害的。 你可以离开一步哦。 ”。
笔者茅塞顿开。 现在笔者终于成为合格的技术负责人，领导着自己的团队。 小组上下都不赞同被至今为止研究性的外界意见所左右的完美主义。 为什么需要担心我们的代码符合相关人员的意见呢？
外界的看法不断变化。 笔者是“Better  Programming”专栏的编辑，这一点不清楚。 别人写的博文在理论上很有用，但基本上对企业来说并不重要。 我们唯一的目的是使产品在线。 自从那次对话以来，我改变了领导团队的方法。
“记录问题，产品上线后仔细研究”成为了我的指南。 我们知道什么是必须完成的。 我们需要开发功能，保证质量，修复漏洞。 至此完成，着手开发以下功能。 我们也做了清单。 这是为以后考虑保留的问题记录下来的。
应用程序在线后，代码不能说是“完美”，但没有因此而发生灾难性的事情。
拖延的本质是恐惧。 与副社长的简短对话注意到了这一点。 当然可以与基于代码的标准和团队就公司的最佳做法达成协议。 但是，如果团队成员的代码必须遵从顽固的工程师的喜好，工作进展缓慢，则产品的在线时间将会延迟。因此，无论所有读者现在是学习编程还是已经进行，都应该在实际行动上花费很多时间，而不是向前看，被工程上的框架束缚住手脚。
必须确保自己代码的安全性、可靠性和效率。 但是请记住，你的代码效率可能有点低，但这是无害的，不会对公司造成很大影响(至少暂时没有)。 这是小事！ 放手去干就行了。
在工作中也优化代码调整。 等到产品完成后再反省。 如果你的代码不按时在线，反而可能会为企业付出更大的代价。

文/上海蓝盟  IT外包专家

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 蓝盟IT外包，IT专业人员仍然需要在企业框架人员的工作中扮演重要的角色. (ente

• 分享到：