难受，关于最近负责设计的一个系统有感

你好，我是yes。

其实想写这篇文章很久了，原本打算双十一后一天就动手写的。

但碍于当时公司精简人员，我又得加班加点投身到双十二的需求中，就一直拖着。

一拖就拖到了现在，当下也是趁着阳了的机会，上来分享下心得。

而恰巧也因为拖到现在，我又有了不一样的心得体会，你可能不信，说出来还有点苦涩。

我负责设计的这个系统简单来说就是卖东西，而一个东西的总价又由几个子价格组成，有些东西可能有 2 个子价格，有些可能有 3 个或者更多。

有些东西的子价格是要随着数量相乘算价的，有些又是不管买几个都只收一个费用的。

然后现在需要设计个营销系统，这个设计就有点讲究了。

因为营销多变、灵活，需要考虑的点很多，单种优惠就不说了，还有组合的优惠等等，其实也不用多说，大家想想购物软件各种各样优惠和折扣策略就知道了。

所以当开始设计的时候，满脑子都是各种场景，总想着能设计的更通用一些，后面有需求变更的话改动小一些。

我当然也是知道架构是演进的，设计也是如此，初生的系统尽量遵循最小产品化原则，后期再进行优化迭代，更何况我还在赶工期呢。

但是，我就是忍不住想要设计得更加通用。

就这样在纠结和与时间的妥协下，两天的开发时间就提测了。

前头提到我想写这篇文章很久了，当时我想写的内容是模糊下公司的业务场景，然后提一些设计的扩展点。

说实话现在我有点忘记其中的细节，但是看下代码和数据库的设计应该能想起来，不过我现在已经不想写这个了。

设计肯定重要，但或许对你来说它不一定那么重要。

前不久我刚写过一篇数据库存储时间到底该用什么类型？文章里面有这样一段话：

这段话用在设计上也是适用的。

在设计这个系统的时候，我还记得当时另一个同事问我：你这个实现如果到时候再加个子价格是不是就有问题了？

我说有道理，容我再考虑考虑。

第二版他又问我如果变更了xxx是不是又有问题。

第三版...

关于他负责的另一个系统他也跟我讨论了很多，他当时整夜没睡，考虑了诸多扩展，设计了一个我觉得确实很通用的方案，很为他点赞。

最终我们加班加点，系统在双十一成功上线，没有辜负老板的期望。

然后昨天他被毕业了。

对，很突然。

前几天他还跟我说他这个设计支持元旦这个活动很稳，都不需要变，不过后续量大了可能需要在某某环节加点缓存...

昨天就直接在会议室签了协议走人了。因为我生病在家，都没来得及在办公室见他一面。

还记得他还跟我说过：如果后面运营要是搞一些比较变态的玩法，他这个设计只要变个xxx就能兼容。

所以我在想，当设计一个系统的时候，需要往后考虑那么多吗？

或许有人说，就算你毕业了，也是给后面的人造福啊！

也许吧，运气好可能遇到可以 get 到你设计的人，运气不好可能还会骂你设计个麻瓜，搞得这么复杂！

我也不知道了。

随着工作年限的增加，遇到的事情也越来越多，我越来越能体会到什么是编程，什么是人生。

或许是时候再重识一遍“架构是演进的”这句话。

可能它有另一层含义。

我是yes，我们下篇见。