---

重要連結：
「系列文章目錄」

「專案原始碼（GitHub）」

前言

有讀者可能知道，我復工前被隔離了十五天。說實話，我還以為我會懷念上班的感覺，結果這種帶薪休假的日子香地一批，到快出來的時候腦子裡各種設想如何當著老闆的面情不自禁地咳嗽兩聲。當然這只是我的內心活動，我第一次見到老闆時對居家枯燥生活的痛恨之情溢於言表，還極其榮幸地接受了好幾件新的分外工作。

最近我把過去屯的課程刷了一些，學習的節奏還算可以。但一連幾天工作千頭萬緒，給我整的下了班還感覺緊張兮兮的。這個時候就比較適合寫文章，因為總結比接受新知識要容易一些。而且我有個習慣，一寫文章就不停打哈欠，可能跟看書促進睡眠是一個道理。

根據最初的規劃，現在我們的專案將要進入 優化與重構 階段。相比上個階段，這一部分的理解與操作難度會變得更大，因為我們要做的事情具有很強的不確定性，究竟怎樣才是正確的，我們無法在進行實踐之前就給出結論。可以說 IT 行業之所以有這麼高的天花板，就是因為這種不確定性。如何在不確定性中尋找確定，讓難以控制的事情儘可能地處於自己的掌控之中，是一個優秀的技術人需要終生磨練的能力。

雖說具體內容不確定，但方向是確定的。為了讓我們的專案 A 起來，需要在三個方面下功夫，分別是：

程式碼規範、服務效能、系統安全

這三個方面的劃分以及本文的核心思想，源自 @範學雷 老師在《程式碼精進之路》中對優秀的程式碼做出的精闢總結。

本篇文章是一個大綱，主要是針對每一個方面提出一些優化的思路。這些思路其實都是各路大牛總結出來的，我只不過是做了一些整合，同時結合我們的專案探索具體可行的操作。

我想，這個教程的主要意義就在於解決 會看不會用 的問題。我在很長一段時間內其實更加偏重理論一些，直到近幾年才深刻體會到實踐的重要性，這也是學習程式設計開發為我帶來的巨大好處。

另外我私底下會對系統的一些業務功能進行完善，由於都是重複性工作，就不在文章裡多提了。近期我打算上傳一下專案的開發日誌，功能變更會列在裡面。由於近期專案主體程式碼的變化可能會比較劇烈，與前期教程不太相符，從頭開始學起的小夥伴可以下載之前的 release，地址是：

https://github.com/Antabot/White-Jotter/releases/tag/v0.2.2

好了，接下來我們進入正題。

一、編寫規範程式碼

規範的程式碼是軟體的根基。規範的程式碼，可以提高編碼的效率，可以降低開發者之間的溝通成本，可以規避不必要的安全問題。在保證程式碼規範的基礎上，我們才能去談效能優化和安全防護。

其實程式語言的語法就是第一層規範，在這一層上大部分人還是做得挺好的，畢竟不遵循這個規範編譯器它根本不搭理我們。然而過了這道關，有不少人就開始放飛自我了。

我推測幾十年前的開發者會有一種老子天下第一的驕傲，編碼不華麗不如去種地。反正那時候會寫程式碼的人也不多，大部分軟體真的就是一個人搞出來的，只要能用就是牛逼。後來時代變了，人均會程式設計了，軟體系統也越來越複雜，才不得不需要秩序。

今天我們學習程式設計其實是站在前人的肩膀上，各種規範其實已經相當成熟。這種情況下我們一定要應用《勸學》大法，與其自己冥思苦想，不如去看，去學。很多時候一個人的程式碼水平並不反映他的聰明程度，而是反映他的見識和意識。 見過優秀的程式碼，體驗過程式碼規範的好處，自然就會處處想著這件事，時時將程式碼規範作為自己的行動綱領。

對於 Java 來說，第一線的規範學習材料包括：

• JDK 原始碼
• SEI CERT Oracle Coding Standard for Java
• Secure Coding Guidelines for Java SE

此外，《Effective Java》以及《重構——改善既有程式碼設計》這兩本書是在設計層面比較優秀的參考資料，尤其是《Effective Java》，幾乎也成為了一種 Java 編碼規範，值得每一個學習 Java 的人仔細品讀。

對於前端，主要是遵循 JS 相關規範，現在來看就是 ES 標準。Vue 也有自己的較好實踐，沒有特殊想法可以參照官方文件的寫法。

在具體編碼的時候，我們需要注意的主要內容如下：

這六個方面還隱含了一條重要原則，就是程式碼要儘量 “清晰明瞭”。 注意 “清晰” 並非 “簡潔”，我相信大家在刷演算法題時都見過一些奇思妙想的解題方法，用一行程式碼幹了我們幾十行程式碼乾的事，賊 6，但是這並不好。假設你的同事給你留下了這樣的神奇演算法，估計你心裡恨不得他頭髮早日掉光。

此外，軟體開發團隊為了進一步保證程式碼質量，通常還需要進行 測試 與 程式碼評審 。對於我們自己來說，做好 單元測試 是必須的，介面測試 雖然大多由專門的測試人員來做，但是其實也不怎麼費勁。對於個人維護的開源專案來說，最好再自己加上 持續整合 。

OK，針對我們的專案，在程式碼規範方面要做的事情，自頂向下包括：

• 梳理專案結構，提高專案可維護性
• 編寫準確、必要、清晰的註釋
• 更換部分不合理的類名、變數名
• 整理部分方法的程式碼段，並考慮複用、封裝一些通用方法
• 編寫單元測試

你看，這些其實都是可以發揮的事，所以會搞成什麼樣子我也不知道 。

二、提高服務效能

軟體開發的主要矛盾，就是使用者日益增長的暢爽體驗需要與不平衡不充分的硬體發展之間的矛盾。都是硬體的鍋，要不是硬體太水太貴，我們也不用費這麼大勁計較雞毛蒜皮子的小事。

開玩笑的。

就算硬體再牛逼一千倍，也頂不住你 $O(n^3)$ 的演算法。解決程式碼規範問題能讓你吃上程式設計師這口飯，但只有具備解決效能問題的能力，才能讓這碗飯吃地香。

效能問題，除了 演算法 之外，還要考慮 軟體架構、軟體設計、軟體部署 ，以及一些具體的 優化技巧。

搞明白這些方面真的不容易，但同樣借用範學雷老師的話，一個人能否解決好效能問題，很多時候都不是取決於聰明程度，而是取決於他的意識和見識。成熟的解決方案就在那兒，容易理解，也容易操作，只是我們沒有想到，沒有看到，沒有用到這些解決方案。

這真的是真知灼見！

不僅僅是軟體開發，在學習各種知識時，我們都有可能因為“聰明”拖累自己，因為一旦我們去重視聰明這個屬性，就會嚴重忽視“努力”的重要性，當我們遇到困難時，首先想的會是自己不夠聰明，認定自己這個破腦子搞不定這些問題，結果還沒有嘗試過就放棄了。有多少聰明人正是因為這種彆扭的認知，活成了不太聰明的樣子。

針對白卷專案，可以從前端、後端兩個方面進行具體分析。

1.前端

前端是直接面向使用者的，因此其優化的核心是 使用者體驗，即 頁面的載入速度 與 操作的響應速度。為了檢驗優化的結果，除了直觀的感受外，我們還需要有靠譜的 度量標準 與 效能測試 手段或工具。

Vitaly Friedman 的大作：

「Front-End Performance Checklist（前端優化清單）」

為我們提供了清晰的整體思路與技術路線。雖然我們很難在短時間內全盤吸收作者提出的內容，但記住上面說過的，“見識和意識”。當你覺得沒有靈感時，就多看看優秀的人是怎麼做的，一時看不懂就反覆看。

我們的專案前端可能會選擇進行如下優化：

由於專案前端邏輯較為簡單，主要工作其實在於載入方面的優化。優化的原則其實可以簡單概括為 “減少請求數量，降低請求大小”。

2.後端

後端效能提升的關注點主要在於 提高響應速度。

相比前端，這是一個更為複雜的命題，需要從多個方面考慮。下面我給你列出一些名詞：

高併發、快取、訊息佇列、資料庫優化、負載均衡、叢集、分散式、微服務、JVM 調優

是不是感覺很頭大？好在我們並不用真的把每個方面做到極致，畢竟沒幾個人能做的到。

當然，還是要在掙扎中前行。現在我們還沒有具體硬體環境，僅就軟體來說，努力的方向有三個，一是 程式碼，二是 “技術應用”，三是 “優化設計”。

當我打算開始進入優化階段後，就越發覺得這個破專案沒眼看了。我很好奇，你們是怎麼能看到這裡還覺得我做的不錯的？（狗頭保命）

一般收到讀者的鼓勵或者感謝時，我都會回覆 “感謝支援，一起進步！” 這是我的肺腑之言，正是因為名不副實地受到了大家的許多認可，我才能堅持學習，堅持輸出（文章也許會遲到，但永遠不會缺席）。

三、考慮系統安全

這裡我用了考慮這個詞，說明我是真的慫。

安全是一個神奇的領域，它的神奇體現在 資訊極其不對等。攻防雙方可能都不知道對面的技術在什麼樣一個水平，很多時候人家背地裡把你扒了個底朝天，你還跟沒事人一樣樂樂呵呵。

我私底下感覺，整體來看攻的力量要強大一些，因為攻可以集中突破，防卻要滴水不漏。我們造出了原子彈，卻造不出對等的防禦手段，只能通過各種 合約、條例 來抑制這種毀滅性的力量。對於系統安全，我們也應該意識到，技術之外的 管理 可能極其重要。

為了給你們講好這部分內容，我混進了一個安全大佬雲集的圈子，這事兒也沒啥好驕傲的，因為我是花錢進去的。圍觀了幾天，最直觀的感覺就是警察叔叔快來，這幫人我們擋不住了。。。

同樣的，給你們推薦個學習資料—— 吳翰清 老師的 《白帽子講 Web 安全》。

即使遲早會被吊打，起碼也要知道對面是哪門哪派、使的什麼招吧。

為了對自己的防禦力大概有個認知，我們還需要一個 評估工具 ——

「CVSS （通用缺陷評分系統）」

只恥而後勇，武功不高就勤學苦練唄。

你看，我們一直都是一個思路，儘量做好自己的能做的事情。畢竟如果這些事情不去做，隨隨便便一個小魚小蝦就能把你給收拾了。

我們需要考慮的安全問題，大概有這麼點：

。。。

大概有這麼些：

此外，還有針對伺服器的安全防護，最主要的是及時修復漏洞。

安全界有個基本道德，就是發現漏洞時會先告知專案的維護者並做好保密工作，給對方留出足夠的時間修復併發布更新，然鵝釋出更新到使用者完成更新還有一段時間，這段時間是最危險的。我們在軟體開發的整個生命週期中，如果得知哪個模組、類庫釋出了 安全更新，一定要 以最快的速度升級到安全修復版本。

另外，有句話叫 “世界上 80％ 以上的攻擊都是由於應用程式的漏洞引起的”。

我們要從兩個方面看這句話：一是應用程式確實容易存在漏洞，我們開發者要時刻具備安全意識；二是之所以這麼多攻擊是由於應用程式漏洞，是因為其它方面其實有一套行之有效的做法，我們如果只顧應用程式，不去佈設其它的防線，那這個比例一定會降低，因為各種攻擊的數量會成指數增長。

下一步

其實最近我的精力主要在後端，估計以後我也會更傾向於講後端的內容，好在據我觀察讀者中做前端的是少數人。

有了這篇大綱，本來後面的文章也不算特別難搞，每種具體的技術做一篇分析與實踐應用就可以了。但我更希望的是能夠和你們一起 開拓視野，探索更多的 可能性，因此可能會花樣作死，繼續嘗試新的技術方案。當這個階段結束時，我再次覺得過去的自己是個憨批什麼也不會，就算是達到目標了。

老有人問我能不能參與到專案中來，我都說好幾次了這是開源的，歡迎提交 pr，你們問完倒是來呀。。。

---

最後，給你們分享兩個小故事。

頭兩天我看評論時，發現推薦欄有一篇文章題目跟我的很像，就點進去看了一下，沒想到李逵遇上李鬼了。

本來吧這些文章也是可以轉載的，放上鍊接就行，有的人加連結就加個文字，也點不動，有的人乾脆連結也不加，我雖然有點在意，但也覺得沒必要說什麼。但這個哥們兒他不是轉載，是洗稿，不但洗技術內容，連說話嘮嗑都模仿我。

你們感受一下，這是我某篇文章的前言：

---

這是那貨的：

---

說實話，我感覺有被冒犯到。當時我覺得這貨居然還蹭了武漢熱點真是夠了，後來突然琢磨過來估計連這加粗兩行字也是看了我上篇文章的結尾才寫上去的，我裂開了。

這個故事的結局是我舉報了他四五篇文章，都通過了。點著挺費勁的，其它的算了，提醒的作用起到就行了。

第二個故事是有個讀者跟我反饋 B 站上有人拿我的專案做了視訊，你們知道像我這樣的社畜的生活是很無聊的，平時我接到詐騙電話都會跟對面多嘮幾句看誰先聊崩，所以當時我特別興奮跑過去圍觀。

當然反饋的讀者本意是對方可能 “侵權” 了，但是其實這個專案是 MIT License，可以隨便拿去用的。只要對方不拿我的教程做講稿，就完全沒有問題。我真正關心的是 UP 主的水平怎麼樣，畢竟關係到我的臉面啊。

看了視訊，發現原來他不是要做講解視訊，是對專案做了一個介紹，然後可能是要接單給人做畢業設計。展示的專案也不完全是白卷，據說是他委託一個同學給他做了 CRUD ，他要講的是推薦系統，核心演算法是他自己寫的。

(⊙o⊙)…

我又仔細看了一遍視訊裡的介紹，感覺他這個同學有那麼一點瓜皮。

視訊的播放量當時大概一兩千吧，賬號也有 1K 的關注量。其實我覺得雖然掙錢的手段不值得提倡，不太正經而且其實掙的是辛苦錢，但他已經有了網際網路營銷的意識與手段，能去搞一搞事情，挺好的。如果能慢慢轉型輸出更有價值的內容，積累下去會有很多意想不到的收穫。

我建議你們也趁年輕多折騰折騰，想想怎麼利用技術掙錢，怎麼利用技術和頭腦合法且輕鬆地賺錢。你要不想提錢覺得太俗，那換個說法，怎麼用知識滿足自己的成就感，怎麼用知識和智慧提高自己的社會地位？

上一篇：Vue + Spring Boot 專案實戰（十八）：動態載入後臺選單

下一篇：Vue + Spring Boot 專案實戰（二十）：前端優化實戰