糟糕的软件设计：幻想出来的问题

翻译 ：蔡雪丹

欢迎访问网易云社区，了解更多网易技术产品运营经验。  

有许多因素可以成为糟糕的软件形成的催化剂：从正在使?的?具，到团队沟通，到开发?员在推动 其成功上可获得的个?利益，再到测试?法。 

我认为在这其中有?个主要问题，?个?乎可以作为所有软件变成糟糕软件推动?的根源:幻想出来的 问题。 

?多数复杂或坏掉的软件并不是设计得过于复杂或功能失调，它只是被设计做了很多超出预期?的的 事情。 

假设你是?个播客主持?，你想要定制?个?站可以销售你的?告产品，在没有第三?介?的情况下 赚钱，最重要的是，可以向你的观众提供播客、视频和博客。 

• 你的?web应?的需求可能如下所示: 

• 在北美?络下有较短的加载时间，可以实时播放和下载博客流。

•  99.99%的?户?少在头15分钟内不会崩溃或卡住，最好始终不会崩溃或卡住。

•  如果有时间的话，最好可以与?歌?告以及其他?些第三??告提供商较好地集成。 

• 动态链接到??Zazzle商店的最新产品，如果可能的话，可以根据?户消费的内容向他们提供建 议。

•  与Facebook实时播放器集成。如果可以有?个不需要Facebook流媒体的替代解决?案就更好 了。       

你把这些需求给了?个承包商团队，然后你与他们聊了?会?，似乎每个?都明?的你意思。然?， 两个?后，当他们带着最?可运?产品（MVP）回来时，你的脸变红了。你发现你只是在?块垃圾上 浪费了15000美元，你想要回你的钱。  

 因为第?次打开应?程序时，屏幕会卡住。你问他们如何选择允许在?站上运?的?告类型，他们指 出?个丑陋、难以让?理解的?定义??( UI )。半数Zazzle商品链接是断开的或丢失的图?， Facebook直播流的也有延时！ 

但是开发者团队对你的?愤感到很困惑—从他们的?度来看，这些都是理所当然的–因为他们已经经 历过地狱式地开发之后回来找你了。 

他们全?全意创建了这个应?，它拥有?些惊?的功能： 

• 最先进的推荐系统

•  实时?成所有流副本的算法 

• ?屏加载时间在全世界?络内都可以低于200ms

•  流媒体协议和客户端?乎都是重头构建的，因为不想依赖Facebook直播 

• 这项服务可以让你轻松整合20多个?告交易     

  这个问题在于你想你的核?产品拥有?堆额外的功能，如果它们易于实现的话。但是开发团队听到的 是不?样的东?，他们听到了?些对他们来说可以攻克的挑战…以及?系列?聊、基础，他们根本不 想去测试或者关?的功能。 

更糟糕的是，你没有直接与这些开发者进?沟通—你就像在玩电话传声游戏?样进?沟通。你和?个 销售?员谈过，他和?个中层管理?员开了会，这个管理?员写了?些业务规范交给了PM，PM写了 技术规范交给了团队负责?或?程师，最后，这个?和他的团队开始设计这个产品，每个?在设计的 过程中或多或少也都加了些??的曲解。 

更糟糕的是，你没有直接与这些开发者进?沟通—你就像在玩电话传声游戏?样进?沟通。你和?个 销售?员谈过，他和?个中层管理?员开了会，这个管理?员写了?些业务规范交给了PM，PM写了 技术规范交给了团队负责?或?程师，最后，这个?和他的团队开始设计这个产品，每个?在设计的 过程中或多或少也都加了些??的曲解。 

?多数程序员希望得到报酬，同时享受乐趣。当然，“乐趣”的定义对每个?来说都不?样，但对许多 ?程师来说，它归结为解决可解决范围内的有趣且富有挑战性的问题。 

给?个有点聪明的?太多?法?动化的?聊任务，你最终会让他发疯。然?，经过数?亿年的进化， ?类的?脑在保持理智???常有天赋。就像童年困苦或虐待的受害者可以在幻想书中找到逃避，企 业中或者进??由web开发的受害者可以在解决想象中的问题时获得解脱。 ?个软件?程师可以想象出来问题的数量取决于他们的想象?，也取决于他们应该解决的真实问题难度。 

应该注意的是，这个问题并不是开发者独有的，管理部?、销售部?、??部分、后勤?持、法务， 甚?会计部?都有他们独有的?式来创建想象中的问题。当他们没有被要求或者形式性地参加某?会 议时，会试图让??更多地参与决策。他们过分强调某个与他们??相关的?问题，或者招募更?的 团队来说明他们的重要性。 

当问题变得愚蠢时，聪明的?总能找到解决的办法。 

但是很多想象中的问题并不仅是?聊的开发者造成的，它们也有可能是?沟通链产?的结果。 

当我第?次开始接触?由职业客户时，不可谓不过分周到。我们电?邮件的交谈链已经持续了100多 次，仅仅讨论关于内部MVP的?些?关紧要的细节。我让?在?周内改动了项?的每?项要求，我问 了?户?些问题，?如“这是ICO吗者“我们能在这?添加?些??智能元素吗 

诚然，?多数客户都?这更精明，但即使如此，他们经常缺乏表达或构建?些需求所需的知识。这很 好，作为我“计算机?员”职业的?部分，我的?作就是帮助?们根据他们的?例指出他们想做什么和 不需要什么。但是当你和客户之间隔了好?层进?沟通时，确定需要什么就变得更加困难了。 

需求变更是因为有?误解了?个意图，或者是因为有?试图应付上述?聊的需求 

?多数公司喜欢由?个销售?员对潜在客户进?推销，协商价格，并概述可能的功能。他们也专?有 ?个?与客户讨论更深?的需求和细节，这通常是另?个销售?员，但职别略有不同。然后是技术团 队内部的指挥链、各种级别的管理，可能还有?些其它层级结构。 

当?份客户需求列表流转很多?时，即使这些?拥有最好的想法，?些东?也不可避免地会在层层翻 译中丢失。有时，这种变化是因为最初的需求没有意义，或者有时需要重新定义需求。销售?员可能 会告诉客户，“只需额外?付39，999英镑，我们就可以在区块链做这件事。但这让所有遇到需求的? 都想知道“在区块链上做”的定义是什么。” 

很多时候，需求会改变是因为有?误解了?个意图，或者因为有?试图应付上述?聊的需求，试图让 他的?作或者他团队的?作更有趣，更令?印象深刻。 

因此经历所有这些，最初的需求—真正的问题在这过程中已经被溶解了—丢失了。它们被想象中的问 题和空洞所取代，并且你会发现很多?已经准备好?他们想象中的问题来填补这些空洞，因为他们真 正需要解决的问题很?聊，填补这些空洞给了他们?种?法来应对这种?聊。

过度复杂化和?然选择 

想象中的问题的存在往往有更阴暗的原因:问题可以帮助团队或公司成?，甚?可以成为其功能不可分 割的?部分。 

那些通过被培养、挑选和补偿来寻找复杂解决?案的?往往没有动?去实施简化的解决?案。 — Nassim Nicholas Taleb 

你听过那三位web?程师吗们发现安全的?上银?其实是?个很容易解决的问题，他们从零开始 开发了?些完美的银?软件，使?功能设计?法论和内存安全语?，然后开始将主要银?迁移到他们 惊?的基础设施中。 

也许你没有听过过他们，因为他们不存在。然?，有许多由成千上万的开发?员组成的团队，他们? 法掌握像“回滚”这样的简单概念，从?不断创造银?软件。 

数字的存储和传输并不是?个特别困难的问题，检索整个互联?内容并在短时间内为?然语?查询提 供相关结果是?个难题，但也?个聪明?设法去解决这个问题。 

但是?上银?业存在的问题是，银??身的?态系统已经?分善于维持??的赚钱等级，它的领导者 是腐败的?蛭，他们掠夺社会–但组织中的领导者只是其成员的?个症状。 

我不认为?多数银?下属员?是邪恶或怀有恶意的，与此相反，他们通常是?些友好的?伙?，为家 庭提供?物、住所和教育，但是他们的主要动机并不是修复银?软件，?是保住?作。对?些?来 说，这今天的经济形势下失去?作不是开玩笑的事；在银?业，嘴巴?或太过主动表现很容易在纪律 委员会?前暴露??。 

因此，银?系统仍然保持原样–不是因为这些系统是?效的，?是因为惯性。这种惰性的表现形式是 为了解决想象中的问题，以避免解决真正的问题。—真正的问题?旦被指出，就会威胁到其他?的? 作。聚焦于这些真正的问题可能会导致被解雇，甚?，在?些特别恶劣的“机构”，?如?盛，让?个 毁灭?活的棕?信封送到联邦调查局那?会引发奇怪的?杀。 

当?个?的薪?取决于他对某件事的不了解时，要让他了解某件事是很困难的!- — Upton Sinclair 

?层管理员忽略了这样?个事实，即他们的上层管理?员的90 %的时间都花在“客户会议”上，这些会 议涉及热带岛屿和数百万美元的“其它费?”预算。作为回报，这些上层管理?员对他们上级的腐败视 ?不?。 

上层管理?员忽略了那些购买古怪办公室并给??雇?三名秘书和??名实习?的中层管理?员，因 为中层管理?员?励他们?活在华尔街的幻想中。 

中层管理?员也忽略了这样?个事实，即?产线管理层把时间都花在了关于“改进我们的敏捷?法”的 PPT演示上，??削减成本，因为?产线管理层并不抱怨他们的独裁权?幻想。 

?产线管理层则忽略了团队负责?和架构师谈论的“我们使?JRPC的系统和使?Hibernate和Spring的 微服务之间的下?代接?”，所以当他们应该?不到?天的时间来处理那些该死的MySQL查询。因为 团队负责?似乎没有注意到他们的上级甚?不能正确使?Excel，并且仅仅只是隔?周来?次办公室。 

团队负责?并没有抱怨他们的开发?员，?是查看了前?提到的缓慢查询的解释，并在那年第?次使 ?新的JavaScript框架重新设计UI。因为开发?员似乎没有注意到他们的领导除了DOT图之外没有真 正编写过任何代码。 

这是?个解决想象问题的恶性循环，从没有意识到再偷3000万也不会让他的?亲爱上他的CEO，到没 有意识到使?Angular-Material-Bootstrap 19.13.5重新设计“提交”按钮并不会让他们以明?形式存储 密码(并将其作为授权cookie的?部分)的事实消失的UE实习?。 

但是每个?都需要继续解决想象中的问题，因为如果他们停?制造和解决这些问题，如果他们开始关 注真正的问题，他们可能会意识到整个系统已经崩溃。他们可能意识到Debra已经坐在那个?落?， 盯着内部服务器集群的正常运?时间图看了10年，尽管该公司五年前搬到了AWS。他们可能意识到他 们99 %的?作是让别?的?作永垂不朽。这是?个难以接受的事实——我敢说，对?多数?来说是不 可能的。因此，?多数?找到了?种应对的?法。

原文：https://medium.com/s/story/imaginary-problems-d4f2921bd1b8           

免费领取验证码、内容安全、短信发送、直播点播体验包及云服务器等套餐

更多网易技术、产品、运营经验分享请点击。

相关文章：
【推荐】 windows系统下npm升级的正确姿势以及原理
【推荐】 理解DDoS防护本质：基于资源较量和规则过滤的智能化系统
【推荐】 Spring Boot 学习系列（05）—自定义视图解析规则

来源：jessicaiu