後台設計那些坑

前一段時間上線了一個產品，經過一段時間的運營後，效果還可以，由於當時時間比較緊張，就把後台往後推了，所有數據暫時由資料庫表中添加。

這段時間沒那麼緊了，就在弄後台的事兒，結果沒有想的那麼簡單。一次次的與開發哥哥討（si)論(bi)，過程中當然是踩了很多坑，下面說正事兒。

很多剛入行的產品狗拿到第一個項目的第一件事兒就是找競品，下一件事兒就是一個字抄，因為無論怎麼樣你都會找到類似的產品，我看你怎麼做的，我抄你。但後台不同，你黑不到對方家裡去拉過來看看對方的後台做的怎麼樣，所以，做後台的時候需要自己認真的思考。應該怎麼設計後台能讓工作變的更輕鬆，這個需要費很大功夫。經過一段時間的踩坑，與開發哥哥撕逼後，得到了以下幾點血淋淋的教訓。

1、提交問題

一個小小的提交，千萬不要把他想的簡單了。你在新增數據的時候，可能由於網路或者其他的情況，提交按鈕被重複的點擊了很多次，你不優化，系統就不人性化，這樣你點擊的那很多次就發送了N多次的請求，錄入了N多條的數據。本來，運營得意洋洋的發布了一條新聞到平台，晚上12點正睡的很香，被老闆吵醒了，爬起來去看看我們網站上什麼情況！！！然後運營刷刷穿上衣服起來看了一下，卧槽，咋這麼多重複的數據？！！！我當時就提交了一次啊。確實，運營只想提交一次，但是當時點擊了很多次，傻乎乎的系統卻以為提交了很多次，造成了這個問題。

這個問題前端也會存在這樣的情況，我們當時是課程優惠碼兌換部分，用戶輸入優惠碼兌換時，點擊了好多次提交按鈕，結果後台生成了好多個訂單，導致了課程關聯的訂單不唯一，課程無法觀看。可是產品上線了，用戶湧進來了，訂單一直在增長，現在下線提交新版本不可能了，來不及，怎麼辦，只能先寫一個遇到重複訂單直接刪除的操作了。然後再加班改bug。

2、提交與發布

這個問題中也有一個提交的關鍵詞，不過與上面的問題完全不同。

遇到這個問題也是欠缺考慮，做的是在線課程平台，設計發布課程模塊時，填寫了課程的信息，點擊提交。然後到前台一看，卧槽，這個上面怎麼出現了一個空的課程，下面沒有視頻。幸虧是測試的環境，然後趕快把提交的button改為提交到後台資料庫，不發布課程。另置發布Button發布課程。

這個問題不只這裡會用到，發布新聞資訊，發布通知公告或者是其他的部分也可能會涉及到。如果用戶量大的話，你點提交就是發布的話，發布出去的那一瞬間可能有很多人已經看到了，刪除是來不及的，所以增加發布的操作是必要的。這裡可以有其他的方式代替，可以在提交之前點擊預覽。

3、第三方介面規範

這個坑歸技術，也歸自己。產品中使用了阿里雲的規範，阿里雲上傳視頻只允許同時上傳並轉碼10條數據，當時設計的時候還考慮到了同時傳輸數據的上限，給了個15條。然後出事兒了，測試的時候，卧槽，咋回事兒，每次我傳的數據怎麼都會給我幹掉？後來才了解到阿里的限制是10條，這個坑，踩的值，以後使用第三方服務的時候得先把他們的規範文檔了解清楚。

4、增刪改查中的「刪」

看到這裡，或許說，這個不是應該很簡單嗎？直接從表中刪除或者在表中將數據禁用不就得了嗎？事情不是這樣的，後台的管理模塊很多是關聯的，比如你發布一個課程，你需要選擇主講老師是誰，這個課程關聯的知識點有哪些，這些你都選擇完了，發布完了，課程也上線了，然後不知哪一天哪個老師由於不明原因得刪除，你咔咔的就刪掉了，過了一會兒運營過來了，哎，咋回事兒，頁面上這麼多Undefined是咋回事兒？！！！趕快排查，原來，這些課程還在線上，是這個老師講的，但是老師沒了課程還在，課程頁面請求老師的時候請求不到了，出現了Undefined，哎，這個當時怎麼就沒有考慮到呢。

5、數據邊界

這個問題在前台也會經常遇到，但是在後台，尤其涉及到數據統計的模塊會讓人很頭疼。做一個數據統計的模塊，比如統計某個課程的播放次數統計、銷售統計等等，多個維度交叉起來很讓人頭疼，在這裡首先要確定的是第一期具體要細化的那個程度。一個課程，關聯的維度有老師、用戶、價格、播放次數、收藏次數等等，如果全部統計會產生很大批量的數據。

剛開始設計的時候，文檔沒有寫明白，開發哥哥過來問，這個圖要展示一年的數據？卧槽，我後台壓力得多大？現在課程還不太多，後期課程成千上百個的時候，每天的數據我得存多少條？我請求多少條，別說後台，我的壓力多大？好吧，是我當時考慮的太理想，怎麼著，調整唄，數據超過一定量時取值根據周來取值，再超過一定量時根據月來取。

做數據統計模塊，每一張圖的背後都是一把辛酸淚。

說到這裡，還有一個小問題，數據取值的時候需要考慮剛上線，沒有數據的時候怎麼顯示，總不能刷刷的空白區域吧，自家用的後台管理還行，面向C端的產品，你的頁面一大片一大片的空白區域，讓用戶怎麼看，用戶會不會以為你的平台出問題了。比如課程列表，經過條件篩選後沒有相關的課程，這時設置一個空值提示，提示用戶還沒有課程，去別的地方看看，這樣給用戶一個引導就能解決問題。

做了很多事兒，也學了很多東西，踩坑沒問題，不踩坑才是問題所在（也有可能真的是大神），總之，後台設計這件事兒有很多要考慮，最好能夠先把前端的頁面拿過來，再把產品的信息結構理出來，把需要發布哪些信息提交哪些信息都關聯起來，然後再去著手做。