譯者按： 牛人都說自己是站在巨人的肩膀上，我們也要善於學習他人的經驗。
為了保證可讀性，本文采用意譯而非直譯。另外，本文版權歸原作者所有，翻譯僅用於學習。
小編推薦：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/
