软件开发故事 - 我对 CTO 撒谎并挽救了项目

news2024/11/19 19:36:39

在这里插入图片描述

原文：GrumpyOldDev - 2024.04.18

这是几年前的事情了。还记得在我职业生涯的初期，父亲曾告诉我，做好工作往往意味着要在上司的阻碍下做好需要做的事情。他的意思是，你可以让上司成功并感到快乐；也可以让上司做每一个决定，在这种情况下，没有人会成功或快乐。

当时，我在一家财富 500 强公司工作，我们的 CTO 承诺要为一个重要的客户交付一个大项目，他与该客户有私人关系。他还决定将其中的一个关键部分外包给一家大型技术服务公司，该公司声称他们有一款产品可以为我们完成大部分繁重的工作。

在我的职业生涯中，这种情况很常见，当供应商说他们有一款产品时，真正的意思是他们一个隐约类似于产品的东西，在某种程度上符合我们的需求，并且通过大量的定制，他们可以把它改造成我们需要的样子。当然，通过定制他们的“产品”，我们巧妙地结合了供应商软件的所有缺点和定制软件的所有缺点。我们同时实现了“坏主意”中的“圣杯”：一个不灵活的供应商软件包，必须被强迫去做它并未设计去做的事情，还要从他们的主产品代码库中分叉出来 – 一旦供应商意识到维护它的成本有多高，它就会被淘汰。我们彼此抱怨这是一个多么可怕的馊主意，尤其是考虑到供应商在不按时交付产品方面的“良好记录”。

由于 CTO 每年都会更换他的直接下属，每次关于项目的状态都会是一些“老板，这是个好主意”，尽管根本没有人认为这是个好主意。

甚至连一般的主意都算不上。这是一个坏主意。

在这里插入图片描述

项目的其他部分都需要在公司内部进行大量开发，所以我们也有自己的挑战，忙得不可开交。但即便如此，随着整个夏天项目日期的推迟，供应商承诺他们的产品随时都可以集成到 10 月份的发布日期，除了 CTO 之外，其他人都越来越明显地感觉到项目遇到了麻烦。终于在 8 月份，供应商交付了他们的“产品”，我们开始了与之集成的死亡之旅。

9 月份，我们遇到了一个令人沮丧的错误。供应商的产品将每笔客户交易以 json 记录的形式存储在一个巨大的 json 文档中（注：此处的 json 文档存储在 MongoDB Collection）。因此，随着测试数据的积累，产品的性能变得越来越慢。添加一个新的交易需要从数据库中读取整个 json 文档，然后将新记录添加到文档末尾。供应商声称，他们可以通过索引交易字段来解决这个问题，这似乎有点帮助，直到我们遇到了第二个问题。

他们选择的数据库是 MongoDB，而当时 Mongo 的记录限制是每个文档 16MB。因此，到了 10 月份，当实施团队开始将真实的客户数据放入其中时，我们遇到了 16MB 的限制。事情开始变得有趣了起来，我们决定向客户隐瞒这一限制，并推迟一个月上线，但同时启动了一个小型项目来替换供应商集成，而且也没有告诉供应商。因此，我们同时欺骗了客户和重要的技术合作伙伴。

当时的“暴躁老开发者”更像是一个“热情的年轻开发者”，于是他组建了自己的团队来开发替代产品。供应商有 70 多人参与了这个项目，团队只分配了 3 个人来替换它。一个负责设计数据库，一个负责构建与数据库接口的后端，还有一个负责构建业务逻辑/网络服务。

客户被告知，我们将在 1 月份推出新版本供他们测试。新版本将修复他们在最初上线时遇到的最严重缺陷。但他们并不知道我们正在重写整个核心系统。这只用了不到两个月的时间，而原始的项目启动用了一年多的时间。只有 3 个人，还是在假期里（你看这是怎么回事）。

于是，大约在 12 月中旬，所有参与项目的人都被告知（不是要求）要在假期中工作。

要知道，在过去的 6 个月里，我们中的大多数人已经每周工作 60-80 个小时，只为赶上原定（大约）的发布日期。

每个人都累坏了。

此时此刻，如果你正在阅读这篇文章，而且你不是一个以交付为导向的技术人员，可能会觉得这太疯狂了，是时候辞职了。你是对的，但是，我们中的许多人真的很喜欢软件开发，感觉有点像摇滚明星。你花了几个月甚至几年的时间来准备这场“演出”，然后发布日期就像一场表演，你想在发布日期一炮而红。部分原因就像剧院里的人：演出必须继续。但你也想在自己的辛勤工作第一次与真正的用户见面时，感觉自己像个摇滚明星，感受到“我做到了”的快感。人们喜欢我做的事情，我战胜了不可能。对于内向的人来说，软件发布就像是现场表演。

在这里插入图片描述