这两天运营要加圣诞活动，也就是大转盘之类的东西。 需求是圣诞当天所有的线路（线路下包含车辆）都可参与活动，并且活动随时上线下线。
我个人的想法是活动奖品之类的东西直接页面写死，配置表里增加一条参数控制活动上下线。等这种活动有更多需求后再进行优化
另外一个同事的想法：以防运营在上线后可能还会改变需求，想要将奖品内容建表维护，对每一个线路，甚至是车辆级的奖品进行可配置化，同时控制车辆级的活动上下线
我觉得他的想法是没啥问题，不过在这种活动本来就不一定常用，甚至有可能用过这次就不会再用，在这种情况下进行这么细的业务设计真的有必要吗
 |
1
iFlicker Dec 4, 2018
有必要
|
 |
2
terry0314 Dec 4, 2018
我比较赞同先拿出能跑的代码，等需求真的变了再优化
|
 |
3
a54552239 Dec 4, 2018
先按最简单的方式实现
|
 |
4
nekoyaki Dec 4, 2018
我觉得这取决于你们产品经理是不是隔三差五加需求……
|
 |
5
ritaswc Dec 4, 2018
看你时间够不够，够的话写成配置式的
|
 |
6
ghostwind Dec 4, 2018
可以把奖品写在配置里，把读配置还是读 db 方法封装下。
|
 |
7
Antihank Dec 4, 2018
时间紧迫，换我肯定是用最快速的方法实现，写的过程中注意一下可拓展性就可以了。
|
 |
8
Solix Dec 4, 2018 via iPhone
看活动是不是可通用，可通用的通常写通用配置，不通用时间紧先出一版能用再说
|
 |
9
also24 Dec 4, 2018
两种方案，分别给出预期开发时长，和能够实现的功能列表，丢给项目负责人决定。
后期如果出现需求变更，那是项目负责人对项目需求把握的问题。 如果没有项目负责人，就丢给需求方。 |
 |
10
visonme Dec 4, 2018
1. 先保证产品能按正常的时间节点完美上线
2. 在上线前，时间充裕情况下，我也推荐走你同事建议的路线。 毕竟只要有百分之一的可能性，都需要做好预防工作 |
 |
11
zidian9 Dec 4, 2018
有必要，具有高级的抽象能力是工程师的进阶之路。来个需求就搞个需求，不考虑后续的演化是外包做的事情。
|
|
12
zidian9 Dec 4, 2018  1
另外你做得好的话，他们以后也会用到。抽奖是运营的基本手法。如果你做的很抽象，比如支持自定义配置奖品和中奖概率，以及增加抽奖机会的条件自定义。运营人员简单配一下，就能使用，简单好用。那可以做到的事情有很多，比如只配置一个奖品（比如 VIP ），然后设定满足什么样条件（比如注册时间晚于多少，认为是新用户）的用户能参与抽奖。然后中奖几率 100%。等等可以做的事情很多，看工程师的抽象能力。如果做得好，运营们会实用的。工程师也应该具有技术推动产品、运营的能力。
|
 |
13
rb6221 Dec 4, 2018
看场景，这个是活动，一般是短期的，所以你的看法是比较合适的。
|
 |
14
reus Dec 4, 2018
先做一版能用的，然后看时间是否充裕，逐步重构成可以配置的
本来就是无聊的系统，你自己还没点技术追求，等着被淘汰吧 |
 |
15
ooo3o Dec 4, 2018
时间够就先做.
等到下次再要修改时不就可以闲一次工作的时间了嘛, 但时间照样要争取到手, 不能说早做好了, 到最后时刻再轻轻捅进代码库. |
 |
16
phpcxy Dec 4, 2018
我赞成你楼主的做法。目前做法能满足需求，注意可扩展就好了
|
 |
17
akira Dec 4, 2018
看给了几天时间
|
 |
18
alcarl Dec 4, 2018 via Android
如果做这种活动是常态，时间也充裕，就应该多实现一些通用的功能，为后面复用搭建些框架，积累代码和经验。如果就是一次性工作时间也紧张，那就先实现基本功能吧，毕竟按时可用是第一位的。这事情没有绝对的，在两个极端中选取最有效率的平衡才是正确的选择
|
Select Language