公司为何不修复漏洞

共有 92 条讨论

1. 很多时候，缺乏漏洞修复是由于管理层建立的激励机制造成的。具体来说，你很少因为修复问题而获得奖励。你能得到奖励的是新产品的发布。实际上，你会因为修复问题而受到惩罚，因为你没有时间去开发新产品。

   所有权是另一个问题。例如，负责交付新产品但支持现有产品的产品团队越来越多地被推给支持团队。这其实也是激励结构的结果。

   这也是我不认为所有订阅软件都不好的部分原因。Adobe 一端是坏的。而 Jetbrains 则是好的。创造优秀、可靠的软件是有价值的。如果你的唯一收入来源是新的销售额，那么错误就更不是优先考虑的问题了，直到它严重到让你的软件几乎无法使用。而通常情况下，你需要花很长的时间来解决这些问题，并对许多警告置之不理。

   回复

   1. ……但对现有事物的支持却越来越多地被推给支持团队。

      支持团队不会修复错误吗？

      回复

      1. 你剥夺了支持团队的自主权，这会打击他们的士气。

         现在的问题是，你有两个团队，一个团队在快速开发、添加新功能，这些功能对支持团队来说往往是毫无意义的，而另一个团队则在事后进行清理。当清洁工一点也不好玩。

         这样会产生怨恨，即 “他们为什么要这样做？”。

         编辑：如果让功能团队必须获得支持团队的批准，就会剥夺功能团队的自主权，从而引起他们的不满（即 “他们为什么要拖我们的后腿？ 我们需要这样才能完成 KPI！”）。

         回复

         1. 除此之外，支持团队往往人手不足，负担过重，而功能推动者却能获得更多职位。

            回复

   2. Jetbrains 仍然喜欢对你施加压力，说你对错误或功能的看法是错误的。

      最近的一个例子是删除提交模式。

      回复

      1. 整个新用户界面的失败确实奠定了基调和期望，我认为他们不会改变。他们现在似乎变成了另一家公司？也许我过去没有注意到。

         回复

         1. 对我来说，他们抄袭 Adobe 的用户界面，去掉图标上的颜色，因为 “会分散注意力”。

            如今，他们抄袭的是 Vs 代码。

            回复

      2. jetbrains 的模式是每个新版本都会修复一个要命的关键 Bug，并新增两个会让你抓狂的关键 Bug。我最终忍无可忍，跳下了这辆车。

         回复

         1. 去哪里？对于许多技术堆栈来说，根本没有可比性。多年来，我一直在寻找替代品（我也受够了他们对错误和性能的漠视），但没有（除了适用于 Windows 的 C++/C# 的 VS）。

            回复

            1. 可悲的是，我只能接受更糟糕的工作效率。其实我别无选择，他们的错误会破坏我的工作流程，比如导致构建失败。这无疑让我更加沮丧，也降低了我的日常工作效率。

               回复

         2. 公平地说，它似乎平均为 1:1，有一些激增和消退。

            回复

         3. 我不太明白你们在说什么。我使用 Rider 已经很多年了，它一直很棒。我正在使用新的用户界面，在提交或其他方面没有任何问题。

            最近我加入了一个新团队，在那里我必须使用 VS，因为我们必须通过远程桌面工作，而在远程桌面上安装新东西需要一个漫长的过程。实际上，我在写代码的每一秒都在想念 Rider。我所需要的一切，VS 都能做得更好。

            我希望随着时间的推移，我能更适应它，但到目前为止，我还是很讨厌它。感觉它比 Rider 明显降低了我的速度。

            回复

      3. 什么时候才能最终移除？我仍然在每台机器上恢复到旧的对话框。

         回复

         1. 在目前处于测试阶段的下一个版本中，但他们同意将其移至不支持的插件中。不知道仍然有效的 idea.properties 设置是否会被移除。

            https://youtrack.jetbrains.com/issue/IJPL-177161/Modal-commi…

            回复

   3. [deleted]

      回复

      1. 你自己评论的语法也好不到哪里去。

         回复

2. 这在大型组织中并不奏效，但如果你经营的是一家小公司/初创公司，只需让一名工程师时常 “帮忙 ”提供支持即可。当工程师休假时，我们会请开发人员来管理支持台，同时也会让他们轮流值班。

   这不仅有利于建立客户同理心，还能帮助产品开发人员了解产品的使用情况。从这些经历中建立起来的直觉非常强大。

   此外，在处理同一问题的支持票据大约两个小时后，99% 的开发人员会直接修复问题。因此，你可以为错误修复创建一个非常优雅的激励结构，从而规避很多传统的结构性问题。

   当然，大公司做不到这一点，这也是规模带来的结构性弊端之一。

   回复

   1. 或许也应该让项目经理和工程经理参与进来，这样你也可以摆脱 “你为什么要在这上面浪费时间 “的对话。

      回复

      1. 最好是取消这些职位，通过公司所有权来激励工程师。

         回复

   2. 为什么大公司不能这样做？如果得到管理层的支持，你就能做到。

      回复

      1. “支持 “通常是不同的组织，可能是外包的，可能在不同的国家。

         用户群是不同的，在一家小型的 saas 公司，你可能会收到相当 “高信号 ”的投诉，但对于大众市场产品来说，情况并非如此。

         修复错误也不一样，有时你需要跨越 3 个不同时区的团队，开一堆会议才能修复一个错误。通常情况下，真正的问题是业务流程或遗留系统出了问题，而单个开发人员并不具备政治 “摇摆 ”能力来解决这个问题。

         大公司的组织结构通常会限制集成电路的代理权。

         回复

3. 解决的办法就是建立竞争对手，掠夺他们的市场。

   公司基本上不可能找到能达到所需水平的经理人，以免最终沦为 “现在功能更多 ”的钝器。

   只要找到那些已经达到这种停滞状态、积压严重的公司，订阅他们的产品并对其进行研究，以正确的方式从头开始重建，并将该公司的名称作为关键词贴上广告。

   然后，当你最终开始扼杀他们，而高层的 MBA 傻瓜们又急不可耐地裁员时，挖走他们没有裁掉的最优秀员工，问他们 “他们裁掉的人中，你会留下谁”，并向他们伸出橄榄枝。

   基本上，这是 “解决 ”这种局面的唯一办法。

   回复

   1. 但我只希望我用的软件不要太差。

      我不想开公司、找资金、雇开发人员、制定市场策略、A/B 测试、调整、再调整，最终可能发布产品，也可能被收购。

      我只想在我孩子学校的通讯应用程序中右击和/或高亮显示一些文字。

      回复

      1. 如果你想从头开始做一个苹果派，你必须先发明宇宙；如果你想在你孩子学校的通信应用程序中右键点击和/或高亮显示一些文字，你必须先创办一家公司，找到资金，雇佣开发人员，制定市场战略，进行A/B测试，调整，再调整，最终也许会发布一款产品，也许只是被收购。

         回复

4. 就我个人而言，作为开发人员，即使是在功能非常不健全的组织中，我也从不觉得在没有项目经理批准的情况下修复我认为有问题的东西有什么问题。有时，它甚至会引起注意，人们会为你鼓掌。

   换句话说：虽然我承认文章中描述的现象是真实存在的，但有时我觉得这只是因为开发人员接受了一个不需要被接受的现实。

   回复

   1. 但修复一个错误需要你（主要是做调查）和其他人（代码审查）的时间。因此，如果整个团队都在开发一个 “重要 ”的史诗（这是指有截止日期的史诗，就像其他史诗一样），而你却在不告诉任何人的情况下突然提出一个与史诗无关的错误修复：那就太奇怪了，不是吗？你的 EM/PM 会问你为什么不优先处理史诗任务，而你的同事可能会说他们无法转移注意力或抽出时间审查你的修复（更何况这是 EM/PM 尚未批准的事情）。

      因此，除非您工作过度（例如，您在完成 jira 任务的同时还在修复错误），否则我看不出这一点。

      我很想做一些有意义的事情，比如稳定系统什么的，但我做的都是能卖出去的东西，或者是 EM/PM 想要的东西。不幸的是，这些天来，出货>>修复。

      回复

      1. 根据我的经验（尽管有限），工作周是有空闲时间的，这种空闲时间可以提供所需的时间来做一些随意的事情。

         我认识到，在一切都由微观管理、工作时间以小时甚至分钟为单位、不存在自主权的组织中，情况并非如此。

         员工越是被当作负责任的专业人士对待，就越有可能做到这一点。反之，员工越像传送带上的工厂工人，这种可能性就越小。

         回复

         1. 在一些组织中，员工人数被削减到了极致，一切都到了紧要关头。

            回复

            1. 公司明确决定贬低质量和中长期成本的情况还是很少见的，这通常是激励措施的副作用。

               显然，“假敏捷 ”是一个行业性问题。但是，如果团队无法控制他们的能力预期，就会演变成

               “松弛 ”这个词用得不好，但在这里确实如此。

               在那些关心中长期生存和成功的公司，随着时间的推移，可以解决这个问题。

               在战略和计划的时间尺度上，将其作为降低风险来销售，就是一种可以帮助解决这个问题的方法。

               回复

      2. 如果你暂时处于 “让我们在最后期限前发货 “的模式，当然可以。

         而如果你_始终_处于截止日期模式，我认为你的问题就更大了。

         回复

      3. 如果对开发人员进行微观管理，以至于他们在没有得到某人允许的情况下不能花一点时间来修复一个 Bug，那是非常不正常的。不幸的是，业内大多数公司都极不正常。

         回复

      4. 1. 在进行毫无意义的视频通话时编写修复代码。

         2. 3. 万一有人对你提出质疑，就说反正你也需要在这方面进行修改，这样可以减轻支持负担。

         回复

         1. 这需要公司内部开发人员的热情和动力。在无意义的视频通话中，他们有很多事情可以偷懒，但他们必须选择把时间花在不劳而获的漏洞修复上。

            回复

         2. 这是引入回归的好方法，尤其是当你没有足够的 QA 资源在每次发布时进行完整的回归测试，并且缺乏自动化测试覆盖范围时。

            我这么说并不是要责备你，但我认为我们大多数人都应该牢记，即使是简单的代码更改也会带来风险并增加测试要求。

            回复

      5. 也称为敏捷™方法

         回复

   2. 取决于公司。

      我曾在禁止我修复错误的地方工作过。即使是与我正在编辑的代码相邻的一行。

      那里的老板曾经在亚马逊工作过。我想这不是一个简单的巧合。

      回复

   3. 我不会加班加点地去修复那些管理层认为没必要优先处理的漏洞。

      回复

5. 这要看情况。还有其他一些原因

   1. 这是一款企业级产品，经济买家对 Bug 的了解和关心程度远不及对功能清单的了解和关心程度。

   2. 公司没有将修复漏洞的影响与底线联系起来。或者说，他们有，但估计影响不大。

   3. 代码库到了重写的时候，因此重写是一种浪费。

   4. 这只是一个附带的赌注，不值得投入额外资源。

   回复

   1. 根据我的经验，还有第五种可能： 如果客户没有意识到漏洞，“修复漏洞 ”是否会导致他们因为应用程序现在的行为与预期不同而提出投诉？

      我还遇到过几个 “承重错误”，在这些错误中，后续的集成/工作流程都是为了适应该错误而设计的。有时，这是因为错误是已知的，但当时无法修复；有时，开发人员认为程序工作正常，并将错误视为预期行为而加以处理。

      因此，修复原始错误会引发其他需要更新的问题。

      回复

      1. 我喜欢把这类错误称为 “地雷”。它们隐藏起来，直到你踩到它们，然后一切就都乱套了。

         回复

         1. 永远不要低估系统稳定状态的力量。有时无为胜有为）

            回复

      2. 义务 xkcd: https://xkcd.com/1172/

         回复

   2. 献给所有手机开发者：

      5. 修复一个 Bug 意味着你必须重新审核你的营销资产，而这些资产在 3 年多的时间里从未改变过，而且每次审核都有可能导致_你的应用从商店前台下架_，在你安抚了之前提交的数百次并不是问题的异想天开的问题并等待下一次审核之后，你将损失_天_的收入。

      回复

   3. 我们做的是低利润行业的利基 B2B 软件。对我们来说，这无疑是第一点。

      我们当然会修复严重的问题，但我们也会让许多错误在我们的跟踪器中蒙尘。

      虽然我知道我们的客户对错误很恼火，但他们更关心的是基本功能和低价格。

      现在，我们正在逐步重写已有 20 多年历史的软件，代码质量是重中之重。因此，希望未来会更加美好。

      不过，我们的用户非常善于发现奇怪的问题。

      回复

   4. 1 和 2 是我参与过的所有大公司的实际答案。这很简单：修复漏洞是否会在短期或中期内影响资金流？如果会，就修复它。如果不会，那就去做能扩大资金流量的事情。

      3 有时是口头上说说，但最终 3 能完成的唯一途径是上层管理人员中有人假装关心 3 的重要性。这是很罕见的

      4 也会发生，但每个人都认为自己是臭鼬工程的工程师，即使他们不是

      回复

   5. 在工作中，我们有时也会把错误修复的推出时间推迟一个月或三个月。如果客户正处于圣诞节/年末/活动高峰期，一个已知的错误（只需一分钟就能解决）有时比一个未知的修复（可能会导致整个运行停止一小时）要好。

      回复

   6. 对于我所支持的许多产品，我怀疑真正的原因是他们最初聘用的是外包程序员，或者多年来解雇了大部分内部程序员，因此根本没有能力以经济有效的方式修复简单的问题。这就是为什么他们总是试图把你推到下一个重写的程序版本，而不是继续支持现有版本。

      回复

6. 这正是产品完全接管开发团队，而他们对自己的技术没有任何控制权的结果。开发团队应该始终有 x% 的精力用于开发人员的工作。

   回复

   1. 修正他人的低劣代码并不能推动公司的发展，尤其是在一个努力让客户打开钱包、掏出硬通货的行业。

      如果一家公司的终极目标是从人们身上榨取金钱，那么那些能更快榨取金钱的开发者（即使他们的渲染/加载算法很烂）就会比那些不能更快榨取金钱的开发者获得更好的回报。

      这就是 “enshittification ”出现的原因（其实仔细想想，这也不是什么新鲜事）。可能是开发人员从产品领导层那里了解到：”我可以修复这 13 行代码。但你要知道，我们公司还可以以每月 5 美元的价格出售’专业’版订阅，它可以提供修复功能……”

      回复

      1. 是的，这很可悲，但这就是现实。关心你的手艺是为了你的激情项目/业余爱好。一旦你的精美软件遭遇现实世界和商业，一切都会分崩离析–你可以采取心平气和的方式来接受它，或者让它把你逼疯。

         我们的目标是写出不差的代码。你不是故意偷工减料，但足够好就是足够好。

         回复

         1. 我不一定同意这种观点。

            很多开发团队都很关注用户体验/外观。很多独立游戏都是用爱精心打造的，而且往往很多都取得了成功 — 甚至在进入 steam 商店多年后还发布了错误修复和更新。许多高级开发人员学会了如何快速编写出优秀的代码，这不仅是为了他们自己，也是为了后来者。

            如果有好的论据，大多数人都会同意逻辑。遗憾的是，许多商业决策都是闭门造车，以避免异议，甚至避免讨论替代方案。

            回复

         2. 这是事实，但一家不能提供优质软件的软件公司最终会比一家能提供优质软件的公司做得更差。

            最终，真正提供价值是无可替代的。

            回复

         3. 生活中不处处都是如此吗？

            从宜家买家具的人远远多于喜欢木工活的工匠，这是有原因的。

            人们一般也不会为服装、房屋建筑、车辆、食品 …. 的手工艺支付高价。

            回复

            1. 他们可能会为这些选择中的某一个支付高级手工艺品的费用。这种情况很常见。

               回复

         4. 不过，事情并不一定非得如此。作为一个社会，我们选择接受这种状况。我们应该接受吗？

            回复

7. 我个人一直很喜欢防火冲刺。每隔一段时间（一年 3-4 次），在其他大型工作之间，花一周时间让开发人员自由支配，单独修复他们认为最重要但似乎从未被优先考虑的问题。

   是的，这说明产品和工程之间存在脱节，但同时处理这种关系并不意味着两者都不值得去做。

   回复

   1. Shape Up 模式（最初来自 Basecamp）在每 6 周的 “构建新内容 ”期之后都会有 2 周的 “冷静期”。我们还指定其中一周为 “错误突击”。每 8 周中的 1-2 周确实有助于鼓励修复问题，而不仅仅是开发新功能。

      回复

   2. 作为工程主管，我正是这么做的。效果很好！

      回复

8. > 所有权旋转门

   就是这个。每个行业都有这种情况。事情之所以会出现裂缝，是因为没有人愿意承担弥补裂缝的责任。因为这通常是一份吃力不讨好的工作。公司里的瑞士军刀/修补者/制度知识守护者默默地支撑着一切，而那些上进的人则确保聚光灯始终聚焦在他们身上。

   回复

   1. 快速发展也能让你免于承担责任，但却能让你累积可感知的收益，即使这些收益最终并不存在（同样，缺乏责任感）

      回复

9. 让我们在此明确一点：公司会修复漏洞。很多很多的错误。

   本文所说的是 “一些错误”。虽然企业的惰性可能会起到一定的作用，但由于各种原因，错误也会被忽略。这很难一概而论。

   例如，有些错误之所以没有被修复，是因为它们很难被复制。当错误很少发生时，就很难对其进行调试，也很难知道修复是否有效。

   其他错误则与外部环境因素有关。比如 AV 表现不佳，或以奇怪的方式与机器交互。

   有时，错误报告非常模糊，缺乏细节，坦率地说毫无用处。我都数不清有多少 “我做错了什么 ”之类的问题，它们似乎认为我是个灵媒。

   有些错误很难解决。非常难。人们会尝试解决，但一段时间后就会放弃，转而去做其他事情。在这种情况下，“修复 ”的结果往往比 Bug 更糟糕，会产生各种副作用等等。

   在某些情况下，错误会被保留下来，因为修复它们会破坏其他东西。例如，如果修复了 C 标准库中的错误，就可能会破坏依赖于该错误的程序，或破坏解决该错误的程序。

   这还只是冰山一角，还有几乎和未解决的漏洞一样多的原因。

   是的，在资源分配方面，有些公司会优先处理某些漏洞，而不是其他漏洞；有些公司会优先处理新功能，而不是漏洞。

   回复

   1. 我没有把标题解析为 “为什么（公司不修复漏洞）”，而是把它解析为 “为什么公司（不修复漏洞）”。

      这篇文章并不是在论证 “公司普遍不修复漏洞”，而是在解释在公司不修复漏洞的情况下，他们为什么不这样做。

      有点像你看到一篇关于求职的文章，标题是 “为什么雇主不回应”

      回复

      1. > “为什么公司（不修复漏洞）”。

         我真的不知道这是什么意思。它与 “为什么（公司不修复漏洞）”有什么不同？

         回复

         1. 这是语法上的一点歧义。

            “X don’t Y ”一般是指 “X 从不 Y”（例如：“葡萄不长在树上”）。

            然而，在 “X Don’t Y ”前面加上 ‘Why’（“为什么 X Don’t Y”）并不一定表示 “X Don’t Y. 为什么？- 相反，有时它实际上是在问：“在 X 不 Y 的情况下，为什么不？”

            换句话说，你不一定能通过简单地解析 “X Don’t Y ”本身，然后将 “为什么 ”作为一个问题应用到这个句子中。这就是我想说明的。

            回复

10. 清单中缺少一项：

    如果你的产品存在一些恼人的错误，你的客户就会抢着购买下一个版本，因为他们会相信这些错误会被修复。

    微软使用这一策略取得了巨大成功。

    回复

    1. 鉴于现在每个产品路线图都希望把人工智能塞进每个角落，也许最好的办法就是忍受你所知道的 Bug。

       回复

11. > 现实一点吧：改善加载时间并不会直接影响底线。销售鲨鱼卡（《GTA》的虚拟货币）才会。公司优化的是季度收益电话会议上显示的指标，而不是商誉或用户体验，直到为时已晚。

    我不知道… 我曾经放弃玩《GTA V》，因为载入时间太长了。后来我换了台新电脑，虽然载入时间还是很可怕，但我终于完成了单人游戏。我还遇到了一个 Bug，那就是当我启动游戏时，帧数会非常慢，而且有些纹理无法加载。

    这款游戏很不错，也许我还会重新玩这款游戏来玩多人游戏，但该死的载入时间让我感觉启动游戏就像一件苦差事。我大部分时间都是在工作之余抽出一点空闲时间玩游戏，我可不想把这些空闲时间浪费在盯着载入屏幕或因为随机 Bug 重启游戏上。

    回复

12. 这引起了我们团队的共鸣。在过去的几年里，我已经看到同样的问题出现了 3 次，陷入了同样的循环。是好是坏。很可能是更糟。

    回复

13. 错误是有等级之分的。

    是崩溃吗？

    有解决方法吗？优先级较低。

    像 GTA 载入错误这样的性能问题很难量化。

    错误是否已被归档？也许没有，因为在互联网上它很慢，但在 10g 开发人员网络上它从未出现过。

    如果已经提交，谁又能保证加载不需要那么长时间呢？昂贵的工程师可能会在这个问题上转来转去，却得不到解决。

    回复

    1. > 像《GTA》加载错误这样的性能问题很难量化。

       对于 1/3 的玩家群来说，加载时间超过 6 分钟（根据关于该错误的原帖中链接的一项民意调查）并不难量化，这简直是灾难性的。到那时，很多人都会干脆退出，改玩其他游戏。

       回复

14. 是啊，我也经历过这种情况。这些优先级排序的事情，这些在 Jira 中钻漏洞的行为，等等。

    不过，这只能说明公司必须开始改变优先级。就我目前在市场上看到的情况而言，公司唯一的货币就是钱。我知道这听起来很愚蠢，对吗？不，我的意思是，它曾经是信任。信任曾经是货币。我记得惠普给我换新显示器的时候，只是因为我给他们打了电话。没有任何验证，快递员带着新货来了，却拿走了旧货。

    现在，信任就在最后一页，如果有人敢说它存在的话…… 公司关心投资者，投资者关心股价上涨。在这种反馈循环中，人是无法得到满足的。至少不是大多数人。

    回复

15. 不仅仅是大公司。出于类似的原因，在公司发展的各个阶段，漏洞都会被掩埋。

    回复

16. 在我看来，这是一个不称职的项目经理，他不会自己测试任何东西。如果他每天都要进行几次 JSON 解析，那么几天之内就能解决这个问题。

    回复

17. 这里是《GTA》的 JSON 错误：https://news.ycombinator.com/item?id=26296339

    回复

18. Huh. 我在金融相关行业工作，读这篇文章是为了了解重要软件功能缺乏进展的情况–与原作者的游戏背景正好相反。

    回复

19. 重复我一连串的推卸责任：

    1）我们不需要软件测试，因为我们有一个 QA 团队。

    2）我们不需要 QA 团队，因为我们只需注意用户的错误报告。

    3）我们不需要关注用户的错误报告，因为任何真正重要的东西都会在使用或销售统计中显示出来。

    4) 我们不需要关注使用或销售统计，因为这与我们的总体财务状况是多余的。

    5）我们不需要关注我们的总体财务状况，因为我们已经有了一个金丝雀，即从大厅拖出家具的回收人员。

    不同的公司对何时开始注意和关注漏洞有不同的标准。

    回复

    1. 我认为，考虑到软件的现状，第 5 条并不像它应该发生的那样频繁，而这正是它如此糟糕的原因。

       回复

20. > 实事求是地说：改善加载时间并不会直接影响底线

    是的，确实如此！

    在这一点之前，我一直同意这篇文章的观点，但这根本就是错误的。

    当《GTA》的漏洞成为头条新闻时，有几篇关于它的文章估计，由于玩家等得不耐烦而改玩其他游戏，它造成了大约 10 亿美元的收入损失。

    这才是真正的悲剧： 性能是一项功能，但几乎没有人承认它是一项功能。

    苹果公司却认识到了这一点。

    提醒我一下，他们值多少钱？多少万亿美元？

    如果 iPhone 每次都会随机卡住几秒钟，它们还能值那么多钱吗？或者需要十秒钟才能解锁？或者任何类似的问题，在无能的管理者心目中都不是 “功能”，但却是史蒂夫-乔布斯（Steve Jobs）强制执行的关键要求？

    不，他们不会。

    回复

21. 我曾在一家名为 Xero 的会计软件公司工作。我们引以为豪的是，我们制作的会计软件非常 “漂亮”，用户使用起来非常方便。当时我们有一个团队（有个不可思议的名字叫 “狙击手团队”），专门负责追捕和修复小错误、剪纸和用户体验问题。他们对代码库、产品和客户满意度产生了巨大的积极影响。

    我猜是这个理念没有得到回报，因为这个团队解散了，我们用来与客户直接交流的论坛也解散了。

    回复

22. 因为法律设计得不好，所以软件产品有漏洞是不需要承担责任的。

    回复

23. Discord 存在一个错误，即在通过桌面和网络客户端创建论坛类型的新帖子时，使用 HOME-SHIFT 键确实会移动光标，但不会选择文本。此外，HOME 键和 END 键还会跳转到文本框的开始/结束位置，而不是行的开始/结束位置。

    他们关闭了单子，并将我发送到他们的反馈页面，在这里我可以申请任何新功能，然后大家可以进行投票。最后，他们用 “在社区的帮助下，一切皆有可能 ”结束了拒绝。

    我在 5 年前创建了同样的票据，得到了完全相同的对待。

    作为用户，基本功能被破坏是一件非常令人沮丧的事情，而且每周都会反复遇到这种情况，因为习惯使然……然后他们被告知，除非有成千上万的人在他们的反馈门户网站上发现了你的错误报告并进行了投票，否则他们不会关心这个错误–就好像我的工作就是为他们确定优先级一样。

    这让人很不爽。

    回复

    1. > HOME 键和 END 键也会跳转到文本框的开始/结束位置，而不是行的开始/结束位置

       这是开发人员造成的后果，他们除了 Mac 什么都不用，甚至没有意识到这是错误的。对于绝大多数客户只能在 Windows 平台上使用的产品来说，这种情况尤其严重。

       回复

    2. 这个 discord 论坛新帖首页/末尾的 bug 完全让我头疼。你不是唯一的一个。

       回复

24. 简短的回答是（经常是）钱。

    回复

25. 由产品经理来决定 “开发人员 “应该做什么是你们问题的一部分。

    你的技术主管应该有权决定你的工作内容，并与业务需求保持高度一致，同时也要明白哪些地方值得权衡利弊。

    这篇文章的第 1-4 点确实很有道理，基本上可以归结为 “存在激励差距，没有人愿意牺牲自己来弥补这一差距”。

    回复

26. 在我上一家公司，我的头顶上大概有 10 个产品经理。每个人都要管理不同客户订购的一堆新功能。作为开发人员，你可以每天与不同的产品经理合作，因为每项任务都与特定的产品经理相关联。你认为他们中会有人关心这种不会阻碍他们宝贵功能的 bug 吗？当然不会。如果你试图与更高层的人讨论这个问题，你就会碰壁：”哪个客户会为我们修复自己的错误买单？好像更好的产品就不会有更好的市场，就不会在未来带来更多的钱。现在一切都与钱有关。猴子看到了钱–猴子的神经元被激活了。

    回复

27. 作为一名架构师，我负责修复漏洞和其他维护工作。我不会征求别人的同意。这是工作的一部分。

    如果你所在的团队管理层不允许你修复漏洞，那么你就有责任向管理层撒谎，无论如何都要修复漏洞。

    害怕失去工作当然是让产品烂掉的正当理由，但这并不能完全免除你的责任。

    回复

    1. 我曾经参与过一个项目，这个项目简直一团糟，他们把产品的质量保证外包出去，而离岸团队每发现一个问题就会创建数百份重复报告。他们还拿出 “烧毁图表”，以此为理由要求整个团队周末加班。

       我对此感到厌烦，于是找来其他几个开发人员，把我们之间的 jira 错误积压拆分开来，我们开始关闭重复报告和非重复报告，大约两天后，数千份报告被关闭，我的经理怒气冲冲地来到我的办公室，要求我停止这种做法，因为 “这会让公司看起来很糟糕”。

       有时候，最好的办法就是不玩。

       回复

28. 因为他们想要的是系统工程师，却雇佣了 “网络开发人员”。

    另外，这篇文章读起来就像人工智能的泔水，尤其是 “为什么好的 Bug 无法修复 ”部分。

    回复

29. 截止日期导致错误。

    回复

30. 谈论 343 工业？编辑：不是，但确实是。

    回复

31. 在一次工作中，我发现了三个漏洞。我做了分析/撰写，并提交了拉取请求，结果它们被尘封了 4 个月。

    我也不知道为什么。也许是政治原因（收购和认证）。也许他们不理解或不认可我使用的统计数据。也许他们不认为这是一个问题，因为他们认为没有发生过任何事件。

    在我的印象中，代码越有漏洞，他们就越不关心安全问题。

    回复