开发的时候的保留项、冗余的成本

老板说，这个功能我们现在不开发，但是你要留好未来拓展的选项，方便到时候直接拓展，减少开发和重构的成本。

这个时候，涉及到取舍问题，主要需要考虑的是，老板说的这个功能，到底什么时候能真的上。

在现有的基础上为未来可能的功能考虑，是有成本的。架构都可能不一样，开发人员的因此增加工时加起来可能也不少。

一开始架构时，确实要考虑到后期增加功能的可能性，但在架构上，现在是否要以此做设计，就需要综合判断。

主要是判断成本，判断这个功能，实际上大概什么时候能上。

这个什么时候能上，不能以老板说的为准，我见过老板说2个月要上的，所以代码里一直保留着迁移过来的部分代码，最后因为各种老问题、新问题、新需求、新计划，结果2年了，也没有上，最后重构的时候，直接砍掉。

如果是作为个人开发者，自己做小产品，那就更要避免这种情况。

小产品，关键是要小，不要在做小东西的时候，给自己太多的冗余处理的逻辑。

我的经验是，一般我说现在这个功能做成这样，但是我后面还要增加什么什么，这个功能真的加上，有时候都是一年之后了，保留字段的含义、业务逻辑都已经忘得差不多了。

有时候我想，我写好文档，写好注释，就可以避免这个问题。但实际上，我以为我下周就会增加的功能，压根不会写文档写注释，即使写了，能否详细到一年后自己还能看懂？

我举一个简单的例子，我之前做了一个优惠码的逻辑，在数据库有1个关于时间的字段，过期时间，前端也是按照这个逻辑做的。

后来我觉得还应该加上，开始显示的时间和结束显示的时间，所以在数据库又加了这两个字段。

仅仅这一个操作，导致我每次需要做优惠活动的时候，我都要去检查前端代码，看我自己是否使用了这两个字段来做判