做一个产品功能,会从扩展性上考虑,在后台管理系统中加很多选项,供运营灵活配置。但也有另一种说法,说功能前期要相对简单一些,这样试错之后的迭代成本会小一点。这两说法是相对的么?如果是相对的,如何做到平衡
我觉得,产品的可扩展性建立在低耦合的基础之上,不仅仅是代码层面的低耦合,也基于设计思想上的低耦合。例如你现在看到的这个页面,是一个展示功能,还是一堆功能模块?
如果你把这个页面理解为问题+回答+答案展示+阅读量统计+推荐+邀请+关注……一堆功能模块的组合,那么这个产品的扩展性自然就会强很多。我身边也有很多产品会通过增加选项的方式来增加配置的灵活性,可这种做法并不代表产品的扩展性,你说我将来会做这个功能,所以我在这里加了个开关但是不起作用,这个就真的增加了配置的灵活性么?配置始终是为业务服务的,三个月以内的业务需要这个配置,那么这个配置才是有价值的。明年某天才会用到?对不起,一般的企业是没有这个实力先做好了等那一天的
所以,低耦合,各个模块的定义和边界清晰了,功能自然就简单了,扩展性也就强了,一个点赞功能玩出花儿来,点击之后各种酷炫的展示,也只是基于点赞模块的展示功能进行了优化而不会影响到我的阅读量、不会影响我回答问题时弹出一个bug。
我以前做的客运项目,后端调度逻辑还算复杂,不过梳理清楚后,发现实质上就是一堆模块的集合,这样整个系统的复杂程度成倍下降了,但是效率和性能却依然得到了提升。
希望这个回答解答了你的疑问