我對(duì)新人的25個(gè)建議
前言
最近知乎上，有一位大佬邀請(qǐng)我回答下面這個(gè)問題，看到這個(gè)問題我百感交集，感觸頗多。
在我是新人時(shí)，如果有前輩能夠指導(dǎo)方向一下，分享一些踩坑經(jīng)歷，或許會(huì)讓我少走很多彎路，節(jié)省更多的學(xué)習(xí)的成本。
這篇文章根據(jù)我多年的工作經(jīng)驗(yàn)，給新人總結(jié)了25條建議，希望對(duì)你會(huì)有所幫助。
1.寫好注釋
很多小伙伴不愿意給代碼寫注釋，主要有以下兩個(gè)原因：
開發(fā)時(shí)間太短了，沒時(shí)間寫注釋。
《重構(gòu)》那本書說(shuō)代碼即注釋。
我在開發(fā)的前面幾年也不喜歡寫注釋，覺得這是一件很酷的事情。
但后來(lái)發(fā)現(xiàn)，有些兩年之前的代碼，業(yè)務(wù)邏輯都忘了，有些代碼自己都看不懂。特別是有部分非常復(fù)雜的邏輯和算法，需要重新花很多時(shí)間才能看明白，可以說(shuō)自己把自己坑了。
沒有注釋的代碼，不便于維護(hù)。
因此強(qiáng)烈建議大家給代碼寫注釋。
但注釋也不是越多越好，注釋多了增加了代碼的復(fù)雜度，增加了維護(hù)成本，給自己增加工作量。
我們要寫好注釋，但不能太啰嗦，要給關(guān)鍵或者核心的代碼增加注釋。我們可以寫某個(gè)方法是做什么的，主要步驟是什么，給算法寫個(gè)demo示例等。
這樣以后過了很長(zhǎng)時(shí)間，再去看這段代碼的時(shí)候，也會(huì)比較容易上手。
2.多寫單元測(cè)試
我看過身邊很多大佬寫代碼有個(gè)好習(xí)慣，比如新寫了某個(gè)Util工具類，他們會(huì)同時(shí)在test目錄下，給該工具類編寫一些單元測(cè)試代碼。
很多小伙伴覺得寫單元測(cè)試是浪費(fèi)時(shí)間，沒有這個(gè)必要。
假如你想重構(gòu)某個(gè)工具類，但由于這個(gè)工具類有很多邏輯，要把這些邏輯重新測(cè)試一遍，要花費(fèi)不少時(shí)間。
于是，你產(chǎn)生了放棄重構(gòu)的想法。
但如果你之前給該工具類編寫了完整的單元測(cè)試，重構(gòu)完成之后，重新執(zhí)行一下之前的單元測(cè)試，就知道重構(gòu)的結(jié)果是否滿足預(yù)期，這樣能夠減少很多的測(cè)試時(shí)間。
多寫單元測(cè)試對(duì)開發(fā)來(lái)說(shuō)，是一個(gè)非常好的習(xí)慣，有助于提升代碼質(zhì)量。
即使因?yàn)楫?dāng)初開發(fā)時(shí)間比較緊，沒時(shí)間寫單元測(cè)試，也建議在后面空閑的時(shí)間內(nèi)，把單元測(cè)試補(bǔ)上。
3.主動(dòng)重構(gòu)自己的爛代碼
好的代碼不是一下子就能寫成的，需要不斷地重構(gòu)，修復(fù)發(fā)現(xiàn)的bug。
不知道你有沒有這種體會(huì)，看自己1年之前寫的代碼，簡(jiǎn)直不忍直視。
這說(shuō)明你對(duì)業(yè)務(wù)或者技術(shù)的理解，比之前更深入了，認(rèn)知水平有一定的提升。
如果有機(jī)會(huì)，建議你主動(dòng)重構(gòu)一下自己的爛代碼。把重復(fù)的代碼，抽取成公共方法。有些參數(shù)名稱，或者方法名稱當(dāng)時(shí)沒有取好的，可以及時(shí)修改一下。對(duì)于邏輯不清晰的代碼，重新梳理一下業(yè)務(wù)邏輯。看看代碼中能不能引入一些設(shè)計(jì)模式，讓代碼變得更優(yōu)雅等等。
通過代碼重構(gòu)的過程，以自我為驅(qū)動(dòng)，能夠不斷提升我們編寫代碼的水平。
4.代碼review很重要
有些公司在系統(tǒng)上線之前，會(huì)組織一次代碼評(píng)審，一起review一下這個(gè)迭代要上線的一些代碼。
通過相互的代碼review，可以發(fā)現(xiàn)一些代碼的漏洞，不好的寫法，發(fā)現(xiàn)自己寫代碼的壞毛病，讓自己能夠快速提升。
當(dāng)然如果你們公司沒有建立代碼的相互review機(jī)制，也沒關(guān)系。
可以后面可以多自己review自己的代碼。
5.多用explain查看執(zhí)行計(jì)劃
我們?cè)趯懲瓴樵僑QL語(yǔ)句之后，有個(gè)好習(xí)慣是用explain關(guān)鍵字查看一下該SQL語(yǔ)句有沒有走索引。
對(duì)于數(shù)據(jù)量比較大的表，走了索引和沒有走索引，SQL語(yǔ)句的執(zhí)行時(shí)間可能會(huì)相差上百倍。
我之前親身經(jīng)歷過這種差距。
因此建議大家多用explain查看SQL語(yǔ)句的執(zhí)行計(jì)劃。
關(guān)于explain關(guān)鍵字的用法，如果你想進(jìn)一步了解，可以看看我的另外一篇文章《explain | 索引優(yōu)化的這把絕世好劍，你真的會(huì)用嗎？》，里面有詳細(xì)的介紹。
6.上線前整理checklist
在系統(tǒng)上線之前，一定要整理上線的清單，即我們說(shuō)的：checklist。
系統(tǒng)上線有可能是一件很復(fù)雜的事情，涉及的東西可能會(huì)比較多。
假如服務(wù)A依賴服務(wù)B，服務(wù)B又依賴服務(wù)C。這樣的話，服務(wù)發(fā)版的順序是：CBA，如果順序不對(duì)，可能會(huì)出現(xiàn)問題。
有時(shí)候新功能上線時(shí)，需要提前執(zhí)行sql腳本初始化數(shù)據(jù)，否則新功能有問題。
要先配置定時(shí)任務(wù)。
上線之前，要在apollo中增加一些配置。
上線完成之后，需要增加相應(yīng)的菜單，給指定用戶或者角色分配權(quán)限。
等等。
系統(tǒng)上線，整個(gè)過程中，可能會(huì)涉及多方面的事情，我們需要將這些事情記錄到checklist當(dāng)中，避免踩坑。
7.寫好接口文檔
接口文檔對(duì)接口提供者，和接口調(diào)用者來(lái)說(shuō)，都非常重要。
如果你沒有接口文檔，別人咋知道你接口的地址是什么，接口參數(shù)是什么，請(qǐng)求方式時(shí)什么，接口多個(gè)參數(shù)分別代碼什么含義，返回值有哪些字段等等。
他們不知道，必定會(huì)多次問你，無(wú)形當(dāng)中，增加了很多溝通的成本。
如果你的接口文檔寫的不好，寫得別人看不懂，接口文檔有很多錯(cuò)誤，比如：輸入?yún)?shù)的枚舉值，跟實(shí)際情況不一樣。
這樣不光把自己坑了，也會(huì)把別人坑慘。
因此，寫接口文檔一定要寫好，盡量不要馬馬虎虎應(yīng)付差事。
如果對(duì)寫接口文檔比較感興趣，可以看看我的另一篇文章《瞧瞧別人家的API接口，那叫一個(gè)優(yōu)雅》，里面有詳細(xì)的介紹。
8.接口要提前評(píng)估請(qǐng)求量
我們?cè)谠O(shè)計(jì)接口的時(shí)候，要跟業(yè)務(wù)方或者產(chǎn)品經(jīng)理確認(rèn)一下請(qǐng)求量。
假如你的接口只能承受100qps，但實(shí)際上產(chǎn)生了1000qps。
這樣你的接口，很有可能會(huì)承受不住這么大的壓力，而直接掛掉。
我們需要對(duì)接口做壓力測(cè)試，預(yù)估接口的請(qǐng)求量，需要部署多少個(gè)服務(wù)器節(jié)點(diǎn)。
壓力測(cè)試的話，可以用jmeter、loadRunner等工具。
此外，還需要對(duì)接口做限流，防止別人惡意調(diào)用你的接口，導(dǎo)致服務(wù)器壓力過大。
限流的話，可以基于用戶id、ip地址、接口地址等多個(gè)維度同時(shí)做限制。
可以在nginx層，或者網(wǎng)關(guān)層做限流。
9.接口要做冪等性設(shè)計(jì)
我們?cè)谠O(shè)計(jì)接口時(shí)，一定要考慮并發(fā)調(diào)用的情況。
比如：用戶在前端頁(yè)面，非常快的點(diǎn)擊了兩次保存按鈕，這樣就會(huì)在極短的時(shí)間內(nèi)調(diào)用你兩次接口。
如果不做冪等性設(shè)計(jì)，在數(shù)據(jù)庫(kù)中可能會(huì)產(chǎn)生兩條重復(fù)的數(shù)據(jù)。
還有一種情況時(shí)，業(yè)務(wù)方調(diào)用你這邊的接口，該接口發(fā)生了超時(shí)，它有自動(dòng)重試機(jī)制，也可能會(huì)讓你這邊產(chǎn)生重復(fù)的數(shù)據(jù)。
因此，在做接口設(shè)計(jì)時(shí)，要做冪等設(shè)計(jì)。
當(dāng)然冪等設(shè)計(jì)的方案有很多，感興趣的小伙伴可以看看我的另一篇文章《高并發(fā)下如何保證接口的冪等性？》。
如果接口并發(fā)量不太大，推薦大家使用在表中加唯一索引的方案，更加簡(jiǎn)單。
10.接口參數(shù)有調(diào)整一定要慎重
有時(shí)候我們提供的接口，需要調(diào)整參數(shù)。
比如：新增加了一個(gè)參數(shù)，或者參數(shù)類型從int改成String，或者參數(shù)名稱有status改成auditStatus，參數(shù)由單個(gè)id改成批量的idList等等。
建議涉及到接口參數(shù)修改一定要慎重。
修改接口參數(shù)之前，一定要先評(píng)估調(diào)用端和影響范圍，不要自己偷偷修改。如果出問題了，調(diào)用方后面肯定要罵娘。
我們?cè)谧鼋涌趨?shù)調(diào)整時(shí)，要做一些兼容性的考慮。
其實(shí)刪除參數(shù)和修改參數(shù)名稱是一個(gè)問題，都會(huì)導(dǎo)致那個(gè)參數(shù)接收不到數(shù)據(jù)。
因此，盡量避免刪除參數(shù)和修改參數(shù)名。
對(duì)于修改參數(shù)名稱的情況，我們可以增加一個(gè)新參數(shù)，來(lái)接收數(shù)據(jù)，老的數(shù)據(jù)還是保留，代碼中做兼容處理。
11.調(diào)用第三方接口要加失敗重試
我們?cè)谡{(diào)用第三方接口時(shí)，由于存在遠(yuǎn)程調(diào)用，可能會(huì)出現(xiàn)接口超時(shí)的問題。
如果接口超時(shí)了，你不知道是執(zhí)行成功，還是執(zhí)行失敗了。
這時(shí)你可以增加自動(dòng)重試機(jī)制。
接口超時(shí)會(huì)拋一個(gè)connection_timeout或者read_timeout的異常，你可以捕獲這個(gè)異常，用一個(gè)while循環(huán)自動(dòng)重試3次。
這樣就能盡可能減少調(diào)用第三方接口失敗的情況。
當(dāng)然調(diào)用第三方接口還有很多其他的坑，感興趣的小伙伴可以看看我的另一篇文章《我調(diào)用第三方接口遇到的13大坑》，里面有詳細(xì)的介紹。
12.處理線上數(shù)據(jù)前，要先備份數(shù)據(jù)
有時(shí)候，線上數(shù)據(jù)出現(xiàn)了問題，我們需要修復(fù)數(shù)據(jù)，但涉及的數(shù)據(jù)有點(diǎn)多。
這時(shí)建議在處理線上數(shù)據(jù)前，一定要先備份數(shù)據(jù)。
備份數(shù)據(jù)非常簡(jiǎn)單，可以執(zhí)行以下sql：
create?table?order_2022121819?like?`order`;
insert?into?order_2022121819?select?*?from?`order`;
數(shù)據(jù)備份之后，萬(wàn)一后面哪天數(shù)據(jù)處理錯(cuò)了，我們可以直接從備份表中還原數(shù)據(jù)，防止悲劇的產(chǎn)生。
13.不要輕易刪除線上字段
不要輕易刪除線上字段，至少我們公司是這樣規(guī)定的。
如果你刪除了某個(gè)線上字段，但是該字段引用的代碼沒有刪除干凈，可能會(huì)導(dǎo)致代碼出現(xiàn)異常。
假設(shè)開發(fā)人員已經(jīng)把程序改成不使用刪除字段了，接下來(lái)如何部署呢？
如果先把程序部署好了，還沒來(lái)得及刪除數(shù)據(jù)庫(kù)相關(guān)表字段。
當(dāng)有insert請(qǐng)求時(shí)，由于數(shù)據(jù)庫(kù)中該字段是必填的，會(huì)報(bào)必填字段不能為空的異常。
如果先把數(shù)據(jù)庫(kù)中相關(guān)表字段刪了，程序還沒來(lái)得及發(fā)。這時(shí)所有涉及該刪除字段的增刪改查，都會(huì)報(bào)字段不存在的異常。
所以，線上環(huán)境字段不要輕易刪除。
14.要合理設(shè)置字段類型和長(zhǎng)度
我們?cè)谠O(shè)計(jì)表的時(shí)候，要給相關(guān)字段設(shè)置合理的字段類型和長(zhǎng)度。
如果字段類型和長(zhǎng)度不夠，有些數(shù)據(jù)可能會(huì)保存失敗。
如果字段類型和長(zhǎng)度太大了，又會(huì)浪費(fèi)存儲(chǔ)空間。
我們?cè)诠ぷ髦?，要根?jù)實(shí)際情況而定。
以下原則可以參考一下：
盡可能選擇占用存儲(chǔ)空間小的字段類型，在滿足正常業(yè)務(wù)需求的情況下，從小到大，往上選。
如果字符串長(zhǎng)度固定，或者差別不大，可以選擇char類型。如果字符串長(zhǎng)度差別較大，可以選擇varchar類型。
是否字段，可以選擇bit類型。
枚舉字段，可以選擇tinyint類型。
主鍵字段，可以選擇bigint類型。
金額字段，可以選擇decimal類型。
時(shí)間字段，可以選擇timestamp或datetime類型。
15.避免一次性查詢太多數(shù)據(jù)
我們?cè)谠O(shè)計(jì)接口，或者調(diào)用別人接口的時(shí)候，都要避免一次性查詢太多數(shù)據(jù)。
一次性查詢太多的數(shù)據(jù)，可能會(huì)導(dǎo)致查詢耗時(shí)很長(zhǎng)，更加嚴(yán)重的情況會(huì)導(dǎo)致系統(tǒng)出現(xiàn)OOM的問題。
我們之前調(diào)用第三方，查詢一天的指標(biāo)數(shù)據(jù)，該接口經(jīng)常出現(xiàn)超時(shí)問題。
在做excel導(dǎo)出時(shí)，如果一次性查詢出所有的數(shù)據(jù)，導(dǎo)出到excel文件中，可能會(huì)導(dǎo)致系統(tǒng)出現(xiàn)OOM問題。
因此我們的接口要做分頁(yè)設(shè)計(jì)。
如果是調(diào)用第三方的接口批量查詢接口，盡量分批調(diào)用，不要一次性根據(jù)id集合查詢所有數(shù)據(jù)。
如果調(diào)用第三方批量查詢接口，對(duì)性能有一定的要求，我們可以分批之后，用多線程調(diào)用接口，最后匯總返回?cái)?shù)據(jù)。
16.多線程不一定比單線程快
很多小伙伴有一個(gè)誤解，認(rèn)為使用了多線程一定比使用單線程快。
其實(shí)要看使用場(chǎng)景。
如果你的業(yè)務(wù)邏輯是一個(gè)耗時(shí)的操作，比如：遠(yuǎn)程調(diào)用接口，或者磁盤IO操作，這種使用多線程比單線程要快一些。
但如果你的業(yè)務(wù)邏輯非常簡(jiǎn)單，在一個(gè)循環(huán)中打印數(shù)據(jù)，這時(shí)候，使用單線程可能會(huì)更快一些。
因?yàn)槭褂枚嗑€程，會(huì)引入額外的消耗，比如：創(chuàng)建新線程的耗時(shí)，搶占CPU資源時(shí)線程上下文需要不斷切換，這個(gè)切換過程是有一定的時(shí)間損耗的。
因此，多線程不一定比單線程快。我們要根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景，決定是使用單線程，還是使用多線程。
17.注意事務(wù)問題
很多時(shí)候，我們的代碼為了保證數(shù)據(jù)庫(kù)多張表保存數(shù)據(jù)的完整性和一致性，需要使用@Transactional注解的聲明式事務(wù)，或者使用TransactionTemplate的編程式事務(wù)。
加入事務(wù)之后，如果A,B,C三張表同時(shí)保存數(shù)據(jù)，要么一起成功，要么一起失敗。
不會(huì)出現(xiàn)數(shù)據(jù)保存一半的情況，比如：表A保存成功了，但表B和C保存失敗了。
這種情況數(shù)據(jù)會(huì)直接回滾，A,B,C三張表的數(shù)據(jù)都會(huì)同時(shí)保存失敗。
如果使用@Transactional注解的聲明式事務(wù)，可能會(huì)出現(xiàn)事務(wù)失效的問題，感興趣的小伙伴可以看看我的另一篇文章《聊聊spring事務(wù)失效的12種場(chǎng)景，太坑了》。
建議優(yōu)先使用TransactionTemplate的編程式事務(wù)的方式創(chuàng)建事務(wù)。
此外，引入事務(wù)還會(huì)帶來(lái)大事務(wù)問題，可能會(huì)導(dǎo)致接口超時(shí)，或者出現(xiàn)數(shù)據(jù)庫(kù)死鎖的問題。
因此，我們需要優(yōu)化代碼，盡量避免大事務(wù)的問題，因?yàn)樗性S多危害。關(guān)于大事務(wù)問題，感興趣的小伙伴，可以看看我的另一篇文章《讓人頭痛的大事務(wù)問題到底要如何解決？》，里面有詳情介紹。
18.小數(shù)容易丟失精度
不知道你在使用小數(shù)時(shí)，有沒有踩過坑，一些運(yùn)算導(dǎo)致小數(shù)丟失了精度。
如果你在項(xiàng)目中使用了float或者double類型的數(shù)據(jù)，用他們參與計(jì)算，極可能會(huì)出現(xiàn)精度丟失問題。
使用Double時(shí)可能會(huì)有這種場(chǎng)景：
double?amount1?=?0.02;
double?amount2?=?0.03;
System.out.println(amount2?-?amount1);
正常情況下預(yù)計(jì)amount2 - amount1應(yīng)該等于0.01
但是執(zhí)行結(jié)果，卻為：
0.009999999999999998
實(shí)際結(jié)果小于預(yù)計(jì)結(jié)果。
Double類型的兩個(gè)參數(shù)相減會(huì)轉(zhuǎn)換成二進(jìn)制，因?yàn)镈ouble有效位數(shù)為16位這就會(huì)出現(xiàn)存儲(chǔ)小數(shù)位數(shù)不夠的情況，這種情況下就會(huì)出現(xiàn)誤差。
因此，在做小數(shù)運(yùn)算時(shí)，更推薦大家使用BigDecimal，避免精度的丟失。
但如果在使用BigDecimal時(shí)，使用不當(dāng)，也會(huì)丟失精度。
BigDecimal?amount1?=?new?BigDecimal(0.02);
BigDecimal?amount2?=?new?BigDecimal(0.03);
System.out.println(amount2.subtract(amount1));
這個(gè)例子中定義了兩個(gè)BigDecimal類型參數(shù)，使用構(gòu)造函數(shù)初始化數(shù)據(jù)，然后打印兩個(gè)參數(shù)相減后的值。
結(jié)果：
0.0099999999999999984734433411404097569175064563751220703125
使用BigDecimal的構(gòu)造函數(shù)創(chuàng)建BigDecimal，也會(huì)導(dǎo)致精度丟失。
如果如何避免精度丟失呢？
BigDecimal?amount1?=?BigDecimal.valueOf(0.02);
BigDecimal?amount2?=?BigDecimal.valueOf(0.03);
System.out.println(amount2.subtract(amount1));
使用BigDecimal.valueOf方法初始化BigDecimal類型參數(shù)，能保證精度不丟失。
19.優(yōu)先使用批量操作
有些小伙伴可能寫過這樣的代碼，在一個(gè)for循環(huán)中，一個(gè)個(gè)調(diào)用遠(yuǎn)程接口，或者執(zhí)行數(shù)據(jù)庫(kù)的update操作。
其實(shí)，這樣是比較消耗性能的。
我們盡可能將在一個(gè)循環(huán)中多次的單個(gè)操作，改成一次的批量操作，這樣會(huì)將代碼的性能提升不少。
例如：
for(User?user?:?userList)?{
???userMapper.update(user);
}
改成：
userMapper.updateForBatch(userList);
20.synchronized其實(shí)用的不多
我們?cè)诿嬖囍挟?dāng)中，經(jīng)常會(huì)被面試官問到synchronized加鎖的考題。
說(shuō)實(shí)話，synchronized的鎖升級(jí)過程，還是有點(diǎn)復(fù)雜的。
但在實(shí)際工作中，使用synchronized加鎖的機(jī)會(huì)不多。
synchronized更適合于單機(jī)環(huán)境，可以保證一個(gè)服務(wù)器節(jié)點(diǎn)上，多個(gè)線程訪問公共資源時(shí)，只有一個(gè)線程能夠拿到那把鎖，其他的線程都需要等待。
但實(shí)際上我們的系統(tǒng)，大部分是處于分布式環(huán)境當(dāng)中的。
為了保證服務(wù)的穩(wěn)定性，我們一般會(huì)把系統(tǒng)部署到兩個(gè)以上的服務(wù)器節(jié)點(diǎn)上。
后面哪一天有個(gè)服務(wù)器節(jié)點(diǎn)掛了，系統(tǒng)也能在另外一個(gè)服務(wù)器節(jié)點(diǎn)上正常運(yùn)行。
當(dāng)然也能會(huì)出現(xiàn)，一個(gè)服務(wù)器節(jié)點(diǎn)扛不住用戶請(qǐng)求壓力，也掛掉的情況。
這種情況，應(yīng)該提前部署3個(gè)服務(wù)節(jié)點(diǎn)。
此外，即使只有一個(gè)服務(wù)器節(jié)點(diǎn)，但如果你有api和job兩個(gè)服務(wù)，都會(huì)修改某張表的數(shù)據(jù)。
這時(shí)使用synchronized加鎖也會(huì)有問題。
因此，在工作中更多的是使用分布式鎖。
目前比較主流的分布式鎖有：
數(shù)據(jù)庫(kù)悲觀鎖。
基于時(shí)間戳或者版本號(hào)的樂觀鎖。
使用redis的分布式鎖。
使用zookeeper的分布式鎖。
其實(shí)這些方案都有一些使用場(chǎng)景。
目前使用更多的是redis分布式鎖。
當(dāng)然使用redis分布式鎖也很容易踩坑，感興趣的小伙伴可以看看我的另一篇文章《聊聊redis分布式鎖的8大坑》，里面有詳細(xì)介紹。
21.異步思想很重要
不知道你有沒有做過接口的性能優(yōu)化，其中有一個(gè)非常重要的優(yōu)化手段是：異步。
如果我們的某個(gè)保存數(shù)據(jù)的API接口中的業(yè)務(wù)邏輯非常復(fù)雜，經(jīng)常出現(xiàn)超時(shí)問題。
現(xiàn)在讓你優(yōu)化該怎么優(yōu)化呢？
先從索引，sql語(yǔ)句優(yōu)化。
這些優(yōu)化之后，效果不太明顯。
這時(shí)該怎么辦呢？
這就可以使用異步思想來(lái)優(yōu)化了。
如果該接口的實(shí)時(shí)性要求不高，我們可以用一張表保存用戶數(shù)據(jù)，然后使用job或者mq，這種異步的方式，讀取該表的數(shù)據(jù)，做業(yè)務(wù)邏輯處理。
如果該接口對(duì)實(shí)效性要求有點(diǎn)高，我們可以梳理一下接口的業(yè)務(wù)邏輯，看看哪些是核心邏輯，哪些是非核心邏輯。
對(duì)于核心邏輯，可以在接口中同步執(zhí)行。
對(duì)于非核心邏輯，可以使用job或者mq這種異步的方式處理。
22.Git提交代碼要有好習(xí)慣
有些小伙伴，不太習(xí)慣在Git上提交代碼。
非常勤勞的使用idea，寫了一天的代碼，最后下班前，準(zhǔn)備提交代碼的時(shí)候，電腦突然死機(jī)了。
會(huì)讓你欲哭無(wú)淚。
用Git提交代碼有個(gè)好習(xí)慣是：多次提交。
避免一次性提交太多代碼的情況。
這樣可以減少代碼丟失的風(fēng)險(xiǎn)。
更重要的是，如果多個(gè)人協(xié)同開發(fā)，別人能夠盡早獲取你最新的代碼，可以盡可能減少代碼的沖突。
假如你開發(fā)一天的代碼準(zhǔn)備去提交的時(shí)候，發(fā)現(xiàn)你的部分代碼，別人也改過了，產(chǎn)生了大量的沖突。
解決沖突這個(gè)過程是很痛苦的。
如果你能夠多次提交代碼，可能會(huì)及時(shí)獲取別人最新的代碼，減少代碼沖突的發(fā)生。因?yàn)槊看蝡ush代碼之前，Git會(huì)先檢查一下，代碼有沒有更新，如果有更新，需要你先pull一下最新的代碼。
此外，使用Git提交代碼的時(shí)候，一定要寫好注釋，提交的代碼實(shí)現(xiàn)了什么功能，或者修復(fù)了什么bug。
如果有條件的話，每次提交時(shí)在注釋中可以帶上jira任務(wù)的id，這樣后面方便統(tǒng)計(jì)工作量。
23.善用開源的工具類
我們一定要多熟悉一下開源的工具類，真的可以幫我們提升開發(fā)效率，避免在工作中重復(fù)造輪子。
目前業(yè)界使用比較多的工具包有：apache的common，google的guava和國(guó)內(nèi)幾個(gè)大佬些hutool。
比如將一個(gè)大集合的數(shù)據(jù)，按每500條數(shù)據(jù)，分成多個(gè)小集合。
這個(gè)需求如果要你自己實(shí)現(xiàn)，需要巴拉巴拉寫一堆代碼。
但如果使用google的guava包，可以非常輕松的使用：
List<Integer>?list?=?Lists.newArrayList(1,?2,?3,?4,?5);
List<List<Integer>>?partitionList?=?Lists.partition(list,?2);
System.out.println(partitionList);
如果你對(duì)更多的第三方工具類比較感興趣，可以看看我的另一篇文章《吐血推薦17個(gè)提升開發(fā)效率的“輪子”》。
24.培養(yǎng)寫技術(shù)博客的好習(xí)慣
我們?cè)趯W(xué)習(xí)新知識(shí)點(diǎn)的時(shí)候，學(xué)完了之后，非常容易忘記。
往往學(xué)到后面，把前面的忘記了。
回頭溫習(xí)前面的，又把后面的忘記了。
因此，建議大家培養(yǎng)做筆記的習(xí)慣。
我們可以通過寫技術(shù)博客的方式，來(lái)記筆記，不僅可以給學(xué)到的知識(shí)點(diǎn)加深印象，還能鍛煉自己的表達(dá)能力。
此外，工作中遇到的一些問題，以及解決方案，都可以沉淀到技術(shù)博客中。
一方面是為了避免下次犯相同的錯(cuò)誤。
另一方面也可以幫助別人少走彎路。
而且，在面試中如果你的簡(jiǎn)歷中寫了技術(shù)博客地址，是有一定的加分的。
因此建議大家培養(yǎng)些技術(shù)博客的習(xí)慣。
25.多閱讀優(yōu)秀源碼
建議大家利用空閑時(shí)間，多閱讀JDK、Spring、Mybatis的源碼。
通過閱讀源碼，可以真正的了解某個(gè)技術(shù)的底層原理是什么，這些開源項(xiàng)目有哪些好的設(shè)計(jì)思想，有哪些巧妙的編碼技巧，使用了哪些優(yōu)秀的設(shè)計(jì)模式，可能會(huì)出現(xiàn)什么問題等等。
當(dāng)然閱讀源碼是一個(gè)很枯燥的過程。
有時(shí)候我們會(huì)發(fā)現(xiàn)，有些源碼代碼量很多，繼承關(guān)系很復(fù)雜，使用了很多設(shè)計(jì)模式，一眼根本看不明白。
對(duì)于這類不太容易讀懂的源碼，我們不要一口吃一個(gè)胖子。
要先找一個(gè)切入點(diǎn)，不斷深入，由點(diǎn)及面的閱讀。
我們可以通過debug的方式閱讀源碼。
在閱讀的過程中，可以通過idea工具，自動(dòng)生成類的繼承關(guān)系，輔助我們更好的理解代碼邏輯。
我們可以一邊讀源碼，一邊畫流程圖，可以更好的加深印象。
當(dāng)然還有很多建議，由于篇幅有限，后面有機(jī)會(huì)再跟大家分享。
當(dāng)然還有很多建議，由于篇幅有限，后面有機(jī)會(huì)再跟大家分享。
最后歡迎大家加入蘇三的知識(shí)星球【Java突擊隊(duì)】，一起學(xué)習(xí)。
星球中有很多獨(dú)家的干貨內(nèi)容，比如：Java后端學(xué)習(xí)路線，分享實(shí)戰(zhàn)項(xiàng)目，源碼分析，百萬(wàn)級(jí)系統(tǒng)設(shè)計(jì)，系統(tǒng)上線的一些坑，MQ專題，真實(shí)面試題，每天都會(huì)回答大家提出的問題。
星球目前開通了6個(gè)優(yōu)質(zhì)專欄：技術(shù)選型、系統(tǒng)設(shè)計(jì)、Spring源碼解讀、痛點(diǎn)問題、高頻面試題 和 性能優(yōu)化。
每一個(gè)專欄都是大家非常關(guān)心，和非常有價(jià)值的話題，我相信在專欄中你會(huì)學(xué)到很多東西，值回票價(jià)。
目前僅需99元，后面應(yīng)該會(huì)漲到199元。
加入星球如果不滿意，3天內(nèi)包退。
