这是一个创建于 64 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近一对专职做爬虫的后端来做业务。
1. 前面业务很简单，就是简单的搜索然后出结果。
2. 迭代第二版，加了个搜索记录，每条记录点击去要和他搜索的时候出一样的内容
2.1 然后后端在每个搜索的接口加了个时间，历史记录点击去就传时间
3. 迭代第三版，搜索改成多个数据组合起来的聚合详情页，我就开始觉得不对劲了，搜索页变结果页了。
3.1 我就叫他们最好出个新接口，把我的传参存起来然后给个 id 给我，后续结果页都通过这个 id 取数据。
3.2 然后他们以太复杂，改动太大，没必要，先用着，然后框框出来七八个接口，每一个都传相同的筛选字段。
4. 后续迭代，需要给每条记录加上状态了，但是后端没有状态，他们只有筛选条件，没办法知道是从那条记录点进去得。
4.1 这个时候状态还比较简单，还是 3.2 的理由，不出 id 。然后我给了个他们糊屎的建议，叫他们取最后一条记录也就是最新的状态，然后勉强糊弄过去了。
... 中间还有一堆乱七八糟的需求迭代
然后最新的迭代，真的每条记录都有单独而且**复杂**的状态了，在这条记录上新增了个额外的支付选项，额外支付又牵扯出其它数据。
当然，他们如果直接把查询时间当 id 用，然后再加上状态也不是不行，只不过从一开始简单快捷的办法，慢慢糊成屎还是很懊恼。
主要是他们还老是觉得我在故意找茬（就是我会经常和他们说加上 3.1 好应对后续的需求），说话都开始阴阳起来了，可能觉得我在教他们做事（
期间有趣的是，记录不是有状态吗，但是他们只有一个简单的最新（当前）状态，没有每条记录的状态
所以如果期间的调用链路状态有问题了，他们只能通过看日志的接口调用日志，去排查问题，但是接口实在太多太杂，很不好排查，一个逻辑要找我确认 7-8 遍，反复确认是不是前端接口调用有问题。
然后同一个问题要每天问我好几次，过一天好像失去记忆一样，又跑来问我一会。
😶
1. 前面业务很简单，就是简单的搜索然后出结果。
2. 迭代第二版，加了个搜索记录，每条记录点击去要和他搜索的时候出一样的内容
2.1 然后后端在每个搜索的接口加了个时间，历史记录点击去就传时间
3. 迭代第三版，搜索改成多个数据组合起来的聚合详情页，我就开始觉得不对劲了，搜索页变结果页了。
3.1 我就叫他们最好出个新接口，把我的传参存起来然后给个 id 给我，后续结果页都通过这个 id 取数据。
3.2 然后他们以太复杂，改动太大，没必要，先用着，然后框框出来七八个接口，每一个都传相同的筛选字段。
4. 后续迭代，需要给每条记录加上状态了，但是后端没有状态，他们只有筛选条件，没办法知道是从那条记录点进去得。
4.1 这个时候状态还比较简单，还是 3.2 的理由，不出 id 。然后我给了个他们糊屎的建议，叫他们取最后一条记录也就是最新的状态，然后勉强糊弄过去了。
... 中间还有一堆乱七八糟的需求迭代
然后最新的迭代，真的每条记录都有单独而且**复杂**的状态了，在这条记录上新增了个额外的支付选项，额外支付又牵扯出其它数据。
当然，他们如果直接把查询时间当 id 用，然后再加上状态也不是不行，只不过从一开始简单快捷的办法，慢慢糊成屎还是很懊恼。
主要是他们还老是觉得我在故意找茬（就是我会经常和他们说加上 3.1 好应对后续的需求），说话都开始阴阳起来了，可能觉得我在教他们做事（
期间有趣的是，记录不是有状态吗，但是他们只有一个简单的最新（当前）状态，没有每条记录的状态
所以如果期间的调用链路状态有问题了，他们只能通过看日志的接口调用日志，去排查问题，但是接口实在太多太杂，很不好排查，一个逻辑要找我确认 7-8 遍，反复确认是不是前端接口调用有问题。
然后同一个问题要每天问我好几次，过一天好像失去记忆一样，又跑来问我一会。
😶
4 条回复 • 2024-09-06 13:57:12 +08:00
 |
1
dyexlzc 64 天前
这种频繁变更的需求让他每变更一次都输出需求变更文档，不仅为了让他输出文档的时候自己问自己“是不是真的有必要”，也避免了后续扯皮
|
 |
2
vfs 64 天前
我就单纯好奇，这样子每条沟通， 你们得绩效怎么算的？
|
Select Language