前言

最近知乎上，有一位大佬邀請我回答下面這個問題，看到這個問題我百感交集，感觸頗多。

圖片

在我是新人時，如果有前輩能夠指導方向一下，分享一些踩坑經(jīng)歷，或許會讓我少走很多彎路，節(jié)省更多的學習的成本。

這篇文章根據(jù)我多年的工作經(jīng)驗，給新人總結了25條建議，希望對你會有所幫助。

1.寫好注釋

很多小伙伴不愿意給代碼寫注釋，主要有以下兩個原因：

• 開發(fā)時間太短了，沒時間寫注釋。
• 《重構》那本書說代碼即注釋。

我在開發(fā)的前面幾年也不喜歡寫注釋，覺得這是一件很酷的事情。

但后來發(fā)現(xiàn)，有些兩年之前的代碼，業(yè)務邏輯都忘了，有些代碼自己都看不懂。特別是有部分非常復雜的邏輯和算法，需要重新花很多時間才能看明白，可以說自己把自己坑了。

沒有注釋的代碼，不便于維護。

因此強烈建議大家給代碼寫注釋。

但注釋也不是越多越好，注釋多了增加了代碼的復雜度，增加了維護成本，給自己增加工作量。

我們要寫好注釋，但不能太啰嗦，要給關鍵或者核心的代碼增加注釋。我們可以寫某個方法是做什么的，主要步驟是什么，給算法寫個demo示例等。

這樣以后過了很長時間，再去看這段代碼的時候，也會比較容易上手。

2.多寫單元測試

我看過身邊很多大佬寫代碼有個好習慣，比如新寫了某個Util工具類，他們會同時在test目錄下，給該工具類編寫一些單元測試代碼。

很多小伙伴覺得寫單元測試是浪費時間，沒有這個必要。

假如你想重構某個工具類，但由于這個工具類有很多邏輯，要把這些邏輯重新測試一遍，要花費不少時間。

于是，你產(chǎn)生了放棄重構的想法。

但如果你之前給該工具類編寫了完整的單元測試，重構完成之后，重新執(zhí)行一下之前的單元測試，就知道重構的結果是否滿足預期，這樣能夠減少很多的測試時間。

多寫單元測試對開發(fā)來說，是一個非常好的習慣，有助于提升代碼質(zhì)量。

即使因為當初開發(fā)時間比較緊，沒時間寫單元測試，也建議在后面空閑的時間內(nèi)，把單元測試補上。

3.主動重構自己的爛代碼

好的代碼不是一下子就能寫成的，需要不斷地重構，修復發(fā)現(xiàn)的bug。

不知道你有沒有這種體會，看自己1年之前寫的代碼，簡直不忍直視。

這說明你對業(yè)務或者技術的理解，比之前更深入了，認知水平有一定的提升。

如果有機會，建議你主動重構一下自己的爛代碼。把重復的代碼，抽取成公共方法。有些參數(shù)名稱，或者方法名稱當時沒有取好的，可以及時修改一下。對于邏輯不清晰的代碼，重新梳理一下業(yè)務邏輯。看看代碼中能不能引入一些設計模式，讓代碼變得更優(yōu)雅等等。

通過代碼重構的過程，以自我為驅(qū)動，能夠不斷提升我們編寫代碼的水平。

4.代碼review很重要

有些公司在系統(tǒng)上線之前，會組織一次代碼評審，一起review一下這個迭代要上線的一些代碼。

通過相互的代碼review，可以發(fā)現(xiàn)一些代碼的漏洞，不好的寫法，發(fā)現(xiàn)自己寫代碼的壞毛病，讓自己能夠快速提升。

當然如果你們公司沒有建立代碼的相互review機制，也沒關系。

可以后面可以多自己review自己的代碼。

5.多用explain查看執(zhí)行計劃

我們在寫完查詢SQL語句之后，有個好習慣是用explain關鍵字查看一下該SQL語句有沒有走索引。

對于數(shù)據(jù)量比較大的表，走了索引和沒有走索引，SQL語句的執(zhí)行時間可能會相差上百倍。

我之前親身經(jīng)歷過這種差距。

因此建議大家多用explain查看SQL語句的執(zhí)行計劃。

關于explain關鍵字的用法，如果你想進一步了解，可以看看我的另外一篇文章《explain | 索引優(yōu)化的這把絕世好劍，你真的會用嗎？》，里面有詳細的介紹。

6.上線前整理checklist

在系統(tǒng)上線之前，一定要整理上線的清單，即我們說的：checklist。

系統(tǒng)上線有可能是一件很復雜的事情，涉及的東西可能會比較多。

假如服務A依賴服務B，服務B又依賴服務C。這樣的話，服務發(fā)版的順序是：CBA，如果順序不對，可能會出現(xiàn)問題。

有時候新功能上線時，需要提前執(zhí)行sql腳本初始化數(shù)據(jù)，否則新功能有問題。

要先配置定時任務。

上線之前，要在apollo中增加一些配置。

上線完成之后，需要增加相應的菜單，給指定用戶或者角色分配權限。

等等。

系統(tǒng)上線，整個過程中，可能會涉及多方面的事情，我們需要將這些事情記錄到checklist當中，避免踩坑。

7.寫好接口文檔

接口文檔對接口提供者，和接口調(diào)用者來說，都非常重要。

如果你沒有接口文檔，別人咋知道你接口的地址是什么，接口參數(shù)是什么，請求方式時什么，接口多個參數(shù)分別代碼什么含義，返回值有哪些字段等等。

他們不知道，必定會多次問你，無形當中，增加了很多溝通的成本。

如果你的接口文檔寫的不好，寫得別人看不懂，接口文檔有很多錯誤，比如：輸入?yún)?shù)的枚舉值，跟實際情況不一樣。

這樣不光把自己坑了，也會把別人坑慘。

因此，寫接口文檔一定要寫好，盡量不要馬馬虎虎應付差事。

如果對寫接口文檔比較感興趣，可以看看我的另一篇文章《瞧瞧別人家的API接口，那叫一個優(yōu)雅》，里面有詳細的介紹。

8.接口要提前評估請求量

我們在設計接口的時候，要跟業(yè)務方或者產(chǎn)品經(jīng)理確認一下請求量。

假如你的接口只能承受100qps，但實際上產(chǎn)生了1000qps。

這樣你的接口，很有可能會承受不住這么大的壓力，而直接掛掉。

我們需要對接口做壓力測試，預估接口的請求量，需要部署多少個服務器節(jié)點。

壓力測試的話，可以用jmeter、loadRunner等工具。

此外，還需要對接口做限流，防止別人惡意調(diào)用你的接口，導致服務器壓力過大。

限流的話，可以基于用戶id、ip地址、接口地址等多個維度同時做限制。

可以在nginx層，或者網(wǎng)關層做限流。

9.接口要做冪等性設計

我們在設計接口時，一定要考慮并發(fā)調(diào)用的情況。

比如：用戶在前端頁面，非常快的點擊了兩次保存按鈕，這樣就會在極短的時間內(nèi)調(diào)用你兩次接口。

如果不做冪等性設計，在數(shù)據(jù)庫中可能會產(chǎn)生兩條重復的數(shù)據(jù)。

還有一種情況時，業(yè)務方調(diào)用你這邊的接口，該接口發(fā)生了超時，它有自動重試機制，也可能會讓你這邊產(chǎn)生重復的數(shù)據(jù)。

因此，在做接口設計時，要做冪等設計。

當然冪等設計的方案有很多，感興趣的小伙伴可以看看我的另一篇文章《高并發(fā)下如何保證接口的冪等性？》。

如果接口并發(fā)量不太大，推薦大家使用在表中加唯一索引的方案，更加簡單。

10.接口參數(shù)有調(diào)整一定要慎重

有時候我們提供的接口，需要調(diào)整參數(shù)。

比如：新增加了一個參數(shù)，或者參數(shù)類型從int改成String，或者參數(shù)名稱有status改成auditStatus，參數(shù)由單個id改成批量的idList等等。

建議涉及到接口參數(shù)修改一定要慎重。

修改接口參數(shù)之前，一定要先評估調(diào)用端和影響范圍，不要自己偷偷修改。如果出問題了，調(diào)用方后面肯定要罵娘。

我們在做接口參數(shù)調(diào)整時，要做一些兼容性的考慮。

其實刪除參數(shù)和修改參數(shù)名稱是一個問題，都會導致那個參數(shù)接收不到數(shù)據(jù)。

因此，盡量避免刪除參數(shù)和修改參數(shù)名。

對于修改參數(shù)名稱的情況，我們可以增加一個新參數(shù)，來接收數(shù)據(jù)，老的數(shù)據(jù)還是保留，代碼中做兼容處理。

11.調(diào)用第三方接口要加失敗重試

我們在調(diào)用第三方接口時，由于存在遠程調(diào)用，可能會出現(xiàn)接口超時的問題。

如果接口超時了，你不知道是執(zhí)行成功，還是執(zhí)行失敗了。

這時你可以增加自動重試機制。

接口超時會拋一個connection_timeout或者read_timeout的異常，你可以捕獲這個異常，用一個while循環(huán)自動重試3次。

這樣就能盡可能減少調(diào)用第三方接口失敗的情況。

當然調(diào)用第三方接口還有很多其他的坑，感興趣的小伙伴可以看看我的另一篇文章《我調(diào)用第三方接口遇到的13大坑》，里面有詳細的介紹。

12.處理線上數(shù)據(jù)前，要先備份數(shù)據(jù)

有時候，線上數(shù)據(jù)出現(xiàn)了問題，我們需要修復數(shù)據(jù)，但涉及的數(shù)據(jù)有點多。

這時建議在處理線上數(shù)據(jù)前，一定要先備份數(shù)據(jù)。

備份數(shù)據(jù)非常簡單，可以執(zhí)行以下sql：

create table order_2022121819 like `order`;
insert into order_2022121819 select * from `order`;

數(shù)據(jù)備份之后，萬一后面哪天數(shù)據(jù)處理錯了，我們可以直接從備份表中還原數(shù)據(jù)，防止悲劇的產(chǎn)生。

13.不要輕易刪除線上字段

不要輕易刪除線上字段，至少我們公司是這樣規(guī)定的。

如果你刪除了某個線上字段，但是該字段引用的代碼沒有刪除干凈，可能會導致代碼出現(xiàn)異常。

假設開發(fā)人員已經(jīng)把程序改成不使用刪除字段了，接下來如何部署呢？

如果先把程序部署好了，還沒來得及刪除數(shù)據(jù)庫相關表字段。

當有insert請求時，由于數(shù)據(jù)庫中該字段是必填的，會報必填字段不能為空的異常。

如果先把數(shù)據(jù)庫中相關表字段刪了，程序還沒來得及發(fā)。這時所有涉及該刪除字段的增刪改查，都會報字段不存在的異常。

所以，線上環(huán)境字段不要輕易刪除。

14.要合理設置字段類型和長度

我們在設計表的時候，要給相關字段設置合理的字段類型和長度。

如果字段類型和長度不夠，有些數(shù)據(jù)可能會保存失敗。

如果字段類型和長度太大了，又會浪費存儲空間。

我們在工作中，要根據(jù)實際情況而定。

以下原則可以參考一下：

• 盡可能選擇占用存儲空間小的字段類型，在滿足正常業(yè)務需求的情況下，從小到大，往上選。
• 如果字符串長度固定，或者差別不大，可以選擇char類型。如果字符串長度差別較大，可以選擇varchar類型。
• 是否字段，可以選擇bit類型。
• 枚舉字段，可以選擇tinyint類型。
• 主鍵字段，可以選擇bigint類型。
• 金額字段，可以選擇decimal類型。
• 時間字段，可以選擇timestamp或datetime類型。

15.避免一次性查詢太多數(shù)據(jù)

我們在設計接口，或者調(diào)用別人接口的時候，都要避免一次性查詢太多數(shù)據(jù)。

一次性查詢太多的數(shù)據(jù)，可能會導致查詢耗時很長，更加嚴重的情況會導致系統(tǒng)出現(xiàn)OOM的問題。

我們之前調(diào)用第三方，查詢一天的指標數(shù)據(jù)，該接口經(jīng)常出現(xiàn)超時問題。

在做excel導出時，如果一次性查詢出所有的數(shù)據(jù)，導出到excel文件中，可能會導致系統(tǒng)出現(xiàn)OOM問題。

因此我們的接口要做分頁設計。

如果是調(diào)用第三方的接口批量查詢接口，盡量分批調(diào)用，不要一次性根據(jù)id集合查詢所有數(shù)據(jù)。

如果調(diào)用第三方批量查詢接口，對性能有一定的要求，我們可以分批之后，用多線程調(diào)用接口，最后匯總返回數(shù)據(jù)。

16.多線程不一定比單線程快

很多小伙伴有一個誤解，認為使用了多線程一定比使用單線程快。

其實要看使用場景。

如果你的業(yè)務邏輯是一個耗時的操作，比如：遠程調(diào)用接口，或者磁盤IO操作，這種使用多線程比單線程要快一些。

但如果你的業(yè)務邏輯非常簡單，在一個循環(huán)中打印數(shù)據(jù)，這時候，使用單線程可能會更快一些。

因為使用多線程，會引入額外的消耗，比如：創(chuàng)建新線程的耗時，搶占CPU資源時線程上下文需要不斷切換，這個切換過程是有一定的時間損耗的。

因此，多線程不一定比單線程快。我們要根據(jù)實際業(yè)務場景，決定是使用單線程，還是使用多線程。

17.注意事務問題

很多時候，我們的代碼為了保證數(shù)據(jù)庫多張表保存數(shù)據(jù)的完整性和一致性，需要使用@Transactional注解的聲明式事務，或者使用TransactionTemplate的編程式事務。

加入事務之后，如果A,B,C三張表同時保存數(shù)據(jù)，要么一起成功，要么一起失敗。

不會出現(xiàn)數(shù)據(jù)保存一半的情況，比如：表A保存成功了，但表B和C保存失敗了。

這種情況數(shù)據(jù)會直接回滾，A,B,C三張表的數(shù)據(jù)都會同時保存失敗。

如果使用@Transactional注解的聲明式事務，可能會出現(xiàn)事務失效的問題，感興趣的小伙伴可以看看我的另一篇文章《聊聊spring事務失效的12種場景，太坑了》。

建議優(yōu)先使用TransactionTemplate的編程式事務的方式創(chuàng)建事務。

此外，引入事務還會帶來大事務問題，可能會導致接口超時，或者出現(xiàn)數(shù)據(jù)庫死鎖的問題。

因此，我們需要優(yōu)化代碼，盡量避免大事務的問題，因為它有許多危害。關于大事務問題，感興趣的小伙伴，可以看看我的另一篇文章《讓人頭痛的大事務問題到底要如何解決？》，里面有詳情介紹。

18.小數(shù)容易丟失精度

不知道你在使用小數(shù)時，有沒有踩過坑，一些運算導致小數(shù)丟失了精度。

如果你在項目中使用了float或者double類型的數(shù)據(jù)，用他們參與計算，極可能會出現(xiàn)精度丟失問題。

使用Double時可能會有這種場景：

double amount1 = 0.02;
double amount2 = 0.03;
System.out.println(amount2 - amount1);

正常情況下預計amount2 - amount1應該等于0.01

但是執(zhí)行結果，卻為：

0.009999999999999998

實際結果小于預計結果。

Double類型的兩個參數(shù)相減會轉(zhuǎn)換成二進制，因為Double有效位數(shù)為16位這就會出現(xiàn)存儲小數(shù)位數(shù)不夠的情況，這種情況下就會出現(xiàn)誤差。

因此，在做小數(shù)運算時，更推薦大家使用BigDecimal，避免精度的丟失。

但如果在使用BigDecimal時，使用不當，也會丟失精度。

BigDecimal amount1 = new BigDecimal(0.02);
BigDecimal amount2 = new BigDecimal(0.03);
System.out.println(amount2.subtract(amount1));

這個例子中定義了兩個BigDecimal類型參數(shù)，使用構造函數(shù)初始化數(shù)據(jù)，然后打印兩個參數(shù)相減后的值。

結果：

0.0099999999999999984734433411404097569175064563751220703125

使用BigDecimal的構造函數(shù)創(chuàng)建BigDecimal，也會導致精度丟失。

如果如何避免精度丟失呢？

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)先使用批量操作

有些小伙伴可能寫過這樣的代碼，在一個for循環(huán)中，一個個調(diào)用遠程接口，或者執(zhí)行數(shù)據(jù)庫的update操作。

其實，這樣是比較消耗性能的。

我們盡可能將在一個循環(huán)中多次的單個操作，改成一次的批量操作，這樣會將代碼的性能提升不少。

例如：

for(User user : userList) {
   userMapper.update(user);
}

改成：

userMapper.updateForBatch(userList);

20.synchronized其實用的不多

我們在面試中當中，經(jīng)常會被面試官問到synchronized加鎖的考題。

說實話，synchronized的鎖升級過程，還是有點復雜的。

但在實際工作中，使用synchronized加鎖的機會不多。

synchronized更適合于單機環(huán)境，可以保證一個服務器節(jié)點上，多個線程訪問公共資源時，只有一個線程能夠拿到那把鎖，其他的線程都需要等待。

但實際上我們的系統(tǒng)，大部分是處于分布式環(huán)境當中的。

為了保證服務的穩(wěn)定性，我們一般會把系統(tǒng)部署到兩個以上的服務器節(jié)點上。

后面哪一天有個服務器節(jié)點掛了，系統(tǒng)也能在另外一個服務器節(jié)點上正常運行。

當然也能會出現(xiàn)，一個服務器節(jié)點扛不住用戶請求壓力，也掛掉的情況。

這種情況，應該提前部署3個服務節(jié)點。

此外，即使只有一個服務器節(jié)點，但如果你有api和job兩個服務，都會修改某張表的數(shù)據(jù)。

這時使用synchronized加鎖也會有問題。

因此，在工作中更多的是使用分布式鎖。

目前比較主流的分布式鎖有：

1. 數(shù)據(jù)庫悲觀鎖。
2. 基于時間戳或者版本號的樂觀鎖。
3. 使用redis的分布式鎖。
4. 使用zookeeper的分布式鎖。

其實這些方案都有一些使用場景。

目前使用更多的是redis分布式鎖。

當然使用redis分布式鎖也很容易踩坑，感興趣的小伙伴可以看看我的另一篇文章《聊聊redis分布式鎖的8大坑》，里面有詳細介紹。

21.異步思想很重要

不知道你有沒有做過接口的性能優(yōu)化，其中有一個非常重要的優(yōu)化手段是：異步。

如果我們的某個保存數(shù)據(jù)的API接口中的業(yè)務邏輯非常復雜，經(jīng)常出現(xiàn)超時問題。

現(xiàn)在讓你優(yōu)化該怎么優(yōu)化呢？

先從索引，sql語句優(yōu)化。

這些優(yōu)化之后，效果不太明顯。

這時該怎么辦呢？

這就可以使用異步思想來優(yōu)化了。

如果該接口的實時性要求不高，我們可以用一張表保存用戶數(shù)據(jù)，然后使用job或者mq，這種異步的方式，讀取該表的數(shù)據(jù)，做業(yè)務邏輯處理。

如果該接口對實效性要求有點高，我們可以梳理一下接口的業(yè)務邏輯，看看哪些是核心邏輯，哪些是非核心邏輯。

對于核心邏輯，可以在接口中同步執(zhí)行。

對于非核心邏輯，可以使用job或者mq這種異步的方式處理。

22.Git提交代碼要有好習慣

有些小伙伴，不太習慣在Git上提交代碼。

非常勤勞的使用idea，寫了一天的代碼，最后下班前，準備提交代碼的時候，電腦突然死機了。

會讓你欲哭無淚。

用Git提交代碼有個好習慣是：多次提交。

避免一次性提交太多代碼的情況。

這樣可以減少代碼丟失的風險。

更重要的是，如果多個人協(xié)同開發(fā)，別人能夠盡早獲取你最新的代碼，可以盡可能減少代碼的沖突。

假如你開發(fā)一天的代碼準備去提交的時候，發(fā)現(xiàn)你的部分代碼，別人也改過了，產(chǎn)生了大量的沖突。

解決沖突這個過程是很痛苦的。

如果你能夠多次提交代碼，可能會及時獲取別人最新的代碼，減少代碼沖突的發(fā)生。因為每次push代碼之前，Git會先檢查一下，代碼有沒有更新，如果有更新，需要你先pull一下最新的代碼。

此外，使用Git提交代碼的時候，一定要寫好注釋，提交的代碼實現(xiàn)了什么功能，或者修復了什么bug。

如果有條件的話，每次提交時在注釋中可以帶上jira任務的id，這樣后面方便統(tǒng)計工作量。

23.善用開源的工具類

我們一定要多熟悉一下開源的工具類，真的可以幫我們提升開發(fā)效率，避免在工作中重復造輪子。

目前業(yè)界使用比較多的工具包有：apache的common，google的guava和國內(nèi)幾個大佬些hutool。

比如將一個大集合的數(shù)據(jù)，按每500條數(shù)據(jù)，分成多個小集合。

這個需求如果要你自己實現(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);

如果你對更多的第三方工具類比較感興趣，可以看看我的另一篇文章《吐血推薦17個提升開發(fā)效率的“輪子”》。

24.培養(yǎng)寫技術博客的好習慣

我們在學習新知識點的時候，學完了之后，非常容易忘記。

往往學到后面，把前面的忘記了。

回頭溫習前面的，又把后面的忘記了。

因此，建議大家培養(yǎng)做筆記的習慣。

我們可以通過寫技術博客的方式，來記筆記，不僅可以給學到的知識點加深印象，還能鍛煉自己的表達能力。

此外，工作中遇到的一些問題，以及解決方案，都可以沉淀到技術博客中。

一方面是為了避免下次犯相同的錯誤。

另一方面也可以幫助別人少走彎路。

而且，在面試中如果你的簡歷中寫了技術博客地址，是有一定的加分的。

因此建議大家培養(yǎng)些技術博客的習慣。

25.多閱讀優(yōu)秀源碼

建議大家利用空閑時間，多閱讀JDK、Spring、Mybatis的源碼。

通過閱讀源碼，可以真正的了解某個技術的底層原理是什么，這些開源項目有哪些好的設計思想，有哪些巧妙的編碼技巧，使用了哪些優(yōu)秀的設計模式，可能會出現(xiàn)什么問題等等。

當然閱讀源碼是一個很枯燥的過程。

有時候我們會發(fā)現(xiàn)，有些源碼代碼量很多，繼承關系很復雜，使用了很多設計模式，一眼根本看不明白。

對于這類不太容易讀懂的源碼，我們不要一口吃一個胖子。

要先找一個切入點，不斷深入，由點及面的閱讀。

我們可以通過debug的方式閱讀源碼。

在閱讀的過程中，可以通過idea工具，自動生成類的繼承關系，輔助我們更好的理解代碼邏輯。

我們可以一邊讀源碼，一邊畫流程圖，可以更好的加深印象。