• 请不要在回答技术问题时复制粘贴 AI 生成的内容
juzisang
V2EX  ›  程序员

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

  •  
  •   juzisang ·
    JuZiSang · Sep 6, 2024 · 2694 views
    This topic created in 683 days ago, the information mentioned may be changed or developed.
    最近一对专职做爬虫的后端来做业务。

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

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

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

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

    3.1 我就叫他们最好出个新接口,把我的传参存起来然后给个 id 给我,后续结果页都通过这个 id 取数据。

    3.2 然后他们以太复杂,改动太大,没必要,先用着,然后框框出来七八个接口,每一个都传相同的筛选字段。

    4. 后续迭代,需要给每条记录加上状态了,但是后端没有状态,他们只有筛选条件,没办法知道是从那条记录点进去得。

    4.1 这个时候状态还比较简单,还是 3.2 的理由,不出 id 。然后我给了个他们糊屎的建议,叫他们取最后一条记录也就是最新的状态,然后勉强糊弄过去了。

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

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

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

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

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

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

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

    😶
    4 replies    2024-09-06 13:57:12 +08:00
    dyexlzc
        1
    dyexlzc  
       Sep 6, 2024
    这种频繁变更的需求让他每变更一次都输出需求变更文档,不仅为了让他输出文档的时候自己问自己“是不是真的有必要”,也避免了后续扯皮
    vfs
        2
    vfs  
       Sep 6, 2024
    我就单纯好奇,这样子每条沟通, 你们得绩效怎么算的?
    juzisang
        3
    juzisang  
    OP
       Sep 6, 2024
    @dyexlzc #1 有文档,需求变更都有评审的
    juzisang
        4
    juzisang  
    OP
       Sep 6, 2024
    @vfs #2 没有每条都沟通,你看错了吧,需求下来后,做之前肯定要沟通一下前后端怎么做,不是做到哪说到哪。我说的迭代是指需求搞完了,上线观察一段时间,产品又有新需求了,一版一版得上。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5461 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 48ms · UTC 05:49 · PVG 13:49 · LAX 22:49 · JFK 01:49
    ♥ Do have faith in what you're doing.