前後端分離開發后的狀態處理

2016-11-28 星期一

十月廿九丙申年 【猴年】己亥月 甲寅日

宜 纳采 移徙 纳财 开市 交易

忌 开仓 造屋 造桥 祭祀

眾所周知，在如今，web開發已經沒有曾經那樣刀耕火種的了，效率也已經是提升了不是一星半點，可以說算是進入了「蒸汽時代」。

那麼，既然進入蒸汽時代了，是不是開發模式也有所改變了呢，答案是肯定的。現在很多都是前後端分離了。

要知道，在以前，也就是前後端沒有分離的時候，特別的耦合。出了問題，誰都不想解決，誰都不想去更改、修復，前端退給後端，後端推給前端，對了那時候還不叫前端，叫「切圖仔」，要做的就是切頁面，改交互效果，頂多有個什麼ajax請求什麼的，前端看不懂後端寫在velocity\jsp模板里的的後端邏輯，後端看不懂前端里的html標籤，甚至亂用標籤。這導致了開發效率極低，一旦出現問題那就開始扯皮~~；而且我感受是100%出問題。

那麼這和我今天要說的有什麼關聯呢？今天不是說在前后端分離的情況下開發麼？難道也有扯皮事件發生？

對！當然有側披事件發生，不僅僅是前端和後端扯皮，還有前端和前端之間的扯皮~~

先引入一個親身經歷吧，前景提示：是在前後端分離的情況下開發。

有一次在開發一堆按鈕：上線、下線、提交、保存、編輯、刪除……這些按鈕都是通過實際的狀態碼來決定顯示與否，並且不是根據一個狀態碼，是根據幾個狀態碼的集合來顯示的。

第一次，一個前端人員改了2次，最後QA測試出沒有完全覆蓋按鈕顯示規則；

第二次，是我來修改的，當然最後QA也是測試出沒有完全覆蓋按鈕顯示規則；

第三次，是另一個前端人員，改了第一次，還是被QA測試出沒有完全覆蓋顯示規則，是第二次更改時，他用注釋把所有的狀態集合列舉出來，才完成這一規則顯示的；

從上看出，其實問題出在前後端分離后，像這樣的狀態碼，（1，2，3）到第二個人甚至某些天后的自己或許都分辨不出來代表什麼，這一節出現了脫節，並且是間斷時間性的脫節。這樣其實並不好，對項目來自自身都不好。

經過一段時間的思考，其實也該總結總結應該怎麼解決，避免扯皮~~~

這裡給出最完整最有效的方案：

1.對於很多狀態碼，使用枚舉用一個json變量儲存起來；

2.要使用狀態碼來處理邏輯，只需要&& ||操作即可；

3.起名的json變量以及裡面的key值也要有一定意義；

為什麼使用有意義的json變量儲存而不是用注釋呢？

1.首先，注釋並不是有效程序的一部分，只是起到注釋作用，讓有意義的變量作為程序的一部分才是好的代碼，反正也得起變量名；

2.只有在實在是說不清楚的時候才使用注釋加以更加準確的說明；

在這樣的更改下再出問題的幾率就很小很小了，除非本身設計的邏輯就有問題；

今天的記錄就結束了，算不上什麼高大上的建議，只是一點經驗而已~~~