在工作中遇到了很恶心的需求该怎么办

职位是后端开发，最近的需求是将一个原本是前端完成的工作变为后端完成：前端轮询系统接口获取新增交易单后，根据一系列筛选条件过滤之后调用三方接口完成交易。产品需求是获取新增交易单后后端可以直接完成整个流程逻辑，对前端无感。产品想法很简单，但是对后端来说就很麻烦：我需要去看前端代码这一系列的筛选过滤条件的逻辑，以及调用三方接口的参数的组装逻辑。更麻烦的是前端一个 select 下的不同 option 可能对应着不同的逻辑，每一种逻辑的每一个步骤我都得保持一致；从前端轮询变成后端接收消息处理，后端接收消息进行处理，消息 QPS 相当高，对于性能要求很高。然而这也不是最恶心的，最恶心的是这个需求只能在 prod 来验证。

来这个部门才不到一个月，这其中的核心逻辑都不甚清楚。评审会的时候更是人微言轻，主管只说先做先做，然后就开始排期。

自从接了这个需求之后似乎就没怎么高兴的过过周末。脑子里一想到这个需求就好像有什么恶心的东西挂在背上，时不时刺你一下，但是你还甩不掉。。。

只要工作量给够有啥恶心的。工作量给不够什么需求都恶心🐶

是你不懂现有业务啊，而不是需求恶心，这个需求很合理啊，目前是前端调用第三方下订单，然后再给后端处理？这坑多大了，前端调用第三方成功了，跟后端通讯失败了，那这个单子到底是有还是没有。。。。，现在只是优化。 如果去做 一堆筛选项，不是变一个 select 就调后端，而是一堆选择完，才去点查询按钮去调接口。 如果就要改一个 select 就去调数据，那就照做，卡也是别人卡。跟你有毛关系。 人微言轻就埋头苦干。

你系统设计的时候，没必要先开始写代码。先写文档整理原来的流程逻辑，拆解步骤，就正常拆，不懂就问前端或者懂的人，最终你产出一个完整的改造文档。这个时候你再着手去写逻辑。

需求站在产品的角度看是正常的，但是对于核心业务之前都没接触过的开发来说，要在短期内全搞懂相关的业务逻辑挺恶心。

这需求太正常不过了 由前端完成才叫离谱

产品描述不清楚就不做，“和以前一样”不算需求，直接打回。

这需求很常规啊，哪里恶心了。实在不想做，考虑花点钱外包出去。

@hefish 是这样想的，目前想的最好是拿了年终奖之后给我 n+1 了。但是就怕哪天彻底顶不住一冲动就主动辞职了，两个都没了

@franswish 前端原本是一个设置页面，改为后端后也有一个设置页面。产品的需求就是跟之前的筛选逻辑一样