github_37934404的博客

为了将此次进行的“黑色星期五”促销活动区别与凤凰项目的工作方法，玛克辛他们将项目命名为“独角兽项目”。玛克辛觉得早就应该给团队起个独特的名字，按照塔克曼的团队阶段模型，他们经过了形成期、动荡期，她已经准备好开启团队的规范期和高效期了。由于团队在演示日之前经历问题并迅速修复，现在每个人都清楚目标是什么，团队也会自组织起来，更好地实现这个目标。“不同职能的人——开发、QA、运维、安全......还有数据和分析——像队友一样每天在一起工作，而不是之前像对手一样”。促销活动终于开始了。手机 APP 系统由于

打造伟大的产品需要什么？作为开发者，我们能够提供什么帮助？

玛克辛总算解决了项目环境的问题，但是现在障碍是测试。通过在白板上，分析功能的价值流，发现凤凰项目的现有架构无法使团队独立的开发、测试或是向客户交付价值。团队需要对数据总线和项目进行解耦。在 LARB （Lead Architecture Review Board，即首席架构审查委员会）会议上 ，反抗军发现了一位优秀的工程师。她据理力争，要求将应用程序重新平台化，使用TOMCAT。这是她第二次提议，“为什么我们如此海派运行自己编写的软件......不仅可以每年为公司节省几十万美元，还可以实现第三方软件

在进行代码合并时，出现了 43 个合并冲突，团队觉得这很痛苦，而他们的逻辑是，痛苦就少做。玛克辛表示，“之所以痛苦，是因为合并的规模太大了。为了减少痛苦，特们需要跟频繁地进行合并，这样合并的规模就会变小，产生的冲突也会更少。”团队需要变更时，只有 一个 SCM 经理有权进行。团队认为这样的设置理所当然，只为了“合规”和“信息安全”。玛克辛感叹，

技术高管们决定将功能交付暂缓，任命库尔特带领数据总线团队利用这一个月的缓冲时间，偿还技术债务。事实上，让数据总线团队为凤凰项目的发布背黑锅，“就像在无端指责一家失事飞机后排的乘客没有把安全带系紧一样“。数据总线包含几十年前的老系统，那时候都没有凤凰项目。库尔特邀请玛克辛一起参加数据总线团队的工作。她通过让每个线程创建自己对象的副本，使每个对象方法重写为纯函数，即输出完全依赖于输入，不会影响其他部分或全局访问，解决了一个“足以把十级黑带”逼到绝望的问题。她意识到，这正是第一理念，局部性和简单性的一个最佳实

正如道恩预测的那样，凤凰项目上线就是个灾难。启动发布 14 个小时了，还没发布成功。电商网站的订单、流量，甚至公司的电子邮件服务器都出现了问题。“技术故障在整个组织中蔓延，就像海水不断涌进一艘正在沉默的潜水艇一样”。正当红衫军奋力扑救大火的时候，长官们却在继续掩盖自己的错误。QA 总监威廉被“休假”了。晚上，反抗军们在酒吧里又碰头了，每个人都是垂头丧气。他们谈到了三个交换机的问题。原来有三家不同外包商维护的三台交换机，被一台更大更强的交换机取代了。结果，团队反而不能正常工作了。一开始为了节省成本作出

长官的任务是确保公司的战略切实可行，而不是提醒他们战略是什么或细致入微地管理每一个人