這又是一篇記錄+閑聊+整理貼。最近在一個(gè)人做一個(gè)不算很小的項(xiàng)目，所以想把思路和一些設(shè)計(jì)整理下來，方便以后遇到相同需求可以快速的有思路，如果能順便幫助一頭霧水的別人那是更好不過的了。
首先說點(diǎn)閑話，工作以來沒去過大公司，團(tuán)隊(duì)人數(shù)最多的就是第一家公司，標(biāo)準(zhǔn)外包續(xù)命的有自己理想的一家公司。老板是個(gè)老技術(shù)，也是我至今為止都非常感謝的一個(gè)人（雖然現(xiàn)在沒有聯(lián)系了）?，F(xiàn)在的代碼書寫的習(xí)慣，項(xiàng)目開發(fā)的流程和思路，一些常用工具類的使用等，都是那時(shí)候?qū)W會(huì)的。在此也祝那家公司越來越好吧。

初中級(jí)程序員日常工作

首先，這么多年工作以來，也做過不少的項(xiàng)目了，有二次開發(fā)的，有項(xiàng)目重構(gòu)的，有維護(hù)現(xiàn)有的，也有從0開始的。而二次開發(fā)又分為從頭開始和接手原來的。
反正目前為止我差不多都做過。這里簡(jiǎn)單的截個(gè)圖表示下我自己的理解（個(gè)人理解，錯(cuò)了或者不全歡迎指出，但是不接受惡意攻擊）。

我心目中的初中級(jí)程序員日常工作

因?yàn)槲耶吘菇?jīng)驗(yàn)也就這么多，所以不敢說我理解的就很全面了。但是這些都是我遇到過，經(jīng)歷過的。簡(jiǎn)單的說下目前為止待過三家公司。

• 第一家工作時(shí)間最長(zhǎng)是個(gè)7個(gè)人的外包公司，然后大大小小的接過很多個(gè)項(xiàng)目。一個(gè)星期一個(gè)小程序之類的很正常。剩下網(wǎng)站，app等都有涉及。其中從0開始做項(xiàng)目比較多，但是這期間也接過一次二次開發(fā)的項(xiàng)目。就是甲方之前自己養(yǎng)個(gè)團(tuán)隊(duì)開發(fā)，一年多了也沒出完整結(jié)果，所以后來直接找了我們二次開發(fā)。
• 第二家公司的個(gè)創(chuàng)業(yè)公司，老板用php寫了一個(gè)項(xiàng)目，但是因?yàn)榭紤]到性能還有其他原因吧，所以只招了我一個(gè)java程序員，還有一個(gè)前端，想要用java重構(gòu)這個(gè)項(xiàng)目（最后因?yàn)榉N種原因所以還沒重構(gòu)完我就離職了）。
• 第三家公司就是現(xiàn)在寫這篇筆記時(shí)所在的公司。我們公司是做自己的產(chǎn)品的，不過在我入職的時(shí)候這個(gè)項(xiàng)目已經(jīng)接近尾聲。另外還有個(gè)16年的項(xiàng)目也在維護(hù)。所以入職后工作內(nèi)容百分之二十維護(hù)老項(xiàng)目，百分之三十是自己的產(chǎn)品修修改改，沒事加個(gè)功能加個(gè)接口啥的。比較大的改動(dòng)就是其中有兩個(gè)模塊是后來要去添加的，所以從數(shù)據(jù)庫到代碼邏輯流程都需要重新定義，和之前的業(yè)務(wù)等關(guān)系也不大，我把他定義為二次開發(fā)的一種。另外百分之五十就是現(xiàn)在，因?yàn)橐咔樵蛩怨居幸欢ǖ睦щy，而且推廣遇到很大的阻力，所以2020年的工作計(jì)劃是外包續(xù)命。

簡(jiǎn)單的敘述一下工作經(jīng)歷，然后各個(gè)崗位和不同公司中主要的工作內(nèi)容也簡(jiǎn)單說了下。剩下的一些別的內(nèi)容，比如寫個(gè)專利書，寫個(gè)說明書，寫個(gè)軟件著作權(quán)，寫個(gè)三級(jí)等保申請(qǐng)之類的感覺是雜活，工作中都用到了，但是沒啥意義。所以不多說了。
對(duì)了，一些常用的第三方接入什么的，例如阿里云，騰訊云的一些設(shè)置配置，獲取小程序appid，appKey啥的，這些有的也算是工作中一部分，比如我第二家公司這些所有的配置，或者說買什么服務(wù)也都是我在做，花多少錢直接找老板報(bào)銷。但是第一家公司這些都是老板處理，我需要什么直接朝他要就行了。至于現(xiàn)在這家屬于有些自己要弄，有些要找領(lǐng)導(dǎo)要。反正這些都不難，自己看人家的官方文檔啥的就行了。
畢竟開發(fā)崗位最終肯定還是要落實(shí)到開發(fā)和代碼上。

從需求文檔開始

其實(shí)這個(gè)沒辦法一概而論的給一個(gè)思路解決所有問題，針對(duì)我自己遇到的這么多的工作中也有不一樣的側(cè)重點(diǎn)。但是熟讀需求文檔絕對(duì)是所有開發(fā)的前提。
而且我的習(xí)慣是熟讀開發(fā)文檔，在腦子里先過一遍怎么實(shí)現(xiàn)。而且需求文檔上經(jīng)常會(huì)有一些坑，需要我們自己注意。打個(gè)比方，如下截圖是我們需求文檔中截取的一部分內(nèi)容：

image.png

• 積分：是不是需要一套完整的積分體系？是每天登陸給一定積分，還是在線一定時(shí)間或者做了什么動(dòng)作給積分？
• 等級(jí)：用戶等級(jí)怎么判斷，消費(fèi)到多少還是注冊(cè)多長(zhǎng)時(shí)間還是做了什么動(dòng)作升級(jí)（雖然這個(gè)一般是和積分關(guān)聯(lián)的）？
• 勛章：勛章最基本的要有個(gè)勛章庫吧？比如有什么種類的勛章，每個(gè)勛章的獲得條件之類的。
• 簽到：首先一天的簽到是好做的，但是這個(gè)簽到要在哪里用到？怎么展示？可不可以補(bǔ)簽？是展示本月的簽到情況還是可以查詢所有的簽到情況？

說實(shí)話，上面的八個(gè)字四個(gè)詞可以延伸出來的東西很多。甚至細(xì)節(jié)上的實(shí)現(xiàn)也各有不同。雖然都是基本功能，但是我在看了需求文檔后還是和領(lǐng)導(dǎo)仔細(xì)詢問了，并且我個(gè)人的習(xí)慣是問清楚了，并且記錄下來，把文件也發(fā)給領(lǐng)導(dǎo)確認(rèn)沒問題了然后才會(huì)去做。這樣以后如果有改動(dòng)或者如果說做出來甲方說和他想要的不一樣我也有話可說，這個(gè)習(xí)慣我也推薦給大家，做之前一定要把需求確定了并且砸實(shí)了。當(dāng)時(shí)在第一家公司我就受過這個(gè)坑。

不懂就問，確定再做

那時(shí)候入行時(shí)間也短，當(dāng)時(shí)是一個(gè)搜索的功能，甲方的需求說只需要輸入名字查詢。我就只簡(jiǎn)單的做了個(gè)搜索，并且當(dāng)時(shí)是口頭上確認(rèn)了，可能我沒說清楚，甲方的人也沒注意聽。反正我說這塊這么做那邊的人肯定是說ok了。但是等實(shí)現(xiàn)了以后甲方測(cè)試軟件的時(shí)候，說這里和他想要的不一樣。然后我當(dāng)時(shí)說都確定了的，你們也同意了的，但是甲方就是說沒有。然后我當(dāng)時(shí)也懦弱，好一點(diǎn)的是這塊內(nèi)容不是那么難改動(dòng)，所以最后改完了。然后我們老板把我罵哭了。哈哈，真的是哭了一個(gè)多小時(shí)吧，一方面的委屈，另一方面是恨，我拿著炸藥包炸當(dāng)時(shí)對(duì)接的甲方的家的心都有了。還有一方面是對(duì)自己的恨，當(dāng)時(shí)對(duì)接我什么證據(jù)都沒留下，所以才造成了現(xiàn)在的一切。反正哭了一個(gè)多小時(shí)之后，再做什么都習(xí)慣性用文件和文字的形式來交接和確認(rèn)。哪怕有時(shí)候和領(lǐng)導(dǎo)口頭上談成了什么我都會(huì)用文檔微信發(fā)給領(lǐng)導(dǎo)或者用文字發(fā)給領(lǐng)導(dǎo)再確認(rèn)一次。有時(shí)候不要怕麻煩，也不要怕麻煩別人。畢竟多確認(rèn)一下浪費(fèi)不了多少時(shí)間，你不能確定和你對(duì)接的是人是狗。所以。。。

好了，上面就是一個(gè)過來人的簡(jiǎn)單建議。然后繼續(xù)說這個(gè)需求的八個(gè)字，不確認(rèn)好了匆匆做出來，如果發(fā)現(xiàn)甲方的一些奇葩要求目前的設(shè)計(jì)不好實(shí)現(xiàn)或者不能實(shí)現(xiàn)，那就尷尬了，所以說我的建議熟讀需求文檔，一點(diǎn)點(diǎn)在自己腦海里建立一個(gè)完整的模型。大概做到閉上眼睛能把這個(gè)項(xiàng)目從頭到尾跑一遍而不卡殼。同時(shí)把這個(gè)講給甲方或者領(lǐng)導(dǎo)聽都沒有異議再開始真正的做。
這個(gè)還是要感謝第一家公司，讓我學(xué)會(huì)了簡(jiǎn)單的word畫圖。比原型圖還要簡(jiǎn)陋也沒關(guān)系，丑也沒關(guān)系。但是按鈕，模塊，跳轉(zhuǎn)關(guān)系啥的寫清楚就好。把整個(gè)項(xiàng)目的草圖畫一遍，加深了自己對(duì)業(yè)務(wù)的理解，也讓自己的邏輯關(guān)系數(shù)據(jù)關(guān)系有個(gè)完整的建立。

用戶頁

這個(gè)圖我自己看都辣眼睛。。反正就這樣了，黃色的代表點(diǎn)了要走接口的。白色就是寫死的。點(diǎn)了不走接口的，前端愛咋做咋做吧。然后這個(gè)頁面是我覺得用戶那個(gè)頁面的。劃重點(diǎn)??！這個(gè)圖是我為了展示出來特意畫的?。≌Ｎ医o自己和領(lǐng)導(dǎo)看的比這個(gè)還要丑。。。但是畫的丑時(shí)間也快，就是兩分鐘一張圖的那種。之前的龜毛同事，一個(gè)后端話這種圖畫出來跟原型圖似的。。說真的一方面挺佩服畫工好，另一方面話這個(gè)草圖能畫一天也是佩服了。反正這個(gè)就是個(gè)人的建議。但是這么做的好處是每一個(gè)圖都對(duì)過以后，照著圖來做，不容易出錯(cuò)。
然后好多時(shí)候需求文檔可能不是很專業(yè)，所以有問題一定要在設(shè)計(jì)之前就解決了！不然可能做的時(shí)候坎坷的多。反正目前來講我只和領(lǐng)導(dǎo)還有甲方對(duì)接過，聽說大公司是有專門的項(xiàng)目經(jīng)理的，唔，羨慕。
然后如果你畫不出這個(gè)圖的流程，或者說你自己腦子里不能順下來就說明你對(duì)需求還是不熟，一定不能抱著對(duì)付的心態(tài)開工。
正常我個(gè)人來講，我覺得單單是看需求文檔就是一個(gè)5個(gè)工作日的工期（以4個(gè)月開發(fā)時(shí)間來講）。然后下一步數(shù)據(jù)庫設(shè)計(jì)又是一個(gè)星期。

數(shù)據(jù)庫設(shè)計(jì)

上面我說了，數(shù)據(jù)庫的設(shè)計(jì)一般也是一個(gè)星期也就是5個(gè)工作日的工期。這里先熟悉了業(yè)務(wù)流程和邏輯，對(duì)我們?cè)O(shè)計(jì)數(shù)據(jù)庫的表等好處是大大的。
我簡(jiǎn)單舉兩個(gè)例子：

• 比如釘釘上的上下班簽到，甚至能往上翻記錄的，這種最好每個(gè)用戶每次的簽到單獨(dú)記錄一條數(shù)據(jù)。因?yàn)槌撕灥竭€要具體的時(shí)間。
• 再比如?？蜕系拇蚩▽W(xué)習(xí)，說實(shí)話我不知道人家怎么實(shí)現(xiàn)的，但是只能打完卡顯示打卡數(shù)+1，也不能具體查看哪天打卡了，也沒別的地方展示。我覺得可以做累加。每個(gè)用戶對(duì)應(yīng)簽到天數(shù)。然后打卡的按鈕一天只能觸發(fā)一次（前端實(shí)現(xiàn)）。打卡就+1就好了，這樣做多簡(jiǎn)單又方便。不過人家不一定做得這么low，我就是猜的。

反正這就是說明一個(gè)簡(jiǎn)單的簽到功能不同設(shè)計(jì)的數(shù)據(jù)庫也不同。所以說數(shù)據(jù)庫的設(shè)計(jì)一定要依賴于具體的業(yè)務(wù)。
我是打算有時(shí)間把這些常用的業(yè)務(wù)的數(shù)據(jù)庫的常用設(shè)計(jì)整理下。比如說權(quán)限控制的數(shù)據(jù)庫，我一直習(xí)慣于用shiro的那五張表實(shí)現(xiàn)。雖然不用或者不那么做也可以，但是習(xí)慣了。
還有算是常用的好友是單向好友還是雙向好友啥的。設(shè)計(jì)成多對(duì)多比較靈活。
關(guān)注，收藏什么的。這些其實(shí)都有一些常用是設(shè)計(jì)（我反正知道的大多數(shù)為了靈活性而增加記錄的條數(shù)）。但是之前也做過一個(gè)點(diǎn)贊功能，是點(diǎn)完贊不能取消的，所以是用點(diǎn)贊用戶名的拼接實(shí)現(xiàn)的。缺點(diǎn)也就是點(diǎn)完贊取消啥的不好做。

• 角色表： 另外我這邊的做法是所用用戶一張user表。然后具體的角色比如商家，客戶，管理員，客服，主播等角色再用另外的表寫各自的信息，然后做外鍵關(guān)聯(lián)。感覺這個(gè)也是常規(guī)做法。
• 訂單表： 因?yàn)槲疫@個(gè)項(xiàng)目算是電商項(xiàng)目，所以訂單必不可少，訂單商品一對(duì)多，還有訂單和物流單一對(duì)一之類的，都是常規(guī)做法。
• 商品表：商品表其實(shí)大多數(shù)都是差不多的，不夠個(gè)人做法是商品表保留整個(gè)商品介紹的html頁面。這個(gè)也是以前開發(fā)用過的套路。因?yàn)橛械氖窃试S自定義展示模塊的。反正我只能說這些都不是硬性要求而是個(gè)人習(xí)慣。實(shí)現(xiàn)的途徑從來不是一個(gè)。
• 銀行卡表： 這個(gè)肯定不是在用戶信息里面，畢竟這種涉及到了私人信息。現(xiàn)在又分支付寶微信啥的。有的是調(diào)起本手機(jī)的微信/支付寶。有的是指定的支付寶（比如淘寶支付只會(huì)調(diào)起綁定的支付寶。）具體怎么做都和需求緊密相關(guān)。

這里我就簡(jiǎn)單的說一些常用的功能的設(shè)計(jì)，而且說得也很不清楚，畢竟這個(gè)不是重點(diǎn)，重點(diǎn)是要認(rèn)識(shí)到：最合適的數(shù)據(jù)結(jié)構(gòu)是根據(jù)需求設(shè)計(jì)的，而不能盲目的跟風(fēng)。我早就說過這個(gè)態(tài)度：不要大佬說點(diǎn)什么就當(dāng)成圣旨，因?yàn)槿思艺f的是常用的模式，但是誰知道你們開發(fā)有什么奇葩需求了？
反正我對(duì)這塊的態(tài)度是不要急，一點(diǎn)點(diǎn)構(gòu)思，一遍遍看。慢工出細(xì)活，我不能說百分之百，但是百分之八十隨著項(xiàng)目做著做著要不斷修改表中字段，添加關(guān)系甚至添加表都是因?yàn)樽铋_始的數(shù)據(jù)庫設(shè)計(jì)有問題。所以后期不斷返工，不斷改動(dòng)。
當(dāng)然了從設(shè)計(jì)完到做完項(xiàng)目一次數(shù)據(jù)庫不改也不太現(xiàn)實(shí)。但是改動(dòng)頻繁肯定也是有問題的。
打個(gè)比方，前幾天做的那個(gè)app，領(lǐng)導(dǎo)當(dāng)時(shí)說半個(gè)月做完，然后看了需求文檔覺得蠻簡(jiǎn)單的，我就偷懶了簡(jiǎn)單用半天勾勒一個(gè)數(shù)據(jù)庫關(guān)系圖就上手，雖說主體還是對(duì)的，但是幾乎每個(gè)表都加過字段，甚至有的今天加一個(gè)，明天加一個(gè)，后天加一個(gè)的加。也虧得是邏輯簡(jiǎn)單，加個(gè)字段的成本比較小，不過復(fù)雜的業(yè)務(wù)這么改動(dòng)誰也受不了。
所以數(shù)據(jù)庫的設(shè)計(jì)關(guān)系到以后開發(fā)的速度和代碼的可讀性和邏輯性。我記得聽過一句話：究竟數(shù)據(jù)庫該怎樣設(shè)計(jì),古往今來,每一個(gè)人都有每一個(gè)人的想法,所以數(shù)據(jù)庫設(shè)計(jì)并沒有優(yōu)劣之分,好壞之別,合適的數(shù)據(jù)庫設(shè)計(jì)就是最好的。
我覺得這這句話說的真的很好，數(shù)據(jù)庫三大范式我知道，但是好多時(shí)候問數(shù)據(jù)庫設(shè)計(jì)或者說問多表聯(lián)查，我都會(huì)說非特殊情況除外，需要跨太多表聯(lián)查只能說明是數(shù)據(jù)庫設(shè)計(jì)有問題。有時(shí)候數(shù)據(jù)庫適當(dāng)?shù)娜哂嗾娴暮苡斜匾Ｕf了這么多其實(shí)好多時(shí)候字段的定義，關(guān)聯(lián)關(guān)系等主要還是時(shí)間的累計(jì)。有時(shí)候一個(gè)不怎么好的設(shè)計(jì)會(huì)讓你知道下次怎么做能更好。
另外多學(xué)，多用，多看，多想總是有用的。

接口的定義

這個(gè)其實(shí)是分歧最大的一個(gè)，在我看來也是最難的一個(gè)。接觸過很多前端，從最開始工作四五年的小姐姐（第一家公司的元老人物，我目前為止認(rèn)為技術(shù)最好的 一個(gè)人），到后來的小菜鳥實(shí)習(xí)生。到中間私活的甲方提供的前端。還有現(xiàn)在的前端同事。
怎么說呢，我經(jīng)歷過很多次接口定義好了，代碼差不多寫完了，結(jié)果前端小哥哥小姐姐或者苦著臉或者小心翼翼也有理直氣壯的和我說數(shù)據(jù)格式處理不了等。然后改接口數(shù)據(jù)格式甚至有的改邏輯等。只能說互相理解。但是有時(shí)候發(fā)生的很頻繁也是真的心煩。
經(jīng)常別人的看法也是，不管是前端還是后端。不非要全棧，但是多少也要懂一些對(duì)方的技術(shù)。不然真的很容易被唬（真人真事，我一個(gè)以前的做后端的同事，前端對(duì)接口數(shù)據(jù)有意見的時(shí)候大多數(shù)都是一句你這樣要求java實(shí)現(xiàn)不了。。。。神踏馬實(shí)現(xiàn)不了啊，然后那個(gè)前端經(jīng)常被唬我覺得）。
不過隨著開發(fā)我也確實(shí)發(fā)現(xiàn)接口的定義其實(shí)真的挺不好設(shè)計(jì)的。就前幾天的個(gè)接口。本來是個(gè)添加配置接口，但是最開始的需求文檔只有兩個(gè)字段。我出于嫌麻煩，所以直接決定這兩個(gè)字段分別以參數(shù)的形式傳過來。正常來講這么設(shè)計(jì)沒啥大問題吧？然后隨著開發(fā)，需求今天說應(yīng)該可以傳個(gè)logo，明天說應(yīng)該加個(gè)標(biāo)記，過不長(zhǎng)時(shí)間又說這里有個(gè)類別比較適合篩選。。因?yàn)槭亲约汗卷?xiàng)目，所以都是想到哪做到哪。不說我數(shù)據(jù)庫一個(gè)字段一個(gè)字段的加。實(shí)體一遍一遍的改。單說這個(gè)接口我都改了一次又一次。這也就夠糟心的了。最后的最后參數(shù)變成一大串以后，前端小哥說我這樣也太麻煩了，咋不用對(duì)象包裝。。ex？我特么要是早知道這樣哪怕腦袋進(jìn)了水也不會(huì)這樣設(shè)計(jì)?。。?！
還有常常出問題的就是統(tǒng)計(jì)報(bào)表這一塊了。畢竟功能不同，各種各樣的統(tǒng)計(jì) ，柱狀餅狀曲線，二維三維甚至有的點(diǎn)進(jìn)去還可以放大成4維。。反正現(xiàn)在我?guī)缀踅y(tǒng)計(jì)接口的數(shù)據(jù)定義都是直接交給前端，美名曰你覺得你怎么拿方便怎么定義。我按照你的要求給你。其實(shí)是真的無數(shù)次定義封裝好了前端苦兮兮的說這樣的數(shù)據(jù)形式展示不了給嚇怕了。
還有比較想吐槽的一件事就是分布式的接口調(diào)用情況。這個(gè)是在我去年用cloud的時(shí)候發(fā)生的事。有時(shí)候一個(gè)按鈕的調(diào)用會(huì)觸發(fā)很多事件。最簡(jiǎn)單的例子：一個(gè)訂單的簽收會(huì)觸發(fā)分傭，觸發(fā)訂單狀態(tài)的改變，觸發(fā)商品銷量的改變，觸發(fā)賬戶的變動(dòng)，有的還會(huì)觸發(fā)用戶積分的變化。用戶和商戶的等級(jí)變動(dòng)等等（包括但不限于）。而這個(gè)絕對(duì)不是一個(gè)模塊可以完成的。賬戶模塊，用戶模塊，商品模塊，訂單模塊差不多是跑了個(gè)遍。feign確實(shí)可以解決。但是有些壓根不用交互的模塊就為了這么一個(gè)接口還要來個(gè)調(diào)用我自己的懶得寫。也可能是懶癌晚期。反正我最終的實(shí)現(xiàn)是這么一個(gè)按鈕讓前端調(diào)用了兩個(gè)不是三個(gè)接口。當(dāng)然我不是說我的做法值得倡導(dǎo)。我自己都覺得其實(shí)是有點(diǎn)問題的。但是?。?！但是方便啊。反正說這么多就是想說每一個(gè)接口的功能，作用都是由我們定義的。一個(gè)項(xiàng)目的交互也幾乎是后端主導(dǎo)的。很多時(shí)候良好的接口設(shè)計(jì)確實(shí)會(huì)讓工作更加融洽和方便，反正我的建議就是接口的設(shè)計(jì)要慎重，而且最好是根據(jù)需求和原型圖，流程圖來做。雖然隨著開發(fā)接口的添加和修改不可避免。但是最大程度上減少出現(xiàn)還是很有必要的。
剩下參數(shù)什么的我也沒啥心得，就是按需求設(shè)計(jì)，能不傳不傳，密碼等加密傳。

技術(shù)選型+基本架構(gòu)

數(shù)據(jù)庫好了，流程圖原型圖有數(shù)了，接口也定義的差不多了，最后還是要落實(shí)到代碼上。至于技術(shù)選型啥的可能因?yàn)轫?xiàng)目都是非互聯(lián)網(wǎng)項(xiàng)目，要求也不高，功能也簡(jiǎn)單，領(lǐng)導(dǎo)有時(shí)候還會(huì)有要求（比如手頭的這個(gè)dubbox就是領(lǐng)導(dǎo)指明的）。所以一般不會(huì)有太大的選擇。

• 從我入行以來，spring boot就是基石。最開始還用過spring，但是從開始使用spring boot以后就沒退回去過。所以項(xiàng)目基石是spring boot雷打不動(dòng)。
• orm框架現(xiàn)在主流也就是jpa和mybatis。優(yōu)缺點(diǎn)都有。甚至二者的底層實(shí)現(xiàn)也差別很大。但是有一個(gè)不得不說的點(diǎn)：在基本的使用上來說對(duì)調(diào)用者而言二者沒有多大差別。jpa有spring的封裝，mybatis有mybatis plus的封裝?，F(xiàn)在基本都是自動(dòng)生成實(shí)體和dao層。然后基本的crud都由框架封裝好了
  mybatis plus的條件構(gòu)造器。
  反正我覺得對(duì)于我使用來說是差不多的。導(dǎo)包。生成entity和dao。然后就是調(diào)用。兩者我都用過，最近用mp比較多。性能方面簡(jiǎn)單的操作根本看不出差別。
  至于雙方最主要的兩個(gè)差別：復(fù)雜查詢和改動(dòng)的靈活性來說，代碼中真的沒啥區(qū)別了。所以我一般都是隨緣選擇。mybatis的幾率高一些。因?yàn)槲沂诸^有一套mybatis plus 的項(xiàng)目架子。。
• 微服務(wù)框架
  額，其實(shí)我之前在哪里聽到過一句話：市場(chǎng)上百分之九十的微服務(wù)項(xiàng)目都是閑的。雖然這么說比較偏激片面。但是有時(shí)候確實(shí)是這樣。我經(jīng)常拿上一家公司舉例子，一個(gè)還沒做起來的項(xiàng)目老板整天考慮的都是分庫分表集群微服務(wù)分布式。。講真是有點(diǎn)杞人憂天了吧。
  正常來講現(xiàn)在的服務(wù)器稍微好點(diǎn)的維持一個(gè)項(xiàng)目是夠用了吧。好一點(diǎn)的單體服務(wù)器可以做到10w并發(fā)。說實(shí)話現(xiàn)在市場(chǎng)上有多少軟件能達(dá)到這個(gè)量的？所以微服務(wù)分布式什么的，反正用了就用了，老板愿意花大成本投入我們做的就當(dāng)學(xué)習(xí)了吧。
  現(xiàn)在主流的也是我用過的微服務(wù)框架cloud，dubbo（現(xiàn)在用過的dubbox是dubbo之上的一層封裝，本質(zhì)還是dubbo）。兩者怎么說的，cloud的話我覺得spring對(duì)其的整合很好，無論是注冊(cè)中心還是網(wǎng)關(guān)還有服務(wù)調(diào)用熔斷啥的。學(xué)起來上手比較快，但是遇到問題解決問題的話要么靠百度要么靠運(yùn)氣?！，F(xiàn)在對(duì)當(dāng)時(shí)開發(fā)過程中的一些靈異問題我也是一頭霧水。比如時(shí)有時(shí)無的報(bào)錯(cuò)到現(xiàn)在我也不知道是網(wǎng)的問題還是連接的問題。但是可能是我這種菜鳥才這樣，反正我對(duì)cloud整體的印象就是上手簡(jiǎn)單精通難。而dubbo的自由度高了很多，就是一個(gè)rpc遠(yuǎn)程調(diào)用。剩下的想要什么功能自己添加（有的是有現(xiàn)成的包的）。不過我只用過那個(gè)監(jiān)聽。反正整體感覺二者的簡(jiǎn)單使用都可以是配置文件配置自己名字和注冊(cè)中心。然后不管是服務(wù)調(diào)用還是注冊(cè)都可以用注解的方式實(shí)現(xiàn)。剩下別的功能自己探索吧。因?yàn)槲疫@個(gè)項(xiàng)目就是要用dubbox所以才簡(jiǎn)單的說了幾句。
• 數(shù)據(jù)庫細(xì)節(jié)
  開發(fā)以來只用過mysql和sqlserver。所以沒啥發(fā)言權(quán)。傳說中的土豪專用oracle只聽說過而已。剩下一些別的也沒真正用過。反正我個(gè)人可以選擇就毫無疑問mysql 5.多。但是甲方指定的話別的應(yīng)該也都可以對(duì)付用。畢竟jdbc支持蠻多數(shù)據(jù)庫的。然后基本使用上都是主備兩個(gè)庫。雖然至今也沒遇到過宕機(jī)啥的，不過就是一個(gè)習(xí)慣嘛。這個(gè)不是很重要。
  至于分庫分表啥的我反正也沒接觸過超過十萬的數(shù)據(jù)。所以弄過分庫分表也沒啥實(shí)際的體會(huì)。只能說簡(jiǎn)單的分庫分表，一些常用的分的規(guī)則，什么物理表邏輯表的定義是能明白。但是真說實(shí)用性也不見得有什么。
• 常用工具+第三方工具
  其實(shí)這個(gè)真的是個(gè)人積累了，沒法細(xì)說，比如說定時(shí)器用quartz，代碼引入lombok依賴，還有json工具包啥的。這些都是便于開發(fā)的東西。有了簡(jiǎn)化代碼沒有也能實(shí)現(xiàn)。隨著工作多看看別人的代碼或者項(xiàng)目源碼總能學(xué)到什么的。
  至于第三方工具：阿里的各種服務(wù)（短信，oss，身份證識(shí)別等等），發(fā)送郵箱驗(yàn)證碼的封裝，微信/支付寶授權(quán)支付，極光推送的app推送等等，幾乎在理完流程以后這種需要調(diào)用第三方的都會(huì)心里有數(shù)了。而且這些工具類都是做的賊簡(jiǎn)單，去看看官網(wǎng)幾乎都有現(xiàn)成的代碼。所以也沒必要多說了。

話題轉(zhuǎn)回來,我這個(gè)項(xiàng)目的技術(shù)選型如下:
dubbo+zookeeper + mysql + spring boot + mybatis plus + swagger。
現(xiàn)在還差一個(gè)網(wǎng)關(guān)，zuul是用過的，但是查了好久資料都說zuul性能堪憂，soul倒是叫好一片，所以這個(gè)網(wǎng)關(guān)暫時(shí)待定。大概的籌劃就是這樣。

項(xiàng)目框架

下面是我初步定下的項(xiàng)目大的框架，只用了user和order做例子。簡(jiǎn)單說就是按照模塊分。每個(gè)模塊又分為三個(gè)項(xiàng)目：接口，實(shí)現(xiàn)，和調(diào)用。

image.png

注意這里在api中有個(gè)Dto。這個(gè)也是問了一些人，看了一些資料后才定下這樣做的。
網(wǎng)上也有一種做法是所有的實(shí)體和dao做成公共引用。但是這樣首先肯定是不合理的。畢竟比如api應(yīng)該只是干干凈凈的接口，但是還要引用那些亂七八糟的？其次有個(gè)朋友說這樣也正好違背了解耦，分模塊的概念。但是有時(shí)候參數(shù)是實(shí)體對(duì)象的話，api模塊和web模塊要怎么接收呢？
之前我還靈機(jī)一動(dòng)打算所有參數(shù)都map。。然后群里一提出來就被罵了，哈哈。反正是這樣會(huì)出現(xiàn)魔法值，一點(diǎn)都不合適。
最終決定稍微麻煩點(diǎn)，再封裝一個(gè)對(duì)外的Dto。首先這個(gè)也是符合表中數(shù)據(jù)私有不直接對(duì)外的。其次這樣一層封裝也可以使得數(shù)據(jù)更加有用（好多對(duì)前端沒意義的字段可以直接不傳了）。其實(shí)這種模式早就有，不過以前因?yàn)橄勇闊┧詮膩矶际菍?shí)體直接對(duì)外。這次決定符合規(guī)范一點(diǎn)，entity是entity，dto是dto。

尾

到這為止，所有項(xiàng)目的準(zhǔn)備工作算是做完了。剩下的就是真正的按照接口文檔把接口一個(gè)個(gè)實(shí)現(xiàn)了?？隙▽?shí)現(xiàn)過程中會(huì)有改動(dòng)。不過只要大方向沒問題剩下的改動(dòng)應(yīng)該都不大。因?yàn)榇a的實(shí)現(xiàn)也是一個(gè)長(zhǎng)時(shí)間的過程。如果在項(xiàng)目中遇到什么值得記錄的事情我會(huì)記下來的。本篇文章其實(shí)就是一個(gè)思路的整理和個(gè)人風(fēng)格比較明顯的記錄。
如果本文稍微幫到你了記得點(diǎn)個(gè)喜歡點(diǎn)個(gè)關(guān)注，另外也祝大家工作順順利利！java技術(shù)交流群：130031711歡迎各位萌新大佬踴躍加入。群里好多學(xué)習(xí)資料呦~