超级会员免费看
在开发过程中，预留未来功能扩展虽然旨在减少重构成本，但也会带来额外开销。个人开发者尤其需要权衡，因为冗余代码可能导致长期维护困扰。正确判断功能上线时间，避免因保留未使用的代码而造成资源浪费。及时调整架构，保持产品的简洁性，对于小产品尤为重要。
老板说，这个功能我们现在不开发，但是你要留好未来拓展的选项，方便到时候直接拓展，减少开发和重构的成本。
这个时候，涉及到取舍问题，主要需要考虑的是，老板说的这个功能，到底什么时候能真的上。
在现有的基础上为未来可能的功能考虑，是有成本的。架构都可能不一样，开发人员的因此增加工时加起来可能也不少。
一开始架构时，确实要考虑到后期增加功能的可能性，但在架构上，现在是否要以此做设计，就需要综合判断。
主要是判断成本，判断这个功能，实际上大概什么时候能上。
这个什么时候能上，不能以老板说的为准，我见过老板说2个月要上的，所以代码里一直保留着迁移过来的部分代码，最后因为各种老问题、新问题、新需求、新计划，结果2年了，也没有上，最后重构的时候，直接砍掉。
如果是作为个人开发者，自己做小产品，那就更要避免这种情况。
小产品，关键是要小，不要在做小东西的时候，给自己太多的冗余处理的逻辑。
我的经验是，一般我说现在这个功能做成这样，但是我后面还要增加什么什么，这个功能真的加上，有时候都是一年之后了，保留字段的含义、业务逻辑都已经忘得差不多了。
有时候我想，我写好文档，写好注释，就可以避免这个问题。但实际上，我以为我下周就会增加的功能，压根不会写文档写注释，即使写了，能否详细到一年后自己还能看懂？
我举一个简单的例子，我之前做了一个优惠码的逻辑，在数据库有1个关于时间的字段，过期时间，前端也是按照这个逻辑做的。
后来我觉得还应该加上，开始显示的时间和结束显示的时间，所以在数据库又加了这两个字段。
仅仅这一个操作，导致我每次需要做优惠活动的时候，我都要去检查前端代码，看我自己是否使用了这两个字段来做判
订阅专栏 解锁全文
扫一扫
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
