優(yōu)秀工程師經(jīng)驗(yàn)分享

大多數(shù)人喜歡碎片化時間閱讀一些文章或者自己感興趣的技術(shù)博文。比如你在上下班路上、點(diǎn)餐等飯時間看幾個公眾號技術(shù)文章，很多人會大致瀏覽完。我覺得這樣不如不讀，或者收效甚微。因?yàn)槟X子只有印象的話，看完的文章過半年后問，肯定一問三不知了。與其多篇文章大致瀏覽，不如精讀一篇文章，并動手實(shí)踐每個技術(shù)點(diǎn)和細(xì)節(jié)。必要時做好博文記錄最后總結(jié)輸出。

另外對于每個技術(shù)不要停留在會用（我稱之為 api 資深工程師）而是知道這個 api 背后的原理，設(shè)計(jì)模式、設(shè)計(jì)的優(yōu)缺點(diǎn)。比如 iOS 領(lǐng)域著名的 WKWebView 很多人知道 NSURLProtocol 可以攔截其他的網(wǎng)絡(luò)請求卻攔截不到它里面 post 的 body 內(nèi)容。你查看了 webkit 源代碼之后就知道 WKWebView 官方宣傳快，是說自身做的事情少了，很多任務(wù)比如網(wǎng)絡(luò)是新開了一個獨(dú)立線程去處理，所以獨(dú)立線程處理網(wǎng)絡(luò)完了通過 IPC 的方式將 post 的 body 通過壓縮然后 IPC 給 WKWebView 這會非常消耗資源，所以系統(tǒng)索性不給你傳遞了。

帶著這個疑問看看 Chrome for iOS 的開源項(xiàng)目（至于為什么會看它？因?yàn)閭€人研究多端融合能力、Chrome 這樣的瀏覽器如何渲染處理等流程感興趣所以看的），看到它里面在用 post 傳 body。納悶了，和 webkit2 源代碼不一致。這些現(xiàn)象等都是需要深入才可以理解的。當(dāng)你遇到一個問題發(fā)現(xiàn)網(wǎng)上找不到資料或者資料比較少的時候你就算對這個問題的研究比較深入了。

此外，不管做產(chǎn)品還是技術(shù)都不要湊合，必須要做到極致或者最好。上面說的反爬蟲技術(shù)是我在公司擔(dān)任 iOS 工程師的時候做的。當(dāng)時進(jìn)去一個月寫完一個 App，追到 Android 進(jìn)度。然后不滿足于進(jìn)度，在此基礎(chǔ)上做到的一些優(yōu)化、且通過抓包方式進(jìn)行業(yè)務(wù)測試的時候找到了 Android 和服務(wù)端的一些 Bug，最后還發(fā)現(xiàn)安全性較低，在此基礎(chǔ)上，做了 HTTPS + 證書驗(yàn)證 +RSA 證書校驗(yàn)、AES 數(shù)據(jù)加密，做到了 App 被別人抓包馬上就斷掉鏈接。假如技術(shù)再高明些看到請求信息也是加密過的（不是 HTTPS 自己的加密，是自定義的加密）和防重放策略。

之后鑒于公司的網(wǎng)站太落后，用 Vue 進(jìn)行重寫，再做了安全升級等工作，這樣總經(jīng)理看到個人能力，擔(dān)任小公司大前端負(fù)責(zé)人的崗位。這階段的成長也蠻快的
然后換工作，也是一樣，嚴(yán)格要求自己，半年時間做了無痕埋點(diǎn)、組件化、模塊化、Hybrid 能力提升、商城業(yè)務(wù)模塊開發(fā)等等，從高級工程師升級為資深工程師。個人目標(biāo)2年后成為技術(shù)專家。

很多人會去問有沒有較好的學(xué)習(xí)資料是什么？我覺得如果有人回答除官方文檔之外的答案，那么這個人本身就不夠?qū)I(yè)。在我看來官方文檔是設(shè)計(jì)者（最熟悉技術(shù)細(xì)節(jié)的人）寫出的注釋和說明。那么肯定是最佳實(shí)踐。舉個例子 Objective-C 里面對 NSDictionary 進(jìn)行處理成 JSON 字符串，解析的結(jié)果是會帶空格和換行符的，但是服務(wù)端恰好如果對空格和換行敏感的話，那么你們的邏輯就會和預(yù)期的不一致。