程序员过关斩将-- 喷一喷坑爹的面向UI编程
點(diǎn)擊上方“藍(lán)字”關(guān)注我們
菜菜哥,求你個(gè)事唄?
說來聽聽,假裝你男朋友可不干
不是哦,是正經(jīng)事。前幾天一個(gè)項(xiàng)目UI改了,好多人跟著加班修改,怎么樣盡量避免這種情況呢?
UI修改頂多和客戶端開發(fā)人員關(guān)系密切,你一個(gè)后端人員還牽扯那么大嗎?
我也納悶?zāi)?#xff1f;為什么會(huì)牽扯到我
看來你面向UI編程了!!
摒棄面向UI編程
為何噴起此次話題,因?yàn)榍安痪煤臀覀兪紫軜?gòu)師溝通,談起程序設(shè)計(jì)問題,一不小心把UI扯進(jìn)來,更把那些按照UI來編程的后臺(tái)工程師也扯了進(jìn)來。今天特意百度了一下(其實(shí)程序員應(yīng)該去google一下,奈何需要FQ),確實(shí)沒有面向UI編程這個(gè)概念在市面上流傳,大家可以當(dāng)我是首創(chuàng)吧。需要聲明一點(diǎn),這里噴的是服務(wù)器開發(fā)人員哦!!
我是一個(gè)極具打抱不平的人,浪跡編程十幾年,見過太多的程序員因?yàn)閁I改了,而跟著改程序。當(dāng)年菜菜一不小心踏入歧途的時(shí)候,每天看著《七天入門xxx》樂此不疲,猛烈的消化著書中“極具文化”的內(nèi)容。然后看著“該死”的產(chǎn)品經(jīng)理發(fā)過來的原型圖,費(fèi)勁腦汁把數(shù)據(jù)庫設(shè)計(jì)的特別符合原型圖,然后開心的干起CUAD,你看,編程就是如此簡單!!而且當(dāng)年覺得自己不可一世,可以進(jìn)階架構(gòu)師了
原來初生牛犢真的可以不怕虎,是因?yàn)榛柡?#xff1f;不,是因?yàn)榕龠€太傻X
無論是產(chǎn)經(jīng)經(jīng)理,還是前端開發(fā)人員,更或者是后端開發(fā)人員或者DBA,一切的工作都是圍繞業(yè)務(wù)開展的,產(chǎn)品經(jīng)理首先是第一個(gè)消化并理解業(yè)務(wù)的人,有的產(chǎn)品經(jīng)理自己還未消化業(yè)務(wù)就做出原型圖,概念圖腦圖等等,這些產(chǎn)品經(jīng)理其實(shí)才是該死的。當(dāng)產(chǎn)品把業(yè)務(wù)正確的用UI表達(dá)出來之后,業(yè)務(wù)便傳到了客戶端人員,至于服務(wù)端代碼編寫人員如果按照UI來理解業(yè)務(wù),甚至設(shè)計(jì)數(shù)據(jù)庫表,那多半是掉坑里了
無論是客戶端人員還是服務(wù)端人員,寫代碼之前首先第一要做的,而且也是最重要的就是消化業(yè)務(wù)內(nèi)容,把業(yè)務(wù)消化了寫起代碼來,有時(shí)候會(huì)對那些將來有擴(kuò)展性的地方情不自禁留出擴(kuò)展點(diǎn)。業(yè)務(wù)有時(shí)候就是要做一件事的過程,數(shù)據(jù)的流向而已,整體把握了才能設(shè)計(jì)出可以掌控的系統(tǒng)。
面向業(yè)務(wù)編程
其實(shí)上面說了這么多,都比較“抽象”,別人會(huì)說你寫的什么JB玩意,罵歸罵,但是不能侮辱我對技術(shù)的熱愛~~~
噴了那么多,看一個(gè)原型,話說這個(gè)產(chǎn)品畫的還是不錯(cuò)的
一個(gè)簡單的發(fā)帖動(dòng)態(tài)內(nèi)容的展示,如此簡單的需求,你的系統(tǒng)該如何設(shè)計(jì)呢?
錯(cuò)誤1
根據(jù)UI的設(shè)計(jì),很多人第一步就開始設(shè)計(jì)數(shù)據(jù)庫對應(yīng)UI
| Id | 動(dòng)態(tài)id |
| PublishUserId | 發(fā)布人id |
| PublishUserName | 發(fā)布人姓名 |
| PublisherUserImg | 發(fā)布人頭像 |
| ..... | .... |
很多人會(huì)這樣設(shè)計(jì),其中不乏有些高級程序員,我自認(rèn)為這樣是錯(cuò)誤的,說說我的想法,歡迎你們來噴。這是一個(gè)簡單的動(dòng)態(tài)展示,仔細(xì)分析你會(huì)發(fā)現(xiàn)這個(gè)業(yè)務(wù)其實(shí)包含一些子業(yè)務(wù):動(dòng)態(tài)的發(fā)布人業(yè)務(wù),動(dòng)態(tài)內(nèi)容業(yè)務(wù),動(dòng)態(tài)內(nèi)容產(chǎn)生的外圍業(yè)務(wù)(點(diǎn)贊,留言,收藏等),如果硬是對應(yīng)到表設(shè)計(jì),也應(yīng)該包含這三部分內(nèi)容。
任何數(shù)據(jù)庫設(shè)計(jì)都不應(yīng)該一一對應(yīng)UI,UI只是你設(shè)計(jì)的參考而已,只是很多情況下業(yè)務(wù)模型正好和UI對應(yīng)而已
錯(cuò)誤2
很多人把發(fā)布人的姓名,頭像保存在了動(dòng)態(tài)表,我認(rèn)為這個(gè)還要看這個(gè)動(dòng)態(tài)的定義,如果動(dòng)態(tài)的發(fā)布人明確了不會(huì)隨著發(fā)布人信息的修改而變動(dòng),這個(gè)確實(shí)應(yīng)該一次性保存,如果反之,只存一個(gè)用戶Id足以,這樣還可以避免因?yàn)榘l(fā)布人修改信息而帶來的同步數(shù)據(jù)問題,要知道數(shù)據(jù)一致性這塊其實(shí)是很煩人的。
不要讓UI的顯示內(nèi)容,影響你的業(yè)務(wù)設(shè)計(jì)
錯(cuò)誤3
動(dòng)態(tài)的內(nèi)容后續(xù)產(chǎn)生的數(shù)據(jù)(點(diǎn)贊,收藏,評論)這些業(yè)務(wù)在動(dòng)態(tài)中都有量化,那這個(gè)具體的數(shù)據(jù)量化值很多人選擇在動(dòng)態(tài)表中添加對應(yīng)的字段(點(diǎn)贊總量,收藏總量等等)。其實(shí)我不建議這樣做,原因如下:
1. 如果新建了這些字段來保存,動(dòng)態(tài)的每一次產(chǎn)生結(jié)果都需要更新對應(yīng)的字段,同時(shí)還要保證這個(gè)值和詳細(xì)列表的數(shù)據(jù)一致性,不能產(chǎn)生100條評論,但是評論列表只有99條的情況發(fā)生。
2. 如果將來又新加了一條新的業(yè)務(wù),比如分享的數(shù)量,那是不是還要在加一個(gè)分享量的數(shù)據(jù)表字段呢?
3. 如果你讀過菜菜以前的文章,應(yīng)該知道菜菜一貫的尿性,這種動(dòng)態(tài)的東西最適合做緩存,無論你愿意與否。至于這些點(diǎn)贊總數(shù)等這些類似業(yè)務(wù),仔細(xì)分析只不過是屬于動(dòng)態(tài)內(nèi)容的后續(xù)業(yè)務(wù),應(yīng)該包含在整體業(yè)務(wù)之中,如果非要擼一行代碼:
public class Topic{public int Id; ? ?public string Content;... ? ?public int ThumbUpNumber: //點(diǎn)贊數(shù)量public int CommentNumber; //評論數(shù)量...}需要注意一點(diǎn):我以上代碼代表的是業(yè)務(wù)對象,可不是對應(yīng)的DB中的表哦,這個(gè)業(yè)務(wù)對象也是我們要緩存的對象,當(dāng)新加一條評論或點(diǎn)贊的時(shí)候,只不過是緩存數(shù)據(jù)的+1操作而已,至于這個(gè)數(shù)據(jù)值的初始化,完全可以由詳情表來提供,在真實(shí)的業(yè)務(wù)中,點(diǎn)贊或者評論的數(shù)據(jù)量很少到達(dá)萬級別,所以對于select count(0)這個(gè)操作來說都不是問題,一旦初始化完成做了緩存,后續(xù)的增加數(shù)量完全在內(nèi)存中完成。
這里我想噴:任何業(yè)務(wù)數(shù)據(jù)庫都不是架構(gòu)設(shè)計(jì)的中心
寫在最后
一個(gè)業(yè)務(wù)的成敗在于產(chǎn)品設(shè)計(jì),一個(gè)系統(tǒng)設(shè)計(jì)的好壞,成敗在于程序員,在業(yè)務(wù)正確的情況下,請先消化掉業(yè)務(wù)再開始設(shè)計(jì)系統(tǒng),UI只是你消化業(yè)務(wù)的參考,UI只是你業(yè)務(wù)的具體可視化體現(xiàn)。
完
●程序員修神之路--為什么我會(huì)了SOA,你們還要逼我學(xué)微服務(wù)?
●程序員過關(guān)斬將--數(shù)據(jù)庫的樂觀鎖和悲觀鎖并非真實(shí)的鎖
●程序員修神之路--設(shè)計(jì)一套R(shí)PC框架并非易事
●程序員過關(guān)斬將--要想獲取我的用戶信息,就得按照規(guī)矩來
●程序員過關(guān)斬將--更加優(yōu)雅的Token認(rèn)證方式JWT
●程序員過關(guān)斬將--cookie和session的關(guān)系其實(shí)很簡單
●程序員修神之路--用NOSql給高并發(fā)系統(tǒng)加速
●程序員修神之路--高并發(fā)系統(tǒng)設(shè)計(jì)負(fù)載均衡架構(gòu)
●程序員過關(guān)斬將--你為什么還在用存儲(chǔ)過程?
●程序員修神之路--問世間異步為何物?
●程序員修神之路--提高網(wǎng)站的吞吐
長按添加菜菜好友
關(guān)注后回復(fù):“大禮包”和“福利”,領(lǐng)取驚喜
總結(jié)
以上是生活随笔為你收集整理的程序员过关斩将-- 喷一喷坑爹的面向UI编程的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: OpenSilver: 通过WebAss
- 下一篇: 集成平台集群任务动态分派