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

开发时是否要对不确定的需求进行细致的完整开发

  •  
  •   hayanami · 2018-12-04 09:56:43 +08:00 · 2401 次点击
    这是一个创建于 1941 天前的主题,其中的信息可能已经有所发展或是发生改变。

    这两天运营要加圣诞活动,也就是大转盘之类的东西。 需求是圣诞当天所有的线路(线路下包含车辆)都可参与活动,并且活动随时上线下线。

    我个人的想法是活动奖品之类的东西直接页面写死,配置表里增加一条参数控制活动上下线。等这种活动有更多需求后再进行优化

    另外一个同事的想法:以防运营在上线后可能还会改变需求,想要将奖品内容建表维护,对每一个线路,甚至是车辆级的奖品进行可配置化,同时控制车辆级的活动上下线

    我觉得他的想法是没啥问题,不过在这种活动本来就不一定常用,甚至有可能用过这次就不会再用,在这种情况下进行这么细的业务设计真的有必要吗

    第 1 条附言  ·  2018-12-04 14:33:21 +08:00
    看了大家的回复,基本都是选择在时间充裕的情况下选择更加细致的开发。
    哎,我也知道我那个搞法是偷懒了点,主要是觉得运营这次活动大概率又是用完就不会再用的样子,特地建表维护,配置化,总有种大费周章的感觉。所以才想如果真的有再次使用才进行后续优化,果然还是有点偷懒了啊。
    感谢大家的回复,我也尽量改正提高一下自己
    18 条回复    2018-12-04 21:17:28 +08:00
    iFlicker
        1
    iFlicker  
       2018-12-04 10:13:29 +08:00
    有必要
    terry0314
        2
    terry0314  
       2018-12-04 10:17:44 +08:00
    我比较赞同先拿出能跑的代码,等需求真的变了再优化
    a54552239
        3
    a54552239  
       2018-12-04 10:19:54 +08:00
    先按最简单的方式实现
    nekoyaki
        4
    nekoyaki  
       2018-12-04 10:22:20 +08:00
    我觉得这取决于你们产品经理是不是隔三差五加需求……
    ritaswc
        5
    ritaswc  
       2018-12-04 10:22:59 +08:00
    看你时间够不够,够的话写成配置式的
    ghostwind
        6
    ghostwind  
       2018-12-04 10:23:36 +08:00
    可以把奖品写在配置里,把读配置还是读 db 方法封装下。
    Antihank
        7
    Antihank  
       2018-12-04 10:30:35 +08:00
    时间紧迫,换我肯定是用最快速的方法实现,写的过程中注意一下可拓展性就可以了。
    gaobh
        8
    gaobh  
       2018-12-04 10:40:44 +08:00 via iPhone
    看活动是不是可通用,可通用的通常写通用配置,不通用时间紧先出一版能用再说
    also24
        9
    also24  
       2018-12-04 10:51:46 +08:00
    两种方案,分别给出预期开发时长,和能够实现的功能列表,丢给项目负责人决定。

    后期如果出现需求变更,那是项目负责人对项目需求把握的问题。

    如果没有项目负责人,就丢给需求方。
    visonme
        10
    visonme  
       2018-12-04 10:52:36 +08:00
    1. 先保证产品能按正常的时间节点完美上线
    2. 在上线前,时间充裕情况下,我也推荐走你同事建议的路线。 毕竟只要有百分之一的可能性,都需要做好预防工作
    zidian9
        11
    zidian9  
       2018-12-04 10:53:26 +08:00
    有必要,具有高级的抽象能力是工程师的进阶之路。来个需求就搞个需求,不考虑后续的演化是外包做的事情。
    zidian9
        12
    zidian9  
       2018-12-04 10:59:26 +08:00   ❤️ 1
    另外你做得好的话,他们以后也会用到。抽奖是运营的基本手法。如果你做的很抽象,比如支持自定义配置奖品和中奖概率,以及增加抽奖机会的条件自定义。运营人员简单配一下,就能使用,简单好用。那可以做到的事情有很多,比如只配置一个奖品(比如 VIP ),然后设定满足什么样条件(比如注册时间晚于多少,认为是新用户)的用户能参与抽奖。然后中奖几率 100%。等等可以做的事情很多,看工程师的抽象能力。如果做得好,运营们会实用的。工程师也应该具有技术推动产品、运营的能力。
    janus77
        13
    janus77  
       2018-12-04 11:02:34 +08:00
    看场景,这个是活动,一般是短期的,所以你的看法是比较合适的。
    reus
        14
    reus  
       2018-12-04 11:57:05 +08:00
    先做一版能用的,然后看时间是否充裕,逐步重构成可以配置的
    本来就是无聊的系统,你自己还没点技术追求,等着被淘汰吧
    ooo3o
        15
    ooo3o  
       2018-12-04 14:50:16 +08:00
    时间够就先做.
    等到下次再要修改时不就可以闲一次工作的时间了嘛, 但时间照样要争取到手, 不能说早做好了, 到最后时刻再轻轻捅进代码库.
    phpcxy
        16
    phpcxy  
       2018-12-04 15:03:48 +08:00
    我赞成你楼主的做法。目前做法能满足需求,注意可扩展就好了
    akira
        17
    akira  
       2018-12-04 16:09:34 +08:00
    看给了几天时间
    alcarl
        18
    alcarl  
       2018-12-04 21:17:28 +08:00 via Android
    如果做这种活动是常态,时间也充裕,就应该多实现一些通用的功能,为后面复用搭建些框架,积累代码和经验。如果就是一次性工作时间也紧张,那就先实现基本功能吧,毕竟按时可用是第一位的。这事情没有绝对的,在两个极端中选取最有效率的平衡才是正确的选择
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5042 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 43ms · UTC 09:46 · PVG 17:46 · LAX 02:46 · JFK 05:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.