Spring+SpringMVC+MyBatis+easyUI整合優化篇(八)代碼優化整理小記及個人吐槽


前言

這兩天也一直在糾結這一篇文章該寫什么東西,前面臨時加的兩篇文章就有些打亂了整體節奏,這一篇又想去寫一下代碼層面優化的事情,可是也不太能抓住重要的點,不太確定從何入手,因為這件事情牽涉了太多技術問題,存在於項目的方方面面,如果想要透徹的去講這件事,我也知道是不可能的,糾結了兩天,這篇文章就着眼於最近的一些改動上吧。
花了一周的時間,把項目小小的優化了一下,雖然只是一部分,但是慢慢積累下來,效果應該會越來越明顯的。
我的github地址

原因

前面的文章講了log、maven、測試、版本控制,這些可能都是在項目維度上的一些優化方案,但是我想了一下,好像代碼這一層的優化確實沒有刻意的去記錄過,覺得平時實現功能和解決bug的都是必須的再正常不過的事情了,因此也沒有單獨寫一篇文章去說這個事情。

為什么今天會寫這么一篇文章,也是因為最近的個人狀態不怎么好吧,要工作,要更新代碼,要新增功能,還要寫博客,實在是有些無法全部兼顧,尤其是最近代碼的修改和提交也比較頻繁,寫博客這件事就有些跟不上進度了。幾件事情都想要去做好,但是精力有限,因此最近狀態也有些起伏,希望這幾天可以調整好。(這兩句話是發發牢騷,順便湊湊文章的字數)。

平時做練習的時候,也不止寫了這一個項目,以后也會陸陸續續放到github上來。這個小demo更新了也有兩個月了,打算就在這篇文章里講講對代碼的改動和一些自己的想法,當然,都是圍繞這個demo及最近的一些修改去論述,以往的修改以及以后的計划可能就不會提太多。

至於這次修改的原因,一方面,是自己想對項目小小的動一次刀,另一方面,是開源到網上之后,很多朋友都給了反饋,指出了許多的問題,因此也更堅定了心中的想法,還有一個原因,就是有些朋友的做法我不是很理解。

如何優化

首先是優化目標的明確,結合網友的反饋和自己的想法,總結了以下四點:

  • 代碼整潔
  • 提升響應速度
  • 體驗優化
  • 減少資源開銷

然后是要找到優化的關鍵點,確認優化的方向使得方案落地。

代碼整潔:

  • 代碼命名規則

項目不大的時候可能也不會有特別不協調的感覺,但是如果項目越來越大,參與其中的同事越來越多,差異性和不協調行就體現出來了,每個人都按照自己的方式、每個人都天馬行空、每個人都按照自己的想法不作出妥協,最終得到的可能是一團一團亂麻一樣的代碼,如果項目中新增一位成員,看着各種風格的代碼,應該會瘋吧。
這是15年寫的代碼,那時候對於命名規則還不怎么關注,編寫代碼的時候只講究功能實現,寫的時候也就天馬行空任意發揮,想怎么寫怎么寫,不考慮后期的維護或者和同事之間的合作。如果一直這樣肯定不會有什么進步,實現了功能后,也要想想怎么更好的實現功能,怎么使得代碼更美觀,怎么使得響應速度更快,怎么更安全,怎么更健壯....
針對於此做了兩個方面的改動,一是檢查了java代碼中的命名規則,其中不合理的做了修改,改為駝峰命名法,二是修改了一下數據庫表中字段的命名方式,統一改為蛇形命名方式,以后都會遵循這兩種方試,做好代碼規范。

  • 清理程序中多余的代碼

代碼中有很多注釋,或者一些暫時用不到的代碼,由於擔心可能會用到或者擔心項目經理突然改變主意了,因此就注釋掉放在項目里不管了,少量代碼還好,如果時間長了,這種不在意的代碼越積越多,影響代碼觀感,也影響后期維護人員,因為在熟悉代碼時不僅要看正常的代碼,這些注釋了未刪除的代碼也要一並看了,不然他也覺得會漏掉東西,這就是個不良循環,實際上沒用或者說連編碼者都不知道什么時候會用到的代碼充斥在項目里,實在不是一件好事,因此,該果斷刪掉的就果斷刪掉,即使將來用到,你也完全可以查詢版本記錄。
由於一些原因,刪除了書架的功能,一開始是想注釋掉的,覺得可能有人會用到,后來還是全部刪除了,這種"無用"代碼存在於項目里真的不是一件舒心的事。

體驗優化和速度提升:

布局不合理,頁面卡住,加載速度慢,bug太多,這些因素都會導致用戶體驗很差,屎一樣的東西沒人願意用的,針對這幾個問題做了如下修改。

  • 頁面布局修改

不止一次有人留言說過頁面中布局不合理,沒有做自適應,頁面會隨着瀏覽器的拉伸而卡住,一開始並沒有立刻修復,因為當時有其他功能需要上線,所以就擱置了,這次重新修改了頁面布局,看起來比原來清爽許多,也不會因為拉伸而卡住了。

  • 提高加載速度

在原來的列表頁面,打開都比較慢,加載動畫就一直轉啊轉,用戶看到這個頁面就只能一直等,直到頁面渲染完成,這個過程就比較煎熬。導致這個問題的原因就是請求時pageSize設置不合理,數值過大導致加載較慢,100條數據就說明網絡請求需要從后端服務器傳輸100個數據量的數據,得到這100個量的數據還要通過js去渲染這100條數據到頁面中,現在pageSize改為10,只需要從后端獲取並傳輸10個數據量的數據,前端js也只需要渲染10條數據就完成整個渲染過程,10和100的比較,速度對比還是很明顯的。

  • bug修復

bug太多,用戶在頁面中得不到正確的響應,也很影響體驗,url跳轉錯誤和重復alert的bug修復后,首頁的體驗應該會好一些。

減少資源開銷:

盡量重用對象
減少使用new關鍵字創建對象
程序中有多線程線程編碼時使用線程池
使用數據庫連接池
下一篇開始詳細介紹

總結

其實代碼優化這件事呢,一直在做,可以在github上看到一條條的commit,記錄着代碼的變化及功能改動。以往呢確實沒着重的去講這個點,因為這是一件會持續下去的事情,即使講也只能講其中的一部分,實在太多知識點了,剛好這周並沒有做太多的功能,只是做了一些修修補補,於是用一篇文章來對這周完成的工作做個總結,以后還會用更多的篇幅來講述項目的改進和優化。

吐槽

其他事情不說了,就說現在的網站吧,我本來想的就是大家下載代碼之前可以先體驗一下,但是有些人做的事情怎么就這么討厭呢?兩件事讓我有點兒煩躁,1.改admin密碼,2.亂插數據。
我是真的想不通啊,體驗測試可以,修改數據可以,但是為什么你連登陸信息也要改,你改了別人就不看了?還有些人呢,添加了n多的數據,往一張表里添加了1000萬條左右的數據,導出來都是幾百兆的文件,我也是很煩躁,哈哈哈。可能有些人會說,誰讓你自己寫的不嚴謹的,活該。他媽的,我代碼公開的,賬密也公開的,我還怎么嚴謹?有些時候也不能只考慮自己完全不顧及別人吧。也因此修改了部分功能,這種人也真的是無聊幼稚。

算了,也不怪別人了,有問題就自己修復吧,怪也沒用,誰理你。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM