当上 CTO 才发现：程序员时常犯的 4 个错误有多可怕！

程序员| 2021-04-09

【CSDN 编者按】随着网络科技的创新，IT行业迎来了长足的发展，程序员群体也在不断扩大当中。尽管程序员能够解决开发或测试或运维等各自方向的大部分问题，但程序员毕竟不是万能的，也会出现常见的错误。

作者 | Jakub Górowski

责编 | 弯月

出品 | CSDN（ID：CSDNnews）

我当程序员已经5年了，不过这也没什么大不了，因为你们中很多人的工作经验可能是我的3倍以上，但我一直认为自己是高级开发人员。

因机缘巧合，我成为了一家创业公司的首席技术官（CTO）。在新岗位工作一段时间后，我才发现自己算不上高级开发。这并不是说我的编程技术差，而是想起以往，我在工作中常犯的 4 个错误。

用户都是傻瓜

我错了，他们才不是傻瓜咧。

没错，用户使用应用的方式往往出人意料，而且很诡异。

没错，用户经常会问一些很傻的问题。

没错，有时用户提出的要求看似毫无意义。

没错，用户连一些非常浅显的功能也搞不明白。

毕竟，用户不是IT专家。医生从来都不会指望病人能够明白低密度脂蛋白和高密度脂蛋白之间的区别。那么，我们又凭什么要求用户了解他们应该使用哪种浏览器呢？虽然对你和我来说这个问题太显而易见了，但是在我妈看来，Google就等同于互联网，她说她没有使用任何浏览器，因为她使用的是Google。

有时，为了让用户满意，我不得不重写部分框架，为的只是修改其默认行为。有时，我不得不支持一些本来不打算支持的浏览器（比如Safari）。虽然如今看来这种想法很愚蠢，但当时的我真的觉得这都是客户的错，因为他们的要求，我不得不想尽办法在我的代码中做一些折中和变通。

代码就是艺术，必须力求完美

整洁的代码，严密的单元测试，完善的文档，毋庸置疑这些都非常重要。作为一名程序员，我总是要求自己使用现代模式编写整洁的代码，而且我会频繁地检查所有的依赖项都是最新的。因为我想成为一名优秀的程序员。

每当我的产品经理要求我放下手头的单元测试，提高开发新功能的速度时，我就会火冒三丈，为什么他意识不到单元测试有多么重要呢？当时，我们并没有其他自动测试，所以单元测试是保障产品稳定且没有回归问题的唯一希望。

在我看来，产品经理提这种要求就是因为他的目光短浅。更有甚者，他还暗示我停止编写文档，将代码转换成复杂度更低的架构（当时项目刚刚开始）。

我承认，压缩这些工作可以加快开发速度，但是将来我们肯定会遇到很多问题。我们不得不花费大量时间来修复回归错误，而且随着项目的发展，新的架构也会变得过于简单！此外，如果没有完善的文档，新加入的程序员又如何能快速融入项目呢？

就为了这个问题，我们花费了好几个小时反复讨论，并分析了将来会给我们带来多少损失。

然而，几个月后，那个项目以失败告终，因为预算大大超支。

多年后，我不得不承认，我们的团队犯了一个巨大的错误。我们光顾着考虑将来，却忘记了眼前。我们完全忽略了当时的情况：我们只有很少的预算，而且需要在短时间内迅速建立最小可行产品。

编写可以向他人展示且令人自豪的代码固然很好，但是能够顺利地完成项目不是更好吗？毕竟，编程不是艺术。

只选择自己熟知的技术栈

在以前的公司工作时，每次创建新项目，我们都使用相同的技术栈：Symfony和Angular。Symfony是最好的后端框架吗？并不是。Angular是创建现代前端的唯一途径吗？并不是。我们总是选择这套技术，因为我们不了解其他技术。我们一直在自己的舒适圈内徘徊。但是在新项目中选择众所周知的技术有错吗？这要视情况而定。

在许多情况下，下一个项目与先前的项目多少会有一些相似之处。由于你已有可靠的解决方案，因此花大量时间学习新技术没有任何意义。但是有时候，这种决定可能并不正确。

我记得有一个项目，最重要的需求便是一个运行良好的WebSocket。我们选择了哪种技术来创建后端呢？当然是Symfony。也许现如今使用PHP创建WebSocket很容易，但在当时那就是一场噩梦。我们花费了巨大的精力才让系统跑起来。当时我们知道使用PHP创建WebSocket会花费很多时间（和金钱），但是我们仍然舍弃了使用Node的想法。为什么？我自己都不知道。我们可以利用Node构建速度高达10倍的API，但只是因为我们团队的技术栈里没有Node。

我很高兴现如今我们的团队成员都非常开明。上周，我们决定使用一个完全不同的技术来构建我们的一部分系统。我相信这个决定可以为我们节省很多时间，尽管我们需要从头开始学新技术。

产品经理太糟糕了，还不如我来

当我还是一名程序员的时候，说实话我和产品经理的关系……不太融洽。每当他告诉我计划的范围有变时，我都会很生气：

“为什么你不能做好本职工作，事前定义好范围呢？事先决定好功能需求有这么难吗？”

当时的我简直太天真了，我把事情想象的太简单了。如今，我终于知道计划好项目的每一个细节简直难以上青天。首先，你必须考虑到技术和预算的限制；其次，你必须设身处地的为产品的用户考虑，不能忘记业务与市场的需求。你无法在项目伊始就掌握所有的需求；有时，业务环境会发生变化；有时，你必须先构建一部分产品，然后再逐步改良。

另外，产品经理也可能会犯错误。程序员会编写出bug，产品经理也会犯错。如今想来，这都是再明显不过的事情了。如果当时我能够意识到这一点，那么就可能就会成为一名更好的程序员。我不应该钻牛角尖，就为了证明产品经理错了，而是应该集中精力寻找解决方案。

有时，我甚至忘记了自己和产品经理有着相同的目标，即打造出色的产品，现在想来不禁觉得汗颜。产品经理掌握的有关预算、业务状况、客户需求、截止期限和优先级方面的信息比我多，这也就是为什么我不理解他们为何做出某些决定的原因。