年終跳槽小結-前端篇

年末了，又將迎來一波跳槽小高峯。

算下來工做也兩年半了，最終仍是決定換個環境繼續折騰。跳槽的目的無疑是爲了更好的發展以及更高的薪酬。然而我並不打算討論這些「政治問題」，而是想回顧下這些年來，本身在技術上的收穫。

一個工做三年的前端應該掌握哪些技術？具有哪些硬技能？

我想每一個人狀況不一樣，並沒一個標準答案，但確實是一個值得思考的問題。按照某3-5年前端崗位要求，起碼應該達到如下幾點：

1.前端技術基礎紮實，熟練掌握 HTML、CSS、JavaScript;

2.熟悉前端框架 React 、Vue.js等，對前端工程化和組件開發有較深的理解；

3.熟練掌握 Web 開發相關知識，至少熟悉一門後端語言，例如Node.js、Java、Go等；

4.對技術有熱情，有必定前端架構能力或者技術深度；具有企業級大型前端應用開發經驗更佳；

5.團隊合做意識強，可以多團隊協做開發；

但這其實描述的很是泛，每一個人都會在不一樣領域有所沉澱。而本身的關鍵字，應該是模塊化 + 無線端了，固然還可能有團隊協做、溝通、項目管理等一系列能力沉澱，不作展開，本文主要談技術上的思考。

模塊化思考

談到模塊化，不可避免的會涉及到工程化，組件化(相關區別網上不少，不作展開)。只是本身在工做期間寫了大量業務模塊，因此對模塊化思考更多些。而 module 一詞，在不一樣的語境中也會有不一樣含義，下面從分別從代碼工程層面和系統平臺層面進行介紹。

代碼&工程

代碼層面的模塊化主要涉及語言規範和代碼組織自己。光是對於JS模塊化的演進，就能夠寫上好幾篇了，好比CommonJS(NodeJS)、AMD(RequireJS)、CMD(seajs)，相關介紹網上不少，不作展開，所幸如今都用ES6+了。一個模塊，能夠是一段代碼，一個文件，或者一個文件夾，這是代碼組織的藝術。不管其形態如何，解決的問題都是同樣的：

• 分而治之

牢記這個原則，基本不會出問題，但並不必定優雅，如何分治，如何解耦，如何提升可擴展性同時又不過分設計都須要至關多的經驗，另外一條須要注意的是：

• 最小適用

這點對無線端開發尤其重要。舉個栗子，不少H5頁面都會用到zepto，通常都是直接引入整個js，但zepto做爲一個完備的工具庫(兼具DOM/event/ajax/form/animation...)，可能有些東西咱們並不須要，最佳的方式是隻用頁面中用到的模塊便可（好比只用DOM+event），流量寸土寸金，代碼也是。

其餘的想到了再補充吧，有空能夠多看看孫(dai)子(ma)兵(da)法(quan)，不做展開。技術的成長最直接的體現就是代碼質量，每一個程序員都會有看到本身之前寫的代碼就感受xxx同樣的想法吧。

系統&平臺

代碼層面的模塊化是面向程序員，系統平臺的模塊化範圍則更廣，可能面向程序員，小白用戶或者其餘系統。

舉個栗子，一個系統中可能會有登陸模塊、鑑權模塊、積分模塊等等，這些模塊繼續抽象完備又能造成一個獨立的系統，繼而開放出平臺的能力，爲更多用戶提供PaaS、FaaS服務(咦？怎麼越說越像阿里雲的套路？)。其實阿里很早很早很早就提出了「大中臺，小前臺」的組織模式，聽起來高大上，在我看來其實就是組織架構層面的「模塊化」，沉澱出愈來愈多的中臺能力，驅動快速創新的前臺業務，以搭積木的方式去開發系統。這其中要解決的穩定性、擴展性等問題主要偏後端，或許得再過一兩年我才能完善這部分。

系統平臺領域還有一種直接面向前端用戶的模塊化：可視化模塊。舉個栗子，每一年雙11/雙12各類會場頁面既不是人肉一個個寫的，也不是人工智能自動生成的（或許再過不久有可能），而是前端開發一個個模塊（好比頭圖，標題，商品坑等），運營拖模塊搭建會場並進行投放數據而成。

驀然回首，本身竟有一年多的時間都在弄這個。從源碼搭建到模塊開發再到一套成熟的協做流程，真是一段辛酸史，我嘗試用精煉的文字來概況這類電商動態化運營模式下模塊化的要點：

• 規範化
• 人性化
• 單一職責
• 防護式設計

下面細說：

規範化

我見過一些模塊，命名隨意，也沒有文檔，基本是在面向本身編程，別人接收時：你直接看代碼吧，很簡單的。然而這不是一個簡不簡單的問題，是一個效率問題。代碼模塊化更可能是爲了內聚，運營模塊化則偏向複用，這是須要長期維護的，天然須要一套支持長期維護的規範，並且這種規範最好一開始就樹立好，不然越到後面治理起來越難。

人性化

運營模塊不只面向開發，同時也面向小白運營，咱們開放給運營的配置操做必定要清晰明瞭，足夠人性化，各個字段作好足夠說明，這樣能必定程度上下降運營配置帶來的線上風險。

單一職責

模塊所承擔的職責儘可能簡單。我曾經犯了一個錯誤，那就是開發了一個「強大」的商品展現模塊，能夠支持各類不一樣形式的商品展現形式。但與之而來的就是配置上的複雜性，不只給運營增長了配置負擔，也提升了出錯率。即便是提供同一類功能的模塊，也要適度拆分，在複用性和可用性上做出權衡，把問題儘可能簡單化。

防護式設計

編程中出現的大部分問題，都是來自於意料以外的輸入數據，更況且這些數據還出自運營之手。因此對於模塊配置項必需要給予schema約束，對數據作好校驗和兜底，在代碼和平臺層面都作好防護式設計。工做中遇到很多案例，由於讀取字段爲空報錯而致使模塊不可用，嚴重的狀況整個頁面都會掛掉。

開放仍是封閉？

這實際上是一個模塊管理的問題，有這樣一個場景：

A部門前端小明開發了一個業務模塊並公開在平臺上，B部門運營看到後以爲不錯就拿來直接用了，小明很開心，以爲本身的模塊不只幫助到了自個兒部門，還幫助到了其餘部門！

但故事還有後續，B部門運營在使用模塊上遇到問題都會找小明，以爲這裏不行得改改，XX能不能調一下...

小明：大家本身的需求找本身部門的開發啊
運營：但是我已經用了你的模塊啊

原本是業務定製的模塊，開放出去意味考慮更多通用性的東西，以及更大的維護成本，必定要慎重(忽然聯想到開源)。同時不一樣使用方之間的模塊也要作好隔離，這樣運營在選擇時能夠規避不少誤操做。

是否值得模塊化？

最後要說的就是不要爲了模塊化而模塊化。不少東西以爲能夠模塊化，能夠沉澱下來下次複用，但到最後你會發現計劃永遠趕不上變化，真正能複用下來的並很少。本着經濟適用便可，切忽考慮過分，你花了大量時間在上面，可能需求後面就被一刀砍了。

以上經驗皆源自實戰，必然沒有某些編程大做中描述完整。之前看書看到相似總結時大呼：我TM怎麼不早點看這本書！如今想一想，可能早點看也沒什麼暖用，高內聚，低耦合，可複用，可擴展誰不知道？實踐出真知，人只有被打了才知道疼，招聘要求2年以上經驗必然是有道理的。

無線端開發

這兩年多的時間裏基本都在無線端打拼，我很難描述本身究竟學到了哪些乾貨。HTML5?
CSS3? ES6+? Webpack? Vue.js? React? Weex? 這些東西誰都會，沒啥好說的。這兩年前端的工程化和組件化體系也都完善起來了，本身只能算是一個見證者，多去看看大佬們的總結會比較好。惟一想總結的，就是堅決了將來的方向。曾經有Native/hybrid/Web多種技術方案，一開始我是一個堅決的Web理想主義，以爲隨着技術的發展Web性能終將不是問題，後來用了Weex後發現性能確實甩Web一大截，既具有Native的性能又有Native的設備能力。然而用的越深，發現這種方案的問題越多，不少細節上是沒法處理好的，在產品上不得不作出妥協。後來又看了天貓超市Mobile Web的極致體驗優化和業內一些分享，發現走Web路線也是能夠作的很好的，關鍵點就在於容器的能力。從最近Google和UC的動做來看，會有愈來愈多的設備能力集成在瀏覽器內核中，前端開發體驗只會愈來愈好，加上如今Hybrid技術方案已經比較成熟，極可能某些Hybrid中的能力會在將來直接變成瀏覽器實現標準。

將來技術的發展，一定是將問題變得愈來愈簡單的，若是一項技術的誕生對使用者的要求變得更高，這一定不是一項普惠性的技術。

先寫這麼多吧，這三年的收穫，或許最大的並不在技術自己，而是工做習慣和思考問題的方法，正如 Kent Beck 所說，

「I'm not a great programmer; I'm just a good programmer with great habits.」

對於咱們普通人而言，更重要的是養成好的工做習慣。而身邊有一羣優秀的人，就會潛移默化的感染你，與優秀的人一塊兒共事，也會讓本身變得更優秀。而如今的你就有這樣一個機會：

支付寶招前端啦！
支付寶招前端啦！
支付寶招前端啦！

這邊有平臺，有空間，有大牛，然而遺憾的是缺人才！年末了，正是一個好機會，咱們的招聘要求也很簡單：

• 牛逼

不要被上面崗位描述的條條框框限制了，中國人都很謙虛，只要以爲本身能夠的就簡歷私我，反正不吃虧。暫時不打算換工做的也不要緊，能夠先交個朋友嘛，之後有的是機會~

郵箱：liquanfeng326 @ iCloud.com以上，感謝 (..›ᴗ‹..)