有時候，產品思維和開發思維，由於出發點的不同，會產生較大的分歧。
作爲一個開發，不僅要有自己的思維，也要了解產品的思維，這樣才能在和產品的撕逼的戰鬥中所向披靡，百戰百勝。
舉個例子：
比如你在系統上提交一個申請單，這時這個申請的狀態是待審覈。
待審覈狀態，可以變成審覈通過和審覈不通過。
這時分歧就來了，如果是審覈不通過，原因是因爲申請單裏面的一些東西寫錯了，那應該是重新生成一個申請單呢，還是修改之前審覈不通過的這個申請單然後繼續審覈呢。
說實話，我也見過不少優秀的產品設計了，這種問題我的第一反應，肯定是新生成一個申請單，或者說，我從來都不會想出還能修改之前的申請單這種操作。
但我們想想設計出要修改舊申請單的這種產品同學，設計的初衷是什麼，我覺得應該是想着審覈失敗了，就在原來的申請單上改一下，就可以重新審覈了，也比較方便，怎麼說呢，這個邏輯應該是和改卷子一樣了。如果哪裏寫錯被老師打回了，就在原來的卷子上改一改就好，不會有人會再找份新卷子，再把所有的再寫一遍了。
卷子直接改，是因爲再寫一份新的太麻煩也沒必要，但程序要是設計成這樣，就有點難受了，因爲對於程序來說，新生成一個申請單，並不是什麼難事，而直接修改，就不是隨便找個空子寫上去的問題了，我簡單說說爲什麼這種情況要新生成，而不要修改舊的申請單的原因：
1、狀態最好是單向，且有終態。
我們說任何狀態的變化，最好都是單向的，且有個最終狀態，就是一旦到達最終狀態，數據就不可變了。這樣設計的好處就是在後期的判斷和維護上，都是可以解耦的，如果狀態直接可以任意跳轉，那一旦狀態變多，最後就是一鍋粥了。而且有了終態，就可以做很多事情了，相反如果狀態一直沒有終態，你永遠不知道這個狀態還會變成什麼，那很多統計的事情就會因爲這個變得特別複雜。
2、每次申請最好能清晰記錄
每次申請，都是一個記錄，如果每次審覈不通過的重寫申請，都是新申請，那根據申請人，就可以知道這個人的操作記錄了，比如什麼時候提交申請，什麼時候被審覈不通過了，什麼時候又重新提交了申請等等，甚至後面還可以比對出後面申請都改了什麼東西。反觀直接修改，那就相當於把之前的申請覆蓋了，如果再審覈不通過，再修改，這樣多幾次，誰都不知道一開始是申請什麼了。