小逻辑和大产品

本来想写个文章安慰一下自己，按照大师的说法有了失恋的感觉，不过还是要更积极一些，改变能改变的事。

想写写我们产品中的一些小逻辑，总的来说小逻辑指的是指符合以下三个条件的逻辑：1.在我们SaaS产品中仅有个别用户在用

2.不存在于每天日常人工参与的操作流程中

3.逻辑不那么简单直白。

举个例子：

昨天有一个客户问我们说，通过我们的物料信息计算套数的结果有问题，肉眼一看就是0.9,算出来是0.8。几个开发同学一起重新审视了计算代码，却没有发现，折腾了几个小时，发现问题是用户改过物料信息，但是系统却没有重新计算，再仔细研究发现，用户必须手动把页面上一个特定的字段删除后，系统才会重新计算。好吧，完全没有人能记得起来这样一个小逻辑。想一想写这个逻辑的时候可能花了半天的时间，几个人一起支持一下这个case加起来也有半天了。

对于聚焦于打造产品的团队，小逻辑绝对是一个不讨人喜欢的东西。在team中一般称之为“坑”。

那么如何才能避免这样的坑呢？

首先是要识别，在小逻辑进入产品之前就发现他，只有发现了才能应对。

然后看是不是能拒绝他，最好的应对方式还是拒绝，一了百了。

拒绝不了就像个更通用的方法来应对，尝试把他变成一个通用的大逻辑

然而变通有的时候也没有办法满足用户要求，那就想办法把他变得直白，符合一般逻辑，每次遇到时很容易能想到。

变直白也不行，最后的无奈是把他变得更明显，比如在页面上合适的地方增加说明。至少想不起来的时候能看到。

从代码的角度来说，是想办法把这些逻辑拢到一起，与通用逻辑做隔离，至少查问题好查。我们很多接口的逻辑就是小逻辑，把他陇在接口的逻辑中是个合适的做法。不过这也导致了接口的逻辑越来越复杂，这是下一个话题。

其实按照之前的逻辑每向前一步，对产品的通用性就更差一些，所以每前进一步要想想是不是能回到第一步。

小逻辑和大产品