老板说，这个功能我们现在不开发，但是你要留好未来拓展的选项，方便到时候直接拓展，减少开发和重构的成本。
这个时候，涉及到取舍问题，主要需要考虑的是，老板说的这个功能，到底什么时候能真的上。
在现有的基础上为未来可能的功能考虑，是有成本的。架构都可能不一样，开发人员的因此增加工时加起来可能也不少。
一开始架构时，确实要考虑到后期增加功能的可能性，但在架构上，现在是否要以此做设计，就需要综合判断。
主要是判断成本，判断这个功能，实际上大概什么时候能上。
这个什么时候能上，不能以老板说的为准，我见过老板说2个月要上的，所以代码里一直保留着迁移过来的部分代码，最后因为各种老问题、新问题、新需求、新计划，结果2年了，也没有上，最后重构的时候，直接砍掉。
如果是作为个人开发者，自己做小产品，那就更要避免这种情况。
小产品，关键是要小，不要在做小东西的时候，给自己太多的冗余处理的逻辑。
我的经验是，一般我说现在这个功能做成这样，但是我后面还要增加什么什么，这个功能真的加上，有时候都是一年之后了，保留字段的含义、业务逻辑都已经忘得差不多了。
有时候我想，我写好文档，写好注释，就可以避免这个问题。但实际上，我以为我下周就会增加的功能，压根不会写文档写注释，即使写了，能否详细到一年后自己还能看懂？
我举一个简单的例子，我之前做了一个优惠码的逻辑，在数据库有1个关于时间的字段，过期时间，前端也是按照这个逻辑做的。
后来我觉得还应该加上，开始显示的时间和结束显示的时间，所以在数据库又加了这两个字段。
仅仅这一个操作，导致我每次需要做优惠活动的时候，我都要去检查前端代码，看我自己是否使用了这两个字段来做判断，来看我是否需要，修改数据库这两个字段的值。
因为我老是忘记，每次确认都要花费一些时间，我又怕麻烦，所以很多时候，索性就不做优惠活动。作为个人小产品，正确的做法当然是尽量简单，我后来直接从数据库把这两个字段删掉了。
独立开发者社群： https://dev4myself.com/blog/indie-developer-app-growth-diary-planet-introduction