程式設計師過關斬將-- 噴一噴坑爹的面向UI程式設計
阿新 • • 發佈：2020-03-16
### 摒棄面向UI程式設計
為何噴起此次話題，因為前不久和我們首席架構師溝通，談起程式設計問題，一不小心把UI扯進來，更把那些按照UI來程式設計的後臺工程師也扯了進來。今天特意百度了一下（其實程式設計師應該去google一下，奈何需要FQ），確實沒有面向UI程式設計這個概念在市面上流傳，大家可以當我是首創吧。需要宣告一點，這裡噴的是伺服器開發人員哦！！
我是一個極具打抱不平的人，浪跡程式設計十幾年，見過太多的程式設計師因為UI改了，而跟著改程式。當年菜菜一不小心踏入歧途的時候，每天看著《七天入門xxx》樂此不疲，猛烈的消化著書中“極具文化”的內容。然後看著“該死”的產品經理髮過來的原型圖，費勁腦汁把資料庫設計的特別符合原型圖，然後開心的幹起CUAD，你看，程式設計就是如此簡單！！ 而且當年覺得自己不可一世，可以進階架構師了
>原來初生牛犢真的可以不怕虎，是因為虎厲害嗎？不，是因為牛犢還太傻X
無論是產經經理，還是前端開發人員，更或者是後端開發人員或者DBA，一切的工作都是圍繞業務開展的，產品經理首先是第一個消化並理解業務的人，有的產品經理自己還未消化業務就做出原型圖，概念圖腦圖等等，這些產品經理其實才是該死的。當產品把業務正確的用UI表達出來之後，業務便傳到了客戶端人員，至於服務端程式碼編寫人員如果按照UI來理解業務，甚至設計資料庫表，那多半是掉坑裡了
無論是客戶端人員還是服務端人員，寫程式碼之前首先第一要做的，而且也是最重要的就是消化業務內容，把業務消化了寫起程式碼來，有時候會對那些將來有擴充套件性的地方情不自禁留出擴充套件點。業務有時候就是要做一件事的過程，資料的流向而已，整體把握了才能設計出可以掌控的系統。
### 面向業務程式設計
其實上面說了這麼多，都比較“抽象”，別人會說你寫的什麼JB玩意，罵歸罵，但是不能侮辱我對技術的熱愛~~~
噴了那麼多看一個原型，話說這個產品畫的還是不錯的
一個簡單的發帖動態內容的展示，如此簡單的需求，你的系統該如何設計呢？
##### 錯誤1
根據UI的設計，很多人第一步就開始設計資料庫對應UI
欄位 | 介紹
---|---
Id | 動態id
PublishUserId | 釋出人id
PublishUserName | 釋出人姓名
PublisherUserImg | 釋出人頭像
..... | ....
很多人會這樣設計，其中不乏有些高階程式設計師，我自認為這樣是錯誤的，說說我的想法，歡迎你們來噴。這是一個簡單的動態展示，仔細分析你會發現這個業務其實包含一些子業務：動態的釋出人業務，動態內容業務，動態內容產生的外圍業務（點贊，留言，收藏等），如果硬是對應到表設計，也應該包含這三部分內容。
>任何資料庫設計都不應該一一對應UI，UI只是你設計的參考而已，只是很多情況下業務模型正好和UI對應而已
##### 錯誤2
很多人把釋出人的姓名，頭像儲存在了動態表，我認為這個還要看這個動態的定義，如果動態的釋出人明確了不會隨著釋出人資訊的修改而變動，這個確實應該一次性儲存，如果反之，只存一個使用者Id足以，這樣還可以避免因為釋出人修改資訊而帶來的同步資料問題，要知道資料一致性這塊其實是很煩人的。
>不要讓UI的顯示內容，影響你的業務設計
##### 錯誤3
動態的內容後續產生的資料（點贊，收藏，評論）這些業務在動態中都有量化，那這個具體的資料量化值很多人選擇在動態表中新增對應的欄位（點贊總量，收藏總量等等）。其實我不建議這樣做，原因如下：
1. 如果新建了這些欄位來儲存，動態的每一次產生結果都需要更新對應的欄位，同時還要保證這個值和詳細列表的資料一致性，不能產生100條評論，但是評論列表只有99條的情況發生。
2. 如果將來又新加了一條新的業務，比如分享的數量，那是不是還要在加一個分享量的資料表字段呢？
3. 如果你讀過菜菜以前的文章，應該知道菜菜一貫的尿性，這種動態的東西最適合做快取，無論你願意與否。至於這些點贊總數等這些類似業務，仔細分析只不過是屬於動態內容的後續業務，應該包含在整體業務之中，如果非要擼一行程式碼：
```
public class Topic
{
public int Id;
public string Content;
...
public int ThumbUpNumber: //點贊數量
public int CommentNumber; //評論數量
...
}
```
需要注意一點：我以上程式碼代表的是業務物件，可不是對應的DB中的表哦，這個業務物件也是我們要快取的物件，當新加一條評論或點讚的時候，只不過是快取資料的+1操作而已，至於這個資料值的初始化，完全可以由詳情表來提供，在真實的業務中，點贊或者評論的資料量很少到達萬級別，所以對於select count（0）這個操作來說都不是問題，一旦初始化完成做了快取，後續的增加數量完全在記憶體中完成。
>這裡我想噴：任何業務資料庫都不是架構設計的中心
### 寫在最後
一個業務的成敗在於產品設計，一個系統設計的好壞，成敗在於程式設計師，在業務正確的情況下，請先消化掉業務再開始設計系統，UI只是你消化業務的參考，UI只是你業務的具體視覺化