… - 如果客户发现我们进行了完整的重写，他们也会在他们这边进行完整的回归测试。你知道这会给我们带来多大的麻烦吗？我们过去 XX 年里为构建这个集成所经历的每一个问题、难题、功能变更、错误、改进、沟通、_所有的一切_都会重新浮现。我将不得不重新审理每一件事。"既然你们在处理我们的集成，我们能获得 XX、XX 和 XXXX 吗？"（每个都需要至少一个冲刺的开发时间），"YYY 无法工作，你们又把它搞坏了？"（它一直都有问题，但现在有人会花 3 个小时在 Datadog 中提取日志来证明这一点）。- 我一直用“重写这个库”和“重构那个服务”项目作为杠杆，来争取更多的预算，以增加两名员工，这样我们才能真正有时间和空间来完成这些重写。你谈论在周末完成 80% 的工作完全削弱了我在这项工作上的努力，同时也没有从我的待办事项中移除重构的问题。…
源讨论掌握产品经理的“不”艺术原帖 168 条评论 · 导入时统计我曾经在一个与第三方API集成的应用程序上工作过。它这样做的方式是使用一个庞大而糟糕的客户端库，该库使用单独的数据库来缓存数据。 然后从主应用程序中获取数据，并每天一次基于此数据重建主数据库中的页面。 这个库有很多问题，有一天它停止工作了。我被指派来修复它——我们有源代码，它是从某人那里购买并复制到仓库中的。我花了一周多的时间，甚至更久，试图弄清楚哪里出了问题，但没有成功。我学到的是，这个库是我见过的最糟糕、最无用的代码之一。 所以我告诉团队，我认为我可以从头开始重建这个东西，比修复这个错误更快。中间的数据库是多余的，大部分库代码已经过时了，其余的都是垃圾。我可以做一个简单的小东西…
完整原文把你的经验，加入这段讨论。
这个回复展现了在开发现实世界中的专业性和经验，其中不仅仅是代码从开发者的指尖直接进入生产环境。我本来想自己回复的，但你几乎涵盖了我想说的全部内容。请随意编码者，仔细阅读并认真反思。
完整原文你提出了很多好的观点，其中一些可能适用于我的情况。 但这件事并不复杂。我之前低估了重构，但这次不是那种情况。这只是一个简单的小事情，只是将数据从A点传送到B点。验证新方案是否生成与旧方案相同的页面（数据库表中的数据）本来很容易。 我没有贬低任何人。我在团队会议上提了出来，我没有直接去找部门主管。当然，我之前被拒绝了，但那个拒绝是基于他们认为我错误地认为可以轻易替换掉它。我的周末编码只是为了证明这是可以做到的，不管有没有人相信我。 我真的很喜欢你最后一段话。你没有只是说不，而是和他们一起分析，并帮助他们看到问题。我确信，唯一真正的原因是这件事没有通过，…
完整原文你也可以要求开发人员编写全面的文档和测试用例，不仅针对新代码，也针对旧代码，以确保新代码能够复制高层系统所依赖的错误。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。