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