點擊上方“藍字”關(guān)注我們

菜菜哥，求你個事唄？

說來聽聽，假裝你男朋友可不干

不是哦，是正經(jīng)事。前幾天一個項目UI改了，好多人跟著加班修改，怎么樣盡量避免這種情況呢？

UI修改頂多和客戶端開發(fā)人員關(guān)系密切，你一個后端人員還牽扯那么大嗎？

我也納悶呢？為什么會牽扯到我

看來你面向UI編程了！！

摒棄面向UI編程

為何噴起此次話題，因為前不久和我們首席架構(gòu)師溝通，談起程序設(shè)計問題，一不小心把UI扯進來，更把那些按照UI來編程的后臺工程師也扯了進來。今天特意百度了一下（其實程序員應該去google一下，奈何需要FQ），確實沒有面向UI編程這個概念在市面上流傳，大家可以當我是首創(chuàng)吧。需要聲明一點，這里噴的是服務(wù)器開發(fā)人員哦！！

我是一個極具打抱不平的人，浪跡編程十幾年，見過太多的程序員因為UI改了，而跟著改程序。當年菜菜一不小心踏入歧途的時候，每天看著《七天入門xxx》樂此不疲，猛烈的消化著書中“極具文化”的內(nèi)容。然后看著“該死”的產(chǎn)品經(jīng)理發(fā)過來的原型圖，費勁腦汁把數(shù)據(jù)庫設(shè)計的特別符合原型圖，然后開心的干起CUAD，你看，編程就是如此簡單！！而且當年覺得自己不可一世，可以進階架構(gòu)師了

原來初生牛犢真的可以不怕虎，是因為虎厲害嗎？不，是因為牛犢還太傻X

無論是產(chǎn)經(jīng)經(jīng)理，還是前端開發(fā)人員，更或者是后端開發(fā)人員或者DBA，一切的工作都是圍繞業(yè)務(wù)開展的，產(chǎn)品經(jīng)理首先是第一個消化并理解業(yè)務(wù)的人，有的產(chǎn)品經(jīng)理自己還未消化業(yè)務(wù)就做出原型圖，概念圖腦圖等等，這些產(chǎn)品經(jīng)理其實才是該死的。當產(chǎn)品把業(yè)務(wù)正確的用UI表達出來之后，業(yè)務(wù)便傳到了客戶端人員，至于服務(wù)端代碼編寫人員如果按照UI來理解業(yè)務(wù)，甚至設(shè)計數(shù)據(jù)庫表，那多半是掉坑里了

無論是客戶端人員還是服務(wù)端人員，寫代碼之前首先第一要做的，而且也是最重要的就是消化業(yè)務(wù)內(nèi)容，把業(yè)務(wù)消化了寫起代碼來，有時候會對那些將來有擴展性的地方情不自禁留出擴展點。業(yè)務(wù)有時候就是要做一件事的過程，數(shù)據(jù)的流向而已，整體把握了才能設(shè)計出可以掌控的系統(tǒng)。

面向業(yè)務(wù)編程

其實上面說了這么多，都比較“抽象”，別人會說你寫的什么JB玩意，罵歸罵，但是不能侮辱我對技術(shù)的熱愛~~~

噴了那么多，看一個原型，話說這個產(chǎn)品畫的還是不錯的

一個簡單的發(fā)帖動態(tài)內(nèi)容的展示，如此簡單的需求，你的系統(tǒng)該如何設(shè)計呢？

錯誤1

根據(jù)UI的設(shè)計，很多人第一步就開始設(shè)計數(shù)據(jù)庫對應UI

字段介紹

Id	動態(tài)id
PublishUserId	發(fā)布人id
PublishUserName	發(fā)布人姓名
PublisherUserImg	發(fā)布人頭像
.....	....

很多人會這樣設(shè)計，其中不乏有些高級程序員，我自認為這樣是錯誤的，說說我的想法，歡迎你們來噴。這是一個簡單的動態(tài)展示，仔細分析你會發(fā)現(xiàn)這個業(yè)務(wù)其實包含一些子業(yè)務(wù)：動態(tài)的發(fā)布人業(yè)務(wù)，動態(tài)內(nèi)容業(yè)務(wù)，動態(tài)內(nèi)容產(chǎn)生的外圍業(yè)務(wù)（點贊，留言，收藏等），如果硬是對應到表設(shè)計，也應該包含這三部分內(nèi)容。

任何數(shù)據(jù)庫設(shè)計都不應該一一對應UI，UI只是你設(shè)計的參考而已，只是很多情況下業(yè)務(wù)模型正好和UI對應而已

錯誤2

很多人把發(fā)布人的姓名，頭像保存在了動態(tài)表，我認為這個還要看這個動態(tài)的定義，如果動態(tài)的發(fā)布人明確了不會隨著發(fā)布人信息的修改而變動，這個確實應該一次性保存，如果反之，只存一個用戶Id足以，這樣還可以避免因為發(fā)布人修改信息而帶來的同步數(shù)據(jù)問題，要知道數(shù)據(jù)一致性這塊其實是很煩人的。

不要讓UI的顯示內(nèi)容，影響你的業(yè)務(wù)設(shè)計

錯誤3

動態(tài)的內(nèi)容后續(xù)產(chǎn)生的數(shù)據(jù)（點贊，收藏，評論）這些業(yè)務(wù)在動態(tài)中都有量化，那這個具體的數(shù)據(jù)量化值很多人選擇在動態(tài)表中添加對應的字段（點贊總量，收藏總量等等）。其實我不建議這樣做，原因如下：

1. 如果新建了這些字段來保存，動態(tài)的每一次產(chǎn)生結(jié)果都需要更新對應的字段，同時還要保證這個值和詳細列表的數(shù)據(jù)一致性，不能產(chǎn)生100條評論，但是評論列表只有99條的情況發(fā)生。

2. 如果將來又新加了一條新的業(yè)務(wù)，比如分享的數(shù)量，那是不是還要在加一個分享量的數(shù)據(jù)表字段呢？

3. 如果你讀過菜菜以前的文章，應該知道菜菜一貫的尿性，這種動態(tài)的東西最適合做緩存，無論你愿意與否。至于這些點贊總數(shù)等這些類似業(yè)務(wù)，仔細分析只不過是屬于動態(tài)內(nèi)容的后續(xù)業(yè)務(wù)，應該包含在整體業(yè)務(wù)之中，如果非要擼一行代碼：

public class Topic{public int Id; ? ?public string Content;... ? ?public int ThumbUpNumber: //點贊數(shù)量public int CommentNumber; //評論數(shù)量...}

需要注意一點：我以上代碼代表的是業(yè)務(wù)對象，可不是對應的DB中的表哦，這個業(yè)務(wù)對象也是我們要緩存的對象，當新加一條評論或點贊的時候，只不過是緩存數(shù)據(jù)的+1操作而已，至于這個數(shù)據(jù)值的初始化，完全可以由詳情表來提供，在真實的業(yè)務(wù)中，點贊或者評論的數(shù)據(jù)量很少到達萬級別，所以對于select count（0）這個操作來說都不是問題，一旦初始化完成做了緩存，后續(xù)的增加數(shù)量完全在內(nèi)存中完成。

這里我想噴：任何業(yè)務(wù)數(shù)據(jù)庫都不是架構(gòu)設(shè)計的中心

寫在最后

一個業(yè)務(wù)的成敗在于產(chǎn)品設(shè)計，一個系統(tǒng)設(shè)計的好壞，成敗在于程序員，在業(yè)務(wù)正確的情況下，請先消化掉業(yè)務(wù)再開始設(shè)計系統(tǒng)，UI只是你消化業(yè)務(wù)的參考，UI只是你業(yè)務(wù)的具體可視化體現(xiàn)。

完

●程序員修神之路--為什么我會了SOA，你們還要逼我學微服務(wù)？

●程序員過關(guān)斬將--數(shù)據(jù)庫的樂觀鎖和悲觀鎖并非真實的鎖

●程序員修神之路--設(shè)計一套RPC框架并非易事

●程序員過關(guān)斬將--要想獲取我的用戶信息，就得按照規(guī)矩來

●程序員過關(guān)斬將--更加優(yōu)雅的Token認證方式JWT

●程序員過關(guān)斬將--cookie和session的關(guān)系其實很簡單

●程序員修神之路--用NOSql給高并發(fā)系統(tǒng)加速

●程序員修神之路--高并發(fā)系統(tǒng)設(shè)計負載均衡架構(gòu)

●程序員過關(guān)斬將--你為什么還在用存儲過程？

●程序員修神之路--問世間異步為何物？

●程序員修神之路--提高網(wǎng)站的吞吐

長按添加菜菜好友

關(guān)注后回復：“大禮包”和“福利”，領(lǐng)取驚喜

總結(jié)

以上是生活随笔為你收集整理的程序员过关斩将-- 喷一喷坑爹的面向UI编程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。