剛畢業(yè)開始還是一名普通的 iOS 工程師，做的東西一般是跟著 TL 開會討論需求，完了自己腦補技術(shù)細節(jié)，完了編碼、UI 還原、測試、發(fā)布、維護。在第一家公司做開發(fā)的時候，某次和一個后端工程師對接口遇到問題，人家說“別跟我說接口有問題。你跟我說是什么樣的問題？我需要參數(shù)”。然后初生牛犢（小菜鳥）就把 Xcode 下面的 Debug 信息截圖發(fā)出去，被人懟，說我需要網(wǎng)絡(luò)的具體參數(shù)，Request、Reponse 信息。當(dāng)時很尷尬，我在想封裝好的網(wǎng)絡(luò)框架，我一個個下斷點 Debug 截圖給你嗎。后來才知道有 Charles 這么個抓包工具，簡單搞了搞 Charles 之后就將截圖 Request、Response 信息給他了，這樣他沒話說了，老老實實改了接口 Bug。當(dāng)時他問我 Request、Response 的時候真的超尷尬，我說你等我半小時，我找好發(fā)給你。

第一次看到 Charles 有那種看到仙女一樣的感覺，因為它不只是可以抓包看 HTTP、HTTPS 的網(wǎng)絡(luò)請求，還可以模擬數(shù)據(jù)、篡改網(wǎng)絡(luò)請求信息、篡改網(wǎng)絡(luò)返回的信息、模擬弱網(wǎng)環(huán)境、接口壓力測試（類似于 Load Runner）、還可以隔山打牛（Map Remote：請求域名 A 下的接口 a 卻重定向到域名 B 下的接口 b）。

另一個有趣的事情是慢慢在公司有了起色，自己鉆研進步了很多。在做的東西 iOS Native + Hybrid 模式的應(yīng)用，因為在校實驗室期間有 web 前端經(jīng)驗，所以在公司經(jīng)常設(shè)計 JS 與 Native（iOS、Android）的通信機制、Hybrid 的能力等等，Debug 的時候經(jīng)常踩坑，比如 Android 瀏覽器訪問 localStorage 需要開啟權(quán)限、某些低版本的 Android 不支持 ES6 寫法（Vue、React等工程自動引入 Babel 打包構(gòu)建的工程是轉(zhuǎn)換過的。之前的老工程直接寫 ES6，則低版本瀏覽器不支持）。還有一些 CSS 在 iOS、Android 兩端表現(xiàn)不一致。因為公司和別的上市公司合作項目，成立了微信群，我們公司對外輸出 SDK，由于另一名同事解決不了。直接跟我說“劉哥，上吧”。由于經(jīng)常解決疑難雜癥，導(dǎo)致對面那個公司的項目經(jīng)理，問我要不要跳槽，讓我去他們公司工作

優(yōu)秀工程師如何進階

說到工程師，肯定要談如何進階。那么我作為一個剛畢業(yè)不久，從 普通工程師 -》 高級工程師 -》 資深工程師，談經(jīng)驗不敢當(dāng)，說說個人的心路歷程吧。

首先剛踏入職場，你必須完成從學(xué)生到職場的轉(zhuǎn)換，這個轉(zhuǎn)換不是說換個地方做事就行了，而是態(tài)度和觀念需要改變。學(xué)生時代在校不管是課程作業(yè)還是畢設(shè)、或者學(xué)校實驗室的那些東西，現(xiàn)在看看都很 low（排除一些高端院校的頂級實驗室項目）。

遇到項目，你要認真分析、思考、編碼。完了之后想想有沒有優(yōu)化空間、代碼規(guī)范（https://github.com/FantasticLBP/codesnippets）。代碼寫多了，可以自定義自己的工作流（https://github.com/FantasticLBP/GitWorkflow） 和快捷鍵（https://github.com/FantasticLBP/knowledge-kit/blob/master/第六部分%20開發(fā)雜談/6.11.md）。

很多人強調(diào)沒時間去學(xué)習(xí)，說什么白天在工作，下班后可能要回家路上花費時間、吃晚飯、然后累了一天可能要想著健身、娛樂下。一天除非睡覺、吃飯時間你有多少時間？所以我覺得學(xué)習(xí)和工作不是互斥的事件，你需要矯正態(tài)度，工作中的每個需求都是一次學(xué)習(xí)進階和檢驗的過程，別人給了需求，你需要系統(tǒng)設(shè)計、架構(gòu)設(shè)計、思考需要幾個類、每個類負責(zé)什么行為、屬性，對外暴露什么接口，類與類如何通信、如何低耦合、高內(nèi)聚、可拓展？Unit test 設(shè)計等等問題都要考慮清楚。剩下就是編碼實現(xiàn)了，這個時候考慮的就是一行行代碼如何書寫，才符合團隊規(guī)范、業(yè)界規(guī)范、代碼如何分組、如何做到自解釋、代碼注釋等等都需要做到極致。完成后跑單元測試、最后集成測試。提交給測試工程師的項目個人至少保證 90% 的測試 case 通過，ut 覆蓋率至少 90%。關(guān)于測試也有一堆經(jīng)驗，等后期我會出文章講講。

個人學(xué)習(xí)和工作的時候注意積累和歸納總結(jié)，梳理自己的技術(shù)棧和知識體系，等下次學(xué)到了新的東西塞到體系里面對應(yīng)的地方去。最后你的知識系統(tǒng)會越來越完善。

工程師強調(diào)幾個方面：

專業(yè)能力是第一要素。你的專業(yè)能力決定你是否具有不可代替行和價值。

軟技能決定你的廣度和效率：比如查找知識的能力、快速定位問題的能力、快捷鍵的熟練程度、自己的 WorkFlow、代碼規(guī)范程度、為團隊打造工程化的程度。比如我經(jīng)常***查找資料，公司的網(wǎng)絡(luò)和自己家里的網(wǎng)絡(luò)都可以***查找資料。使用 iterm2 自己制定了很多 iOS、Web 相關(guān)的快捷鍵、這將顯著提高工作效率、一天提高1分鐘，一年下來就不少的時間節(jié)約（如果想看我的快捷鍵或者 WorkFlow 可以在評論區(qū)留言）。團隊的代碼規(guī)范在前端開發(fā)中有 ESLint 集合業(yè)界的 js 規(guī)范比如 airbnb 或者標(biāo)準(zhǔn)的。iOS 這端我使用 shell 腳本開發(fā)了一套團隊的代碼規(guī)范，最后還有一套 shell 腳本檢測全局工程的代碼規(guī)范，最后會生成報表用瀏覽器自動打開。

不要過分追求框架等表層?xùn)|西，要思考原理。很多人初學(xué)前端會糾結(jié)用 Vue、React、Angular哪個？我覺得沒必要，你首先需要打好基礎(chǔ)功，基礎(chǔ)功好了，框架就很好學(xué)習(xí)了。框架一般做的事情是在現(xiàn)狀的基礎(chǔ)上做了封裝，讓你很方便的做某些事情，或者使用一些設(shè)計模式或者先進一些的開發(fā)方式（比如單向數(shù)據(jù)流、虛擬 Dom、組件化等）。這些東西為什么誕生？還不是傳統(tǒng)的命令式編程效率太低、操作 DOM 成本太高了，復(fù)雜邏輯的頁面維護很復(fù)雜嗎？因為是命令式編程，所以你需要思考每一步步驟，以及中間產(chǎn)生的狀態(tài)變量，告訴計算機如何處理具體邏輯，導(dǎo)致代碼量太大，維護不方便。響應(yīng)式編程 + 虛擬 DOM + 單向數(shù)據(jù)流催生了類 React 的前端框架。比如我之前就看過 Vue 的關(guān)鍵邏輯的源代碼，看過 React 的 Redux 的源代碼。

你的水平高了你關(guān)心的技術(shù)點應(yīng)該就是業(yè)界的研究方向了，比如多端融合能力。你會看到現(xiàn)在的 Flutter、React Native、Hybrid 他們不是沒有關(guān)系的，而是一步步演進升級。電商公司（其他業(yè)務(wù)不再舉例）業(yè)務(wù)經(jīng)常變、運營活動經(jīng)常變，傳統(tǒng)的開發(fā)方式需要發(fā)布、審核、上線，iOS 這里尤其負責(zé)，審核嚴格，隨意這樣的流程不能滿足，早期的 Hybyrid 就是這樣誕生的，Native 提供基礎(chǔ)能力，JS 寫業(yè)務(wù)邏輯和 UI操作，但是這樣很零散，比如 UI 操作，JS 需要一個 UI，Native 就需要事先注冊號或者提供好這樣的能力。React Native 解決了這個問題，JSX 的方式寫業(yè)務(wù)，操作數(shù)據(jù)，setState 做 diff 算法計算出需要更新的虛擬 DOM，在移動端這樣的虛擬 DOM 就可以和 Native UI 組件進行綁定，這樣就可以有 Native UI 能力。JS 寫業(yè)務(wù)，Native 捕獲事件回調(diào)給 JS，然后操作數(shù)據(jù)，繼續(xù) setState。這樣還不錯，但是在低端手機上會卡頓，其中一個問題就是不同語言（JS、native語言）之間通信效率比較低，F(xiàn)lutter 誕生了，Dart 誕生就是為了解決 JS 的缺點。Google 自己的 skia 渲染引擎封裝了 OpenGL 接口，所以不需要 Native 提供 UI 能力，Dart 使用聲明式寫 UI、Skia 去渲染看上去還不錯，所以一開始國內(nèi)的咸魚團隊就在跟進 Flutter，現(xiàn)在阿里 all in Flutter。

經(jīng)驗分享

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

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

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

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

之后鑒于公司的網(wǎng)站太落后，用 Vue 進行重寫，再做了安全升級等工作，這樣總經(jīng)理看到個人能力，擔(dān)任小公司大前端負責(zé)人的崗位。這階段的成長也蠻快的

然后換工作，也是一樣，嚴格要求自己，半年時間做了無痕埋點、組件化、模塊化、Hybrid 能力提升、商城業(yè)務(wù)模塊開發(fā)等等，從高級工程師升級為資深工程師。個人目標(biāo)2年后成為技術(shù)專家。

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

NSJSONWritingSortedKeys（兼容性）、NSJSONWritingPrettyPrinted （換行符）

NSDictionary *dict = @{@“name”： @“l(fā)bp”};

NSData *json = ［NSJSONSerialization dataWithJSONObject:dict options:NSJSONWritingPrettyPrinted error:nil］;

NSString *jsonString = ［［NSString alloc］ initWithData:json encoding:NSUTF8StringEncoding］;

很多人轉(zhuǎn)換后可能會去做字符串處理，正則替換空格和換行符。稍微好一些的可能會看到官方的在 iOS11 推出一個新的枚舉值 NSJSONWritingSortedKeys。那么就是判斷當(dāng)前系統(tǒng)小于 11 則字符串替換，否則就使用新的參數(shù)。如果你仔細看官方文檔，上面說的非常仔細。看看下面的官方說明。

Generate JSON data from a Foundation object. If the object will not produce valid JSON then an exception will be thrown. Setting the NSJSONWritingPrettyPrinted option will generate JSON with whitespace designed to make the output more readable. If that option is not set， the most compact possible JSON will be generated. If an error occurs， the error parameter will be set and the return value will be nil. The resulting data is a encoded in UTF-8.

另外，越來越覺得架構(gòu)設(shè)計對于架構(gòu)組同學(xué)來說是非常重要的。

為什么？假設(shè)你一個需求，預(yù)期10天時間；前期架構(gòu)設(shè)計、類的設(shè)計、Uint Test 設(shè)計估計7天，到時候編碼開發(fā)2天完成。

這么做的好處很多，比如：

除非是非常優(yōu)秀，不然腦子想的再前面到真正開發(fā)的時候發(fā)現(xiàn)有出入，coding 完發(fā)現(xiàn)和前期方案設(shè)計不一樣。所以建議用流程圖、UML圖、技術(shù)架構(gòu)圖、UT 也一樣，設(shè)計個表格，這樣等到時候編碼也就是 coding 的工作了，將圖翻譯成代碼

后期和別人討論或者溝通或者 CTO 進行 code review 的時候不需要一行行看代碼。你將相關(guān)的架構(gòu)圖、流程圖、UML 圖給他看看。他再看看一些關(guān)鍵邏輯的 UT，保證輸入輸出正確，一般來說這樣就夠了

軟件項目管理也一樣，確定好關(guān)鍵時間節(jié)點、甘特圖、確定干系人、kick-of meeting、定期碰頭等

程序員這個工作怎么樣？

個人是很喜歡程序員這個工種的。做事情純粹些、且培養(yǎng)了不斷學(xué)習(xí)思考的能力和習(xí)慣。不斷學(xué)習(xí)和思考是每個行業(yè)都需要的基本素養(yǎng)，所以看到事情本質(zhì)、不斷學(xué)習(xí)、不斷進階就是人生常態(tài)吧