最近一对专职做爬虫的后端来做业务。

1. 前面业务很简单,就是简单的搜索然后出结果。

2. 迭代第二版,加了个搜索记录,每条记录点击去要和他搜索的时候出一样的内容

2.1 然后后端在每个搜索的接口加了个时间,历史记录点击去就传时间

3. 迭代第三版,搜索改成多个数据组合起来的聚合详情页,我就开始觉得不对劲了,搜索页变结果页了。

3.1 我就叫他们最好出个新接口,把我的传参存起来然后给个 id 给我,后续结果页都通过这个 id 取数据。
  
3.2 然后他们以太复杂,改动太大,没必要,先用着,然后框框出来七八个接口,每一个都传相同的筛选字段。

4. 后续迭代,需要给每条记录加上状态了,但是后端没有状态,他们只有筛选条件,没办法知道是从那条记录点进去得。
  
4.1 这个时候状态还比较简单,还是 3.2 的理由,不出 id 。然后我给了个他们糊屎的建议,叫他们取最后一条记录也就是最新的状态,然后勉强糊弄过去了。

... 中间还有一堆乱七八糟的需求迭代

然后最新的迭代,真的每条记录都有单独而且**复杂**的状态了,在这条记录上新增了个额外的支付选项,额外支付又牵扯出其它数据。

当然,他们如果直接把查询时间当 id 用,然后再加上状态也不是不行,只不过从一开始简单快捷的办法,慢慢糊成屎还是很懊恼。

主要是他们还老是觉得我在故意找茬(就是我会经常和他们说加上 3.1 好应对后续的需求),说话都开始阴阳起来了,可能觉得我在教他们做事(

期间有趣的是,记录不是有状态吗,但是他们只有一个简单的最新(当前)状态,没有每条记录的状态

所以如果期间的调用链路状态有问题了,他们只能通过看日志的接口调用日志,去排查问题,但是接口实在太多太杂,很不好排查,一个逻辑要找我确认 7-8 遍,反复确认是不是前端接口调用有问题。

然后同一个问题要每天问我好几次,过一天好像失去记忆一样,又跑来问我一会。

😶
举报· 53 次点击
登录 注册 站外分享
2 条回复  
dyexlzc 小成 2024-9-6 11:49:18
这种频繁变更的需求让他每变更一次都输出需求变更文档,不仅为了让他输出文档的时候自己问自己“是不是真的有必要”,也避免了后续扯皮
vfs 小成 2024-9-6 11:56:32
我就单纯好奇,这样子每条沟通, 你们得绩效怎么算的?
返回顶部