寫給前端工程師的10條實用原則

譯者按： 牛人都說自己是站在巨人的肩膀上，我們也要善於學習他人的經驗。

• 原文: 10 Things You Will Eventually Learn About JavaScript Projects
• 譯者: Fundebug

為了保證可讀性，本文采用意譯而非直譯。另外，本文版權歸原作者所有，翻譯僅用於學習。

小編推薦：Fundebug專注於JavaScript、微信小程式、微信小遊戲，Node.js和Java線上bug實時監控。真的是一個很好用的bug監控服務，眾多大佬公司都在使用。

JavaScript程式設計簡直就是一項冒險。當回顧工業界這10年來經過不成熟到專業的開發歷程，我想每個人都會認同這個觀點。

前端開發有很多豐富的選擇性，充分的靈活性，以及大量發揮創造力的空間。不過，同時也要求我們自己需要有足夠的知識，有一定的規劃和自我約束。

一路走來，我們經歷了jQuery，require.js，Angularjs，React，ExtJs等等。2018年的前端開發可以說是遍地開花。

在開發過程中，你會發現有一些通用的正規化可以適用於各種複雜的專案。接下來我會介紹10個重要的正規化，這些都是我多年來的個人經驗。雖然都是個人的觀點，我相信很多有經驗的開發者都會認同。這一套規則適用於任何專案、任何框架、任何大小的團隊。它可以減少開發者花在文件和重構的時間、甚至開發中的爭吵。

1. 分而治之(Divide and conquer)

這個詞大家並不陌生，但是很多人低估了這條規則的適用場景和能力。CommonJS，Webpack，和Node都支援我們把程式碼拆分到多個檔案，我們為什麼還需要分而治之的理念？

一致性：當程式碼量越來越大，將專案拆分成一個個小的檔案可以讓查詢和以來管理變得十分容易。並且檔案命名要足夠直觀，反應了檔案中程式碼做的相關工作。這樣可以減少耗費腦力去查詢程式碼結構的負擔。

管理便捷：程式碼足夠模組化的拆分使得檔案的移動和進一步拆分變得簡單。如果你發現一個幫助函式在應用中另一個地方也需要用到，你可以建立一個名為/shared的目錄，將程式碼放進去。這樣方便共用，也方便查詢。

2. 任何東西都要超級直觀易懂

** 每一個變數、函式、檔名 — 就如同給你的孩子取名字一樣認真去給他們取名字。**

也許你今天通過把它命名為x節省了0.3秒的時間，但是在接下來的一個月你將會花2天的時間來搞清楚x到底指代什麼，然後再花4天做重構。好好想想，不要擔心命名太長。

避免使用一些奇淫技巧(即使已經足以讓你申請MIT)
你的方案也許很聰明但是負責，導致的後果就是在將來，你或則團隊裡面的其他成員將會浪費大量時間去理解你寫的那段程式碼兜裡是如何運作的。專注於用最直觀簡單的方法把事情搞定，甚至不需要文件或則評論

3. 不要使用魔法數字和字串

和命名的原則一樣，要直觀易懂！不管你覺得可能多麼簡單的值，也要用一個有意義的變數名來宣告。

在大多數情況下，任何你宣告的值很有可能在其他地方複用。因此，通過宣告變數的形式，可以減少程式碼重複，並且易於維護。

4. 避免巢狀太深

如果你寫的程式碼一行超過120個字元，超過500行，或則if語句超過3層，最好做拆分。

你可以把巢狀的if語句拆分成函式，Promises，Observables。如果你使用了很多非同步呼叫，使用async/await也可以極大簡化你的程式碼。

5. 早點做好配置工作

如果你的應用中使用了全域性變數，API介面，第三方認證等等，把它們放到單獨的配置檔案中去。

不管是網頁(web)還是Node，都有很多可用的包(package)來管理配置，比如config。
某種程度上說，你的應用的配置應該做到可以支援執行在生產伺服器和本地開發。
早點建立配置檔案比後面再來做要容易很多，特別是相應的環境配置，安全配置，功能配置等等。

6. 選用合適的框架

花時間想清楚你是否需要框架，以及使用哪個框架。終端使用者不會關心你的網站或者應用使用了一個在Github上超過10w stars的框架。 根據我的個人經驗，我把它們簡單的做了如下分類：

• React: 如果你需要對整體的架構和構建有充分的控制權，React是一個很好的選擇。你需要花時間去熟悉React的整個生態系統，事先做好規劃。而這些都是值得的，如果你很清楚你要什麼。

• Angular / VueJS / Ember: 如果你想要快速實現一個可靠的Web App，就選它們吧。雖然你可能對整個架構有一些不瞭解。這些框架幫你做了很多事情，所以在規劃的時候要想清楚使用它的優點和缺點。它們嚴格的目錄結構雖然少了自由，但是可以讓你少犯錯誤。

• jQuery / lodash / 或則類似的: 如果你想快速實現一個網頁，並且沒有多少的頻寬可用，那麼選用它們能節省你很多時間。不過你需要小心，因為你可能寫出難以維護的程式碼。你要注意把它們當做輔助，而不是基礎。

• Vanilla / 不用框架: 如果你有很多的時間來計劃和開發，那麼使用純JavaScript來寫是個很好的選擇。你可以做一些實驗性的功能，比如引入WebGL，Workers，深度優化，或則動畫等等。最終，你可能甚至做出了自己的一個框架。

把這些當做建議，你需要花時間慢慢去選擇使用哪個框架最適合你的專案。

7. 除非是原型，否則一定要寫測試

單元測試、冒煙測試、端到端測試、合理性(Sanity)檢驗。除非你的專案只是一個原型用來演示，否則趕緊寫測試。當你的程式碼庫越來越複雜後，將會變得難以維護和控制。這個時候，你需要測試來幫你做檢查。

在不遠的將來，當你遇到bug的時候，你會仰望藍天，謝天謝地的感慨好在當初寫了測試。你永遠無法預料新引入的功能是否會默默地把你之前的程式碼搞掛掉。

8. 使用版本控制

不管是一個原型、大型企業專案、或則是一個個人的小專案，使用git或則其它版本管理工具，從一開始就要管理起來。每天保持提交(commit)，使用分支(branch)，學會合並程式碼(merge)，解決衝突，和回退到之前提交的版本。記得提交程式碼的訊息要認真寫，不能隨意亂寫。

版本控制可以讓你更好地管理程式碼，如果今天這篇文章我介紹的其它點你都忘記了，這一點一定要記住。為什麼呢？因為如果你沒記住其它要點，這一點可以幫你很好的管理程式碼，輔助解決其它問題。

9. 狀態管理

使用狀態管理庫，並且完全利用起來。

作為一個前端開發，我們往往只需要面對兩個挑戰- 展示資料和儲存資料。而儲存資料隨著專案的複雜變得越來越難，因為你很容易忽略掉。

使用狀態管理，很微妙。我們的應用往往需要在客戶端和服務端保持一致。我們的目標是不要在中間加上覆雜性，在我們使用JavaScript處理資料的時候。元件應該展示相同的資料、將使用者的更新同步，對服務的的變動做出反饋。如何做到？

• React有著非常豐富的選擇，對於Flux的架構使用Redux，Observable-based的架構則使用Mobx。每一種都有各自的優缺點，確保在使用前充分理解。

• Angular, Ember, and VueJS 各自本身就是基於狀態管理設計的，不過你還是可以使用額外的庫，比如ngRx, Akita和Vuex。

• 對於其它的框架或則Vanilla JavaScript，你可以使用Redux、Mobx，或則你自己的狀態管理方案。使用狀態管理的目的是保證整個應用在全域性層面資料保持一致。

10. 擁抱最新並質疑

最後，積極加入社群並從中學習 — 不過要注意每一條評論、每一篇文章、每一個對你程式碼的反饋，你都要認真思考並適當質疑，而不是全盤接受。積極擁抱新的想法，前端的生態演化總是很快。但是，也不要僅僅為了追逐最新的事物而追，有些東西終究會被拋棄。

** 一個使用老一點、成熟的框架搭建的專案會更好、更穩定，勝過同時使用兩個框架，僅僅因為另一個是新的。** 我們不得不承認新的框架可能會效能更好，不過我建議可維護性排在第一位，只有當你認為真的需要遷移的時候再做遷移。

關於Fundebug

Fundebug專注於JavaScript、微信小程式、微信小遊戲、支付寶小程式、React Native、Node.js和Java實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了6億+錯誤事件，得到了Google、360、金山軟體等眾多知名使用者的認可。歡迎免費試用！

版權宣告:
轉載時請註明作者Fundebug以及本文地址：
https://blog.fundebug.com/2018/08/27/code-interview-data-structure/