代码工厂中一个孤独的 Zen 开发者的故事

原文：https://medium.com/hackernoon/a-tale-of-a-lone-zen-developer-among-code-factories-618134e68221

这篇文章是我之前的文章的续篇——拥抱并传播禅宗编码。早先的帖子描绘了一幅谁是 Zen 开发者的图画。但是谁是代码工厂呢？代码工厂是那些以制造大量代码为荣的开发人员，他们用特性和错误膨胀产品，既得利益者成为团队不可弥补的负担。

“责任”这个词太苛刻了吧？嗯，代码是责任，代码工厂也是责任。让我们把这件事搞清楚。“少即是多”，无论是产品特性、团队规模还是代码。不管你的角色是什么，对于你承担的每一项任务，都要学会从更大的角度正确看待业务，并以相反的方式工作。成为一名 Zen 开发者在这个旅程中帮助你，尽管成为一名 Zen 开发者本身就是一个旅程。

说实话，在一个 zen 团队中做一名 Zen 开发者是一种很难体验到的理想状态。作为一个 10 倍开发团队中的 Zen 开发人员，有自己的挑战等待解决。这很难，非常难，但非常值得你花时间、精力和吸取教训。

接下来是一个基于真实工作场所事件的故事来证实这一哲学:任何与你的团队相关的事件都是完全偶然的，它只显示了这种模式在软件开发团队中的流行。

曾经有一家公司叫做无情的 IT 咨询公司，它以当代的软件交付方式而自豪。这家公司的一项工作是为一家旅游初创公司开发产品。该产品的想法是利用千禧一代分享旅游信息、折扣和优惠券的社交媒体热潮，以及在未来旅行中获得折扣的副作用。该产品将在几个亚洲国家推出，这些国家的语言、货币等各不相同。

成立了一个由 3 名成员组成的小型 seed 团队，通过引入以下人员开始构建该产品:

代码工厂先生又名 CF 先生(有 10 年的数字经验)，
曾女士开发商又名 ZD 女士(一个 6 年经验的开发商)和
脆弱的牛顿先生又名 FN 先生(一名大一印度本科生开发者，梦想在美国攻读计算机科学硕士学位)。

这是 CF 领导团队的第一个项目，他非常想打造一个功能丰富的产品，让客户惊叹不已。

听起来很熟悉？这种情况很常见，真正重要的是一个人如何应对这种情况。让我们看看 CF 如何应对这种情况..

从第一天开始，CF 先生就很快改变了思路，希望尽可能多地编写代码，以增强他构建梦想中的功能丰富的产品的信心？他实际上是睡在办公室里，一大早就回家梳洗一番，以便更快地回到办公室。猜猜管理层对他有什么看法？我让你去想象:)猜猜其他团队成员对他的感觉？虽然他们理解他的意图，但他们也表达了对他和他的健康的担忧。

一次冲刺过去了，CF 先生开始觉得有点太累了。他想成为一名成功者，并在某处读到成功者是非理性的。(等等，这是不是意味着非理性的人是成功者？)

当然，成功者是不理性的。但是反过来就不正确了。

情绪影响了 CF 的理智，他在第二次冲刺时也是如此。在冲刺的中途，他感觉到肩上新责任的重量，甚至睡不好觉。白天，他会将这种痛苦分享给他的团队成员和办公室的其他人。

Aping the achievers..

麻烦，麻烦和更多的麻烦开始酝酿团队。CF 先生现在希望他的开发伙伴们模仿同样的行为。

ZD 女士是一名中高级开发人员，碰巧目睹了很多类似情况下的项目失败，并且已经学会了如何成为一名平衡的 Zen 开发人员。因此，她保持冷静，希望减轻团队的痛苦，同时也希望为最终业务的成功而努力。她礼貌地否定了 CF 先生的期望设置，分享了她对 CF 先生和最终业务的担忧。她试图教育人们，巨大的压力会使人看不到努力的工作，而不是聪明的工作。

CF 先生认为这是对他个人成功的抵制和威胁。他对另一个开发人员施加压力，要求他遵守自己的新期望。可怜的 FN 先生，新手开发者被夹在这场战争中间。由于担心个人梦想受到威胁，他同意服从。ZD 女士在这场游戏中肯定会输。她很清楚。她宁愿承担个人风险，希望说服团队相信自己的愚蠢。

与此同时，ZD 决定保持冷静，按自己的方式行事。突然，她看到了一个证明自己观点的绝佳机会。就产品的本质而言，有几个关于跨境货币交易的用户故事。谢天谢地，这是当前 sprint 开发工作的一部分。

她建议 CF 和她自己都选择那个故事，分别做开发工作，看看各自是如何处理这个问题的。出乎她的意料，CF 同意了；因为他认为他能把他的观点表达清楚。这是故事中不寻常的转折，在这种团队环境中不太可能发生。幸运的是，它发生在这种情况下。ZD 问他将如何着手这项工作。CF 对这个问题很兴奋，但却不由自主地自我称赞他的价值。他实际上是试图通过大声的自言自语来建立内心的自信。耐心听完之后，ZD 接着要求解决这个问题。CF 想了想，列出了以下任务:

为货币转换器服务进行概念验证，将美元转换为当地货币或从当地货币转换为美元。
该产品建立在客户开发团队正在开发的底层 web 服务之上。CF 认为，在客户团队完全开发 API 之前，理解 API 是浪费他的时间。所以他提议用一个随机契约来嘲弄它。
i18n 的代码

ZD 感到如释重负。在她看来，上述两项任务可能都是不必要的，而且更像是一种负担。她感到非常需要理解集成点合同，以便更好地理解整个业务工作流程。她觉得这里非常需要合作。但这是她帮助他理解她的观点的黄金机会。

她试图与 CF 进行对话，解释与构建 web 服务的团队进行对话的必要性，了解 API 合同，缝合工作流，然后决定下一步。没有达成一致，但幸运的是，双方都同意用几天时间来解决这个问题，看看会有什么结果。

几天后，CF 重新焕发了活力，努力工作并完成了工作，分享了产品功能完成得如何的演示。(但是产品功能真的准备好了，做好了吗？)

在同样的几天里，ZD 花时间检查了来自网络服务下游团队的 API 合同，与他们交谈，理解它并在其上缝合工作流。但遗憾的是她一行代码都没写。她能有多蠢？让我们看看。

在 CF 展示了他的演示后，他逗 ZD 展示她的代码作品。

ZD 礼貌地点了点头，回答说完成用户故事所需要的就是根据合同从 web 服务中调用相应的 API。并且不需要任何货币兑换服务，因为它由正在开发的底层 web 服务负责。她分享了她与另一个团队合作的经验，谈到了旅游业的利润有多薄，每笔交易中的每一分钱都很重要，以及雇佣第三方服务进行货币兑换如何伤害了他们，更不用说在这个过程中增加一个依赖因素和未知的错误了。

与 CF 编写的数百行代码相比，考虑到 i18n，这只是几行代码。

CF 同时感到羞愧和愤怒。虽然他同意并删除了他的代码行，并应用了新发现的知识，但他确实将此称为例外情况，并希望 ZD 遵守他对长时间工作的期望。

唷，现实太残酷了！还是简单的办公室政治？

至于故事的其余部分，我留给读者去想象。

我真的很感激听到你在这个主题下分享你的经验。别忘了在你忘记之前喜欢并分享这篇博文

下面其他平台也转载了这个帖子: