记得刚来唯品的时候，遇到一位信仰基督教的产品同事，这里说到基督教，没有特别的含义，或者这是对这位产品最贴切的形容词吧，毕竟现在他已经献身基督教，把基督教当做第一职业，也可能是因为这是我第一次遇到信仰基督教的产品吧。每次跟他讨论需求，他开口第一句话总是，这个需求可大可小，在我的记忆中，好像他所有的需求都是可大可小。当时确实不太明白，为什么需求还能可大可小，怎么搞个产品还能搞得跟一年四季变幻，热胀冷缩的样子。作为一个追求美好的程序员，只能带着呆呆的问号，完成了他那一个个可大可小的需求。

       最近半年时间，有一个需求就像鬼魅一样持续优化着，业务诉求点为实时展示每家店铺每个小时的销售额以及每个小时的累计销售额，累计销售额为当天0点累计到该小时的总销售额。如下图一样：

       第一轮开发阶段，我花了半天时间把代码写完了。可是后续我整整花了一个星期做优化，才最终完成了上线发布，交付用户使用。一个星期完成一个报表的成本，只能说很高很高，在现在的互联网里面，近乎不能接受。这个看似很简单的需求，忽略了最重要的一点，就是数据量，线上数据量是以千万级别计算的，当我们通过SQL脚本方式实时计算每家店铺每小时的累计销售额，真的很慢很慢，对的，timeout了。或者有人说，为什么要通过SQL脚本呢，确实实现方案很多，但是方案成本我们可能就要深思了。

      在这里其实并不太想讨论技术层面的实现方案，或者说这个需求的最优解决方案是什么。或者有兴趣了解持续优化半年后，最终实现方案是怎样的，后续有机会可以再细谈，应该会对大家有所帮助。

       言归正传，讲了前面这么一大堆的铺垫，其实想跟大家讨论的只有两个字，平衡。作为一个追求美好的程序员，平衡好开发与产品之间，平衡好代码与需求的锲合度，在一定程度上也可以认为是一种降本增效。就如上面的销售报表，实时计算小时销售额和累计销售额，如果去掉实时二字，数据时效性允许5分钟的延迟，这个需求的实现，伟大的程序员可以自信的说：“三天就能做完！”（当然啦，加加班，两天做完也没问题）。又或者，如果愿意拿掉累计销售额的计算（其实一家店铺每天就10条数据），伟大而自信的程序员，可以拍胸脯回复领导，“一天完成开发并联调完成！”。

       如果让产品童鞋看到上面这段，不知道会不会说，其实就是要砍需求嘛。这还真是有着本质的区别。再举个例子，我们经常遇到用户希望把多个功能糅合在一个界面里面，可以同时在一个界面里面完成多种业务操作。对于这类需求，如果问程序员是否可以完成？程序猿当然可以完美实现，并且也确认，开发完成后确实可以在一定程度有助于用户的操作。但是我们也要考虑，实际中对用户有多大的提高，我们后续的维护应该是怎样的，下次的需求变更又如何支持。

       唠唠叨叨写了一堆，久了不写东西，还是有点生疏，可能也跟年纪有关，希望也能对大家有一点帮助。从古至今，许多人都在追求阴阳平衡，身边的程序猿，普遍感觉完美主义者偏多，极致的追求，越来越觉得或者是一份难得的勇气吧。或者可以静下心来领悟一下时间和空间的法则。

by 江沛  2020-06-22