V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
juzisang
V2EX  ›  程序员

分享下最近因为需求迭代,慢慢糊 S 的过程

  •  
  •   juzisang ·
    JuZiSang · 10 天前 · 1416 次点击
    最近一对专职做爬虫的后端来做业务。

    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
    dyexlzc
        1
    dyexlzc  
       10 天前
    这种频繁变更的需求让他每变更一次都输出需求变更文档,不仅为了让他输出文档的时候自己问自己“是不是真的有必要”,也避免了后续扯皮
    vfs
        2
    vfs  
       10 天前
    我就单纯好奇,这样子每条沟通, 你们得绩效怎么算的?
    juzisang
        3
    juzisang  
    OP
       10 天前
    @dyexlzc #1 有文档,需求变更都有评审的
    juzisang
        4
    juzisang  
    OP
       10 天前
    @vfs #2 没有每条都沟通,你看错了吧,需求下来后,做之前肯定要沟通一下前后端怎么做,不是做到哪说到哪。我说的迭代是指需求搞完了,上线观察一段时间,产品又有新需求了,一版一版得上。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2273 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 09:42 · PVG 17:42 · LAX 02:42 · JFK 05:42
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.