框架框架

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文。

这次全员会议显然将会是 特别的

本来应该只有那种让人沮丧的零食袋，却改成了餐饮服务。原本普通的 PowerPoint 标题页，也换成了一张精美渲染的图形。有什么 大事 要来了；那种让我们坐得比椅子本该承受的更端正的 大事。

会议开始，宣布：高层管理已经 数周 全神贯注地在构建我们的新 Company Strategic Model！该模型将协同我们零散的优先事项，统一跨职能的倡议，推动整体价值创造，并将关键学习（不管那到底是什么意思）进行运营化，以利用我们的核心竞争力，从而让我们能够回到——

…好吧，你明白我的意思了。

新的战略模型充斥着让西装人士心跳加速的内容，却完全缺少，你懂的：真正的战略。我们构建了一个 思考框架，却 忘了去思考。

当模板取代思考

我们喜欢框架，因为它们让我们觉得自己在做聪明的事，即使我们并没有解决正确的问题。

还记得那场关于单体和微服务的“大闹”吗？几家大规模公司（比如 Uber 和 Netflix）公布了它们的战斗经验，结果每个只有两名开发者和一个梦想的创业公司都开始把代码拆成上百个小服务。我们自称在走向现代化，实际上大多数人只是在装逼规模。

而且这不仅仅是架构……想想 JavaScript 框架。

大约每三十八秒就会出现一个新框架，它们都承诺最终解决前端构建的问题（好像这个问题从来只是技术层面的）。每个框架都给我们一种安慰的幻觉：只要选对工具，软件中混乱的人为因素（比如沟通、设计和妥协）就会消失。

但事实并非如此。它们永远做不到，因为问题不在框架，而在于我们对框架的救世情结。当框架取代了深思熟虑时，我们得到的就是…

另外……在不存在的地方看到模式听起来有点像阴谋论者的领域，不是吗？ 👽😱

当流程压倒目的

在上个世纪末，软件工程团队基本上已经确定了一套交付项目的方式……先是设计阶段，回答你能想到的所有问题；然后是编码阶段，构建产品；接着是测试阶段，为发布做准备；最后交付。

但这些规则正在改变；随着互联网的普及，软件产品越来越不像物理世界中的产品。它们不需要装在盒子里摆在货架上。因此在 2001 年初，一些从业者聚在一起，商定了更好交付软件的新原则。

一些过程派人士反对这些新理念，称其“缺乏结构、不可持续、不可扩展”等等各种“非”。随着时间推移，这些新理念逐渐占上风……最终“敏捷”成为一种被广泛接受的思维方式。

然后过程出现了

随着时间的推移，人们开始构建框架来帮助实现敏捷。组织往往对采用敏捷实践持犹豫态度，因为它们习惯了大量的运营规则，并且认为敏捷过于混乱。于是出现了 SAFe（企业级规模化敏捷）之类的东西。

问题在于，敏捷的原始原则与这种结构完全背道而驰。敏捷宣言本身就说明了这一点：

我们通过实践并帮助他人实践，正在不断发现更好的软件开发方式。
通过这项工作，我们认识到：

• 个体和交互 胜过 流程和工具
• 可工作的软件 胜过 完整的文档
• 与客户合作 胜过 合同谈判
• 响应变化 胜过 按计划行事

也就是说，虽然右侧的项目也有价值，但我们更看重左侧的项目。

真正发生的情况是，人们 在结构中感到舒适。我们不喜欢模糊不清的情况，因此尽可能避免它。

但正是在这里，创造力和创新才能蓬勃发展。

反抗框架：协作即工艺

在我职业生涯的早期，我为一位极度推崇 流程（The Process）的人工作。所有事情都必须严格按照手册执行；在我动手之前，我必须（正如道格拉斯·亚当斯在《银河系漫游指南》中著名地写道）：

“……三联签署的订单，发送出去，又被退回，查询后丢失，找到后又被公开审查，再次丢失，最后埋在软泥里三个月，随后被回收做成火柴棒。”

我的老板有他的理由，而且这些理由其实并不算坏。问题在于他选择的心理影响：

• 流程的设计是为了 让人放慢脚步。
• 你 必须在系统中提交请求。
• 你 必须跳过层层障碍。
• 你 必须遵循程序。

流程的每一步都把责任推回到请求帮助的那个人身上。

于是，没有人 喜欢 与他合作。他们来找我们团队寻求帮助，因为自己解决不了……结果却被让去填写表格或其他琐事。

当他离职，我接手团队时，我知道我们面临着一个严重的士气问题，于是我采取了相当非传统的做法：

我彻底取消了整个流程。

需要我们的帮助吗？直接联系并提出请求即可。我不会让你为了我能在半小时内完成的事而去填一张表格。

我们的工作？

想想你刚才的请求。我 要如何记录 我的 工作？不是让别人来做记录！如果我需要跟踪某些事情，责任在 我 身上，必须自己去跟踪。

这样做赢得了向我们寻求帮助的团队的好感。它消除了我们为跟踪文书工作而维护的 整个系统。虽然这不是教材上的解决方案，但它 极大 地帮助我们重建了团队的声誉。

当框架是正确的选择

显然它们有一定价值，否则它们根本不存在，对吧？那么我们什么时候该构建框架，什么时候该容许一点混乱呢？

• 框架不适用于未知领域。
  如果你在探索新技术或尝试“非传统路径”的东西，就不需要构建框架。它会在你快速转向和实验时妨碍你……每次方向改变都重新构建框架既昂贵又慢。

• 框架适用于流水线式工作。
  如果你在大量构建相同类型的东西，框架可以帮助你省去繁琐的设置，专注于结果。

• 特种部队 vs. 常规步兵。
  把框架想象成普通步兵——侵略行动由特种部队先行，一旦他们稳住阵脚，常规步兵就会进来巩固。你需要它们，但不要把它们放在前线！

结束语：舒适区的代价

正如我之前提到的：人类 热爱 结构。他们在结构中感到安全；他们觉得自己免受 “未知” 的威胁。

而且 这没关系。

我们在这里讨论的并不是完全抛弃所有形式的结构；而是呼吁辨别。要意识到 混乱会存在，并且 愿意偶尔陷入混乱。

停止把所有事都框架化，只专注于做好工作。有时需要深入模板化，也有时只需要 把事儿做好。