這篇文章，作爲自己開發一年的小總結。
因爲一些問題造成了很多不必要的時間的浪費。
這篇文章比較適合，沒有實際開發經驗的人看。同樣適合一年左右經驗的人看。也歡迎有經驗的可以給我提出寶貴的意見。
# # 代碼整潔的相關問題
這一塊，確實中間也浪費了不少的時間，中間領導專門拿着阿里開發規範，來扣我們的代碼，一個細節一個細節的去讓我們改。我倒還是之前本來就熟悉阿里開發手冊。還算比較規範。
建議還是看看阿里的《阿里開發手冊》，另外建議去讀《代碼整潔之道》和《重構：改善既有代碼》這兩本書。然後開始知道整潔的代碼應該是什麼樣的。嚴格的要求自己，做到對自己的每一行代碼負責。建議讀一些設計模式之類的數據另外建議讀一下spring 的源碼，這個可以學到很多的設計思想。對我們設計系統，解決問題有很大的幫助，可從裏邊學習到如何去增加擴展性。
最後如果你覺得自己的代碼ok了，可以下載一下阿里的開發規約的插件。用來檢查自己的代碼，只需要掃描一遍，就知道哪裏有問題。然後去改。
這一塊開始從起手開發就裝上插件，每天提交的代碼，自己檢查。可以節省時間在重新整理代碼上。說白了就是一遍過。
相關插件安裝：https://blog.csdn.net/weixin_39220472/article/details/80077803
# # 第二個問題是 工具類封裝的問題
所謂的工具類，真的就是公用的代碼。本來說好的不重複造輪子，壞就壞在我們不知道輪子在哪裏，其實這就是技術視野的問題。不知道有輪子，所以我們自己造輪子，所以浪費時間。所以要加班要996.
最痛苦的還不是重複造輪子的問題，還有一個輪子在項目裏邊被造了很多次的情況，經理一審查代碼，直接吐了，搶救完經歷，解接下來就得搶救我們的代碼了，協調一下跟你造了重複輪子的同事，要不咱們統一用我的工具類？每個人都覺得自己寫的是最好的，擔心用了別人的要重新測試，害怕出現問題。
這個來來回回的改，加上造輪子與測試，花費很多時間，這些時間都是 996 擠出來的，本來不用加班。
這裏不多囉嗦了，一步到位，我給大家推薦一個 好用的輪子。 叫做 hutool 的工具類，及其方便，pom裏邊直接引入就行了，自己看看裏邊都有什麼輪子就好了。
別看什麼其他別人寫的介紹文檔了，直接去官網上看吧。省事，還準確。
# # 第三個問題是使用統一配置中心的問題
我們是使用的 Apollo，攜程的統一配置中心。一開始剛進項目，不懂什麼是統一配置，剛從學校出來，誰聽說過呀。關鍵，我們的項目打好，引入了 Apollo的依賴，並沒有去從 Apollo上讀取配置信息。讀的本地的配置，結果項目跑起來，就時不時的去拉取配置。
我覺得這個問題，就狠一點，一步到位，要麼直接從一開始就用統一配置中心。最後省事，但是在開發過程中，可能會痛苦一點，一不小心，別人給你的配置誤刪了，估計就得找很大一會爾錯誤，才知道配置沒了。 這麼說起來，也可以一開始都用本地的配置，不要引入Apollo，最後都測試沒問題了，統一引進來。這個也耽誤了比較長的時間。
# # 第四個問題就是分庫分表的問題
我們的項目是一開始在單庫上做開發，都開發完，測試完了，又要加分庫分表。
我們用的 sharding 做的分庫分表，sharding 天生就不支持一些sql，比如集合函數需要起一個別名，比如 distinct去重操作，幾乎不支持。這些也沒人給我們說，就讓我們自己解決，自己測試。這太浪費時間了。
關於這個問題，我覺得也是一步到位，從項目開始就去考慮要不要進行分庫分表，這樣省去了重複測試的問題，會節省很多很多的時間。另外就是一定要有人出來把sharding 相關的坑，就給大家說明白，免得重複跳坑，浪費時間。
sharding 說是對開發人員來說無感的，其實並不是，需要注意蠻多坑。具體的還是看官方文檔。
# # 自身問題
當然了，自己本身也是有問題的，比方一上來的時候，因爲環境問題會耽誤很長是時間。還是多遇見一些問題就好了。