有時候，產品思維和開發思維，由于出發點的不同，會產生較大的分歧。
作為一個開發，不僅要有自己的思維，也要了解產品的思維，這樣才能在和產品的撕逼的戰斗中所向披靡，百戰百勝。

舉個例子：

比如你在系統上提交一個申請單，這時這個申請的狀態是待審核。
待審核狀態，可以變成審核通過和審核不通過。

這時分歧就來了，如果是審核不通過，原因是因為申請單里面的一些東西寫錯了，那應該是重新生成一個申請單呢，還是修改之前審核不通過的這個申請單然后繼續審核呢。

說實話，我也見過不少優秀的產品設計了，這種問題我的第一反應，肯定是新生成一個申請單，或者說，我從來都不會想出還能修改之前的申請單這種操作。

但我們想想設計出要修改舊申請單的這種產品同學，設計的初衷是什么，我覺得應該是想著審核失敗了，就在原來的申請單上改一下，就可以重新審核了，也比較方便，怎么說呢，這個邏輯應該是和改卷子一樣了。如果哪里寫錯被老師打回了，就在原來的卷子上改一改就好，不會有人會再找份新卷子，再把所有的再寫一遍了。

卷子直接改，是因為再寫一份新的太麻煩也沒必要，但程序要是設計成這樣，就有點難受了，因為對于程序來說，新生成一個申請單，并不是什么難事，而直接修改，就不是隨便找個空子寫上去的問題了，我簡單說說為什么這種情況要新生成，而不要修改舊的申請單的原因：

1、狀態最好是單向，且有終態。
我們說任何狀態的變化，最好都是單向的，且有個最終狀態，就是一旦到達最終狀態，數據就不可變了。這樣設計的好處就是在后期的判斷和維護上，都是可以解耦的，如果狀態直接可以任意跳轉，那一旦狀態變多，最后就是一鍋粥了。而且有了終態，就可以做很多事情了，相反如果狀態一直沒有終態，你永遠不知道這個狀態還會變成什么，那很多統計的事情就會因為這個變得特別復雜。

2、每次申請最好能清晰記錄
每次申請，都是一個記錄，如果每次審核不通過的重寫申請，都是新申請，那根據申請人，就可以知道這個人的操作記錄了，比如什么時候提交申請，什么時候被審核不通過了，什么時候又重新提交了申請等等，甚至后面還可以比對出后面申請都改了什么東西。反觀直接修改，那就相當于把之前的申請覆蓋了，如果再審核不通過，再修改，這樣多幾次，誰都不知道一開始是申請什么了。

總結

以上是生活随笔為你收集整理的随想，产品思维和开发思维的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。