產(chǎn)品設計時刻：啟用/停用/刪除，該怎么用？什么時候用？
起因
最近在做BMS計費相關(guān)的內(nèi)容，涉及到了很多基礎計費規(guī)則的管理。一般來說，對于這種基礎規(guī)則/配置的管理，就是常用的增刪改查顯算傳一把梭就完事了，但是關(guān)于規(guī)則的“啟用/停用”狀態(tài)這一點卻讓我差點踩了坑，恰巧之前我也對這一塊有過一些思考和總結(jié)，于是就借此機會，寫一篇文章來沉淀一下。
遇到的難題
創(chuàng)建好了三個規(guī)則，其中規(guī)則A和規(guī)則B是啟用狀態(tài)，而規(guī)則C是停用狀態(tài)。
接著，在創(chuàng)建某個方案的時候，需要選擇使用某個規(guī)則。一般來說都會做一個限制，就是：只能選擇“啟用”狀態(tài)的規(guī)則。
以上的內(nèi)容是一個工作中很常見的場景，一般大家也都會使用上述的方案來解決這個問題。
但是如果此時，換個視角來思考這個問題，可能很多產(chǎn)品朋友就會發(fā)現(xiàn)自己平時并沒有注意過這一塊的邏輯，是一個小小的盲區(qū)。
關(guān)于刪除，一般常用的方式是通過規(guī)則去反查方案，如果規(guī)則被方案關(guān)聯(lián)了，則不允許刪除；或者是方案被廢棄了/停用了之后，才允許刪除。
關(guān)于停用，一般來說會有兩種處理方式。一種是反查關(guān)聯(lián)性，判斷是否可以停用；另一種是不做關(guān)聯(lián)性判斷，直接停用，等具體使用到了此規(guī)則的時候，再判斷狀態(tài)是否可用。
第一種方式和上面的刪除的方案是一樣的，這里主要聊一下第二種直接停用的方式。第二種方式會有一點小坑，需要注意一下。
當規(guī)則停用了之后，編輯方案的時候，是否需要默認帶出停用了的規(guī)則？
例如，賬號和角色關(guān)聯(lián)就是一個很常見的功能，賬號可以停用，角色也可以停用。但是角色被停用了之后，賬號雖然還是關(guān)聯(lián)了這個角色，但是失去了相應的權(quán)限。
上面的圖片是從谷倉的OMS中找的截圖，當角色被停用了之后，編輯一個關(guān)聯(lián)了此角色的賬號時候，還是會帶出原來的綁定數(shù)據(jù)，但是點擊下拉的時候，是找不到被停用了的角色的。所以如果不點擊編輯，其實是判斷不出來角色已經(jīng)被停用了，即使點擊了編輯，也需要切換了不同的角色之后才能發(fā)現(xiàn)原來的角色被停用了，其實已經(jīng)不能再選不中了。
這個處理邏輯是正確的，但是也是有體驗不好的弊端，可以試著優(yōu)化一下。如果能在編輯的時候直接對角色加上一個tag標識，提示這個角色被停用了，應該會更好。對了，這個地方還有一個不算BUG的BUG，角色被停用了之后，這里展示的是角色的id，看起來也有點奇怪。
怎么解決的
看完了上面的案例，再回到停用規(guī)則這個問題上來，我們也可以效仿“賬號-角色”的關(guān)聯(lián)方式來處理。如果停用了規(guī)則，則對應的方案還是關(guān)聯(lián)了此條規(guī)則，只不過是方案可能不能生效而已，因為關(guān)聯(lián)的規(guī)則被停用了。
但是由于在做的計費方案，關(guān)聯(lián)了很多個規(guī)則，這樣就會在使用上帶來一些弊端：明明方案關(guān)聯(lián)了規(guī)則，但是卻不能生效，逐個排查了之后才發(fā)現(xiàn)，原來是某個規(guī)則被停用了，所以導致了方案未能生效。
鑒于上面的分析，我們內(nèi)部討論了之后發(fā)現(xiàn)，兩種方案都各有利弊，但是考慮到規(guī)則的維護和管理的難易程度，以及方案未生效之后的排查難度等。
最終的方案是：我們對大多數(shù)規(guī)則都沒有做“啟用/停用”的狀態(tài)。
原因如下：
一個規(guī)則會被多個方案所引用/關(guān)聯(lián)，如果規(guī)則停用了，那么方案可能也會受到影響，由于關(guān)聯(lián)的對象太多了，這樣做一些關(guān)聯(lián)性判斷的時候會增加很多工作量，需要去反查分別被什么方案關(guān)聯(lián)了； 對于很多規(guī)則來說，配置起來并不是很復雜，成本不會很高，所以啟用和停用的狀態(tài)用途并不大，如果想要停用那就直接刪除就好了； 停用和刪除，在很多場景下會有重復的作用，用戶一時間不知道該選擇停用還是刪除，過多的使用停用可能還會造成更多的冗余數(shù)據(jù)；
雖然大多數(shù)規(guī)則是沒“啟用/停用”狀態(tài)，但是針對一些特殊的規(guī)則還是保留了“啟用/停用”狀態(tài)的，這些規(guī)則一般會有以下一些特征：
配置比較麻煩，如果暫時性的不想要可以停用它而不是刪除，因為刪除后再重新配置比較費時間； 關(guān)聯(lián)性不是特別復雜，哪怕是同時有“啟用/停用”和“刪除”功能，但是關(guān)聯(lián)性不是很多，邏輯判斷不會特別復雜，兼顧的業(yè)務場景也比較多；
總結(jié)
關(guān)于“啟用/停用”，最開始我一直采用的一個設計方法論是：如果配置比較復雜，則加上“啟用/停用”，如果配置比較簡單，則不需要加上這個。
但是經(jīng)過這一次項目的小風波之后，我發(fā)現(xiàn)除了考慮這一層因素之外，還需要考慮一下關(guān)聯(lián)性的問題。如果關(guān)聯(lián)對象多，關(guān)聯(lián)的鏈路長，則盡量少用多余的狀態(tài)字段，這樣會導致開發(fā)、測試、使用的時候都更麻煩。
還有一個小細節(jié)要注意的就是，一定要和團隊中的其他產(chǎn)品、開發(fā)、測試等溝通好一個通用的解決方案，這樣可以打消很多不一致的疑惑感。讓大家都知道，到底什么時候用這個狀態(tài)，什么時候不用這個狀態(tài)。
以上便是最近項目的一個小小感觸，希望對大家有所啟發(fā)。如果對這一塊你也有其他的感觸和見解，也歡迎留言與我交流。
