网红机器狗再易主！
|
应用程序发布后，这位技术主管从公司离职，笔者被提拔到了他原本的位置。随后，怪事发生了：笔者最初是想延续前任技术主管的作风。这倒不是说要重写代码，而是坚持完美主义。 不久之后，笔者正在为企业客户开发一个单点登录(single sign on)功能。笔者开始冥思苦想编写某个小函数的“最佳”方法以及它应该在哪里运行。这个函数大概最多只有5行。 “它应该是一个自由函数(free function)吗?它应该在自己的文件中，还是与其他单点登录代码混合在一起呢?”它应该作为某个单一显式函数(single exposed function)的一个类(class)吗?既然它这么小，我能否将其附加在单点登录的另一部分中，而不必担心它自己如何运行呢?” 笔者延续了前任技术主管的思维模式，并且痛苦地意识到，这并未带来任何实际成果，也没有给公司客户带来任何好处。 笔者去了工程部副总裁(VP)那里，想询问他对这一小函数的看法。笔者已经准备好和他进行一次讨论，就像和前任技术主管反复商讨过的那样。然而谈话很简短。他的回答彻底颠覆了笔者的工作方式和对代码的看法。 他说了这么一句话：“这都无伤大雅，尽管放手一搏吧。” 笔者茅塞顿开。现在，笔者终于成为了一名合格的技术主管，带领着自己的团队。团队上下都不赞同之前学究式的、被外界意见所左右的完美主义。为什么还要去担心我们的代码是否符合无关人士的看法呢? 外界的看法是不断改变的。笔者是“Better Programming”栏目的编辑，对这一点再清楚不过。别人所写的博文虽能够在理论上有所帮助，但从根本上来说对企业无足轻重。我们的唯一目的就是让产品上线。从那次谈话以来，我改变了领导团队的方式。 “先记录下问题，产品上线后再仔细研究”成了我的准则。我们都清楚哪些是必须完成的事情。我们需要开发功能、保证质量、修复漏洞，这样才算完工，然后着手开发下一个功能。我们也列出了一个清单，记录了那些留待之后考虑的问题。 应用程序上线后，代码虽然称不上“完美”，但也没有因此发生任何灾难性的事情。 拖延的本质是畏惧。我和副总裁之间的简短交谈令我意识到了这一点。就代码库的标准以及团队和公司的最佳做法达成一致当然是可以的。但如果因为团队成员的代码必须遵循某个固执己见的工程师的偏好，从而导致工作进展缓慢，那么这势必会推迟产品的上线时间。
因此，不论诸位读者目前是在学习编程还是已经入行，都应多花些时间用于实际行动，而非瞻前顾后，被工程上的条条框框束缚住手脚。 保护连接 物联网安全连接的必要性具有相当大的意义。对于早期的新奇设备来说，如果连接失败，或者设备的安全性被破坏，其影响是有限的。如今，对于绝大多数物联网设备来说，情况已不再如此。连接性或安全性的失败将产生巨大且代价高昂的后果。 供水中断、施工事故，或者城市交通混乱——物联网设备的连接性和安全性是其运行的基础。 组织现在需要重新审视现有的连接和未来计划的服务，并提出以下问题：
为了确保未来，物联网必须确保现在。 （编辑：平凉站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
