有时候，产品思维和开发思维，由于出发点的不同，会产生较大的分歧。
作为一个开发，不仅要有自己的思维，也要了解产品的思维，这样才能在和产品的撕逼的战斗中所向披靡，百战百胜。
举个例子：
比如你在系统上提交一个申请单，这时这个申请的状态是待审核。
待审核状态，可以变成审核通过和审核不通过。
这时分歧就来了，如果是审核不通过，原因是因为申请单里面的一些东西写错了，那应该是重新生成一个申请单呢，还是修改之前审核不通过的这个申请单然后继续审核呢。
说实话，我也见过不少优秀的产品设计了，这种问题我的第一反应，肯定是新生成一个申请单，或者说，我从来都不会想出还能修改之前的申请单这种操作。
但我们想想设计出要修改旧申请单的这种产品同学，设计的初衷是什么，我觉得应该是想着审核失败了，就在原来的申请单上改一下，就可以重新审核了，也比较方便，怎么说呢，这个逻辑应该是和改卷子一样了。如果哪里写错被老师打回了，就在原来的卷子上改一改就好，不会有人会再找份新卷子，再把所有的再写一遍了。
卷子直接改，是因为再写一份新的太麻烦也没必要，但程序要是设计成这样，就有点难受了，因为对于程序来说，新生成一个申请单，并不是什么难事，而直接修改，就不是随便找个空子写上去的问题了，我简单说说为什么这种情况要新生成，而不要修改旧的申请单的原因：
1、状态最好是单向，且有终态。
我们说任何状态的变化，最好都是单向的，且有个最终状态，就是一旦到达最终状态，数据就不可变了。这样设计的好处就是在后期的判断和维护上，都是可以解耦的，如果状态直接可以任意跳转，那一旦状态变多，最后就是一锅粥了。而且有了终态，就可以做很多事情了，相反如果状态一直没有终态，你永远不知道这个状态还会变成什么，那很多统计的事情就会因为这个变得特别复杂。
2、每次申请最好能清晰记录
每次申请，都是一个记录，如果每次审核不通过的重写申请，都是新申请，那根据申请人，就可以知道这个人的操作记录了，比如什么时候提交申请，什么时候被审核不通过了，什么时候又重新提交了申请等等，甚至后面还可以比对出后面申请都改了什么东西。反观直接修改，那就相当于把之前的申请覆盖了，如果再审核不通过，再修改，这样多几次，谁都不知道一开始是申请什么了。
