知識星球來自：折騰範兒の味精
連結：http://awhisper.github.io/2018/08/15/interview-suggestion/
原文標題：面試中的個人競爭力
前言
最近因為個人原因換了份工作，離開了獃了5年的百度，應邀寫一篇關於iOSer找工作面試相關的文章。我回顧了一下從畢業到現在的工作經歷，我發現我幾乎沒怎麼面試與找工作過，基本上就一直在百度一獃就是5年。真要說在找工作/面試技巧/Offer選擇上我有啥經驗，可能值得介紹與分享的非常少，就連這次換工作，我也基本上是面了一家就定下來了。
不過我覺得面試技巧也好/找到理想的工作也好，其實離不開展現你個人的競爭力，展現你個人最好的一面來讓自己在競爭中脫穎而出，從而贏得好機會的青睞。所以這篇文章主要和大家聊聊個人競爭力
很少寫雞湯類的文章，尤其是個人經驗個人感悟，有時候聽的人總會覺得稍微有點虛。但在百度當面試官，當晉升評委，面試過不少的人，也見識過很多技術人在面試過程中經常犯的錯。站在面試官/評委的角度，什麼樣的能力與素質算得上有競爭力，這些話題雖然有點虛，但也算換個角度給大家一些參考。
其實主要就是想從2個角度來聊一聊
-
展現競爭力：
面試也罷，晉升也罷，歸根結底要把自己最好的一面展現出來。但很多技術人都會有一些困擾，做了好多東西深入的研究，但不知道如何表達，一兩句話說完了，別人也感受不到這裡面你的心血與技術投入。怎麼辦？
-
增強競爭力：
思考如何展現出個人競爭力的前提，就是要自己不斷地培養資深的實力。但日常工作非常瑣碎，無休止的迭代畫介面，這種枯燥的工作下，毫無技術提升，怎麼辦？
在展現個人競爭力
既然聊面試，找工作，就是在聊一個如何表現自己的個人競爭力，如何把自己推銷出去的話題
在簡歷上，展現競爭力
寫簡歷我覺得可能很多人存在很大的誤區，先總結出兩句雞湯，然後再詳細和大家說明一下
-
大家都寫，每個人都千篇一律，每份簡歷上都能看到的東西，除了必不可少的，能不寫絕對不要寫
-
專案經歷多，簡歷特別長，那就乾脆很多專案直接不寫。只留下最突出的重點，最表現你思考深度技術深度的專案，其他一句話帶過甚至省略
其實簡歷也不一定完全按著我下麵介紹的套路來，但遵循這上面兩條雞湯，你完全可以自由發揮。其實所有的出發點就是你覺得你寫出來的這份簡歷跟別人比，有啥不一樣的？能吸引人眼球的？這就是競爭力
基本資訊一定要寫
什麼是基本資訊？就是下麵這些資訊，任何公司的HR系統，都需要錄入的，用於錄入內部人才庫檢索，用於聯絡你。這就是必不可少的資訊。照片？可以貼可以不貼呀～這個比較隨意～
-
個人資訊
-
姓名/出生年月
-
聯絡方式
-
郵箱/電話
-
教育經歷
-
學校名稱/學歷/時間段
個人技能，熟練XX，精通XX，完全不要寫
1個面試官如果一天需要篩選100份簡歷，能有95份簡歷寫著，熟悉Objective-C，精通Runtime，熟悉Hybrid，精通ReactNative，熟悉XXX等等。槽點就來了，如果你是面試官，看到這些你有什麼感覺？
-
精通？你說的精通是深入原始碼底層各種666的精通，還是79塊錢買本書21天精通XXX的精通？
-
你說是精通就是精通了？我為啥要相信呢？你說後面的專案經歷能體現出來？那直接看專案經歷就好了，在這裡寫這些不多餘麼？
-
還有人給自己的技能打了個分，或者畫了個進度條。你自己說你達到這個水平，沒有面試官會覺得這些評分有參考價值，還是要看實打實的專案經歷
-
一口氣列了七八行精通這，熟悉那，一大坨文字，格式幾乎都一樣，面試官很容易視覺疲勞。你就是夾雜著一個精通 Objective-C 等單詞的拼寫，面試官都可能看都不看一眼
個人技能其實完全可以捨棄，畢竟專案經歷才是證明你能力的核心。但如果想表達一些除了日常工作之外的技術棧，那麼在這裡寫一下個人技能也不是不可以。如果你想表達你有多方向技術棧，在這裡就只寫技術棧涉獵範圍，iOS/RN/FE/Node.js等。自己拿捏你最想突出的技術棧或者技術方向，別一口氣寫了個iOS，然後一個古腦把Runtime，MVVM，元件化，動畫特效，效能最佳化，資料庫，什麼能想到的名詞都堆上去。
-
不要寫太多，全是重點等於沒有重點，涉獵技術棧範圍全寫上去等於全不會。
-
不要加任何修飾與描述詞彙在這裡評價你的水平，水平要考後面貨真價實的專案經歷。
工作經驗，挑重點，不要寫流水賬
工作經驗是簡歷的重要組成部分，經歷過的每家公司一定要寫清楚 公司名/ 入職時間/ 離職時間/ 職位，這幾個內容是重要的不能缺失的，大公司的HR人才庫會嚴格入庫記錄的。因為很多公司是很看重誠信的，這塊建議把所有經歷的公司按著時間倒序一一寫清楚。（如果有一些特殊原因，比如某段工作經歷特別短，那麼簡歷裡沒體現，建議也要在面試的時候提出）
每家公司其實還需要介紹一下 工作職責，負責的業務情況，團隊情況（如果你是帶團隊的），大體使用了什麼技術棧（如果你不寫個人技能那一塊，涉獵技術棧更適合放在這裡）。
-
挑重點1：如果你的工作經歷非常多，換過的公司比較多，比較久遠的公司就不要寫工作職責了，寫上四大基礎資訊，一帶而過吧。
-
挑重點2：如果你最近的一次的工作時間非常的長，你在這家公司經歷了個人的成長，角色職責也經歷了轉變與晉升，那麼你完全可以把最近的一次工作經歷細化，細化出子時間段。XXX時間-XXX時間，普通研發工程師，負責XXX模組業務功能迭代。XXX時間-XXX時間，晉升，負責了XXX更大業務，帶了團隊。這塊可以靈活控制，但只要遵循一個準字，挑重點，不囉嗦！
專案經驗，挑重點，體現技術價值
專案經驗其實應該區別於工作經驗，在這裡體現出你親自做過親自完成的技術成果，展現你的技術深度，這裡才是應該用事實體子來證明你精通XXX的地方。如果你寫負責XX專案的日常常規迭代，保證產品穩定，寫這麼一行廢話基本上就等於工作經驗裡的工作職責，負責了XX業務幾個字，那這種專案經驗其實根本不用寫，在工作經歷的職責裡已經介紹過了。
專案經驗應該寫什麼？應該寫體現你技術深度與技術價值的具體Case，而不是籠統的說負責一個產品業務負責實現迭代上線。在這個Case裡越細化越好，越突出你個人做的技術努力越好。這裡應該是找你的工作生涯中的亮點專案（技術驅動的Topic/有著高業務複雜度的Feature），抽出來進行單獨說明和展現，進行亮劍，展示你的技術肌肉。普通平庸日常的工作乾脆就不要提了。
至於什麼東西堪稱亮點，每個人的看法與經驗都不同，不是說得難到什麼程度才能擺在這裡當作亮點進行強調。而應該是從你所有做過的專案，開發過的模組中，找到你覺得最有價值的，最有深度的內容，挑3-4個，4-5個。對於你來說這些就是你的最拿得出手的亮點，不必管別人眼裡什麼東西才稱得上難點，什麼東西才稱得上亮點。
舉個例子：
-
技術驅動的Topic
因為業務上有XX問題XX背景，純技術驅動，深入到原始碼底層，進行改造或者擴充套件支援，構建了一個XX系統，支援外部這麼使用，支援外部那麼使用，支援外部靈活擴充套件，對外提供給外部門，外公司使用。（純技術上的一些特點，根據自己的case進行描述，亮出自己的肌肉）
-
有著高業務複雜度的Feature
因為業務及其複雜，在各種條件下有著各種處理邏輯，相互之間存在巢狀與依賴，並且還要滿足PM的未來擴充套件和定製需求，基於此設計出來的XX結構，包含了 XXX層 XXX層 XXX層 XXX層，相互之間隔離清晰，程式碼擴充套件性強。
以上只是瞎YY的，但需要感受一下如何表達出你做出來的獨一無二的技術努力與技術深度，而不是千篇一律的，開發了XX模組，使用了XX庫，接入了XXX輪子，你應該表述的是，你是如何理解你使用的輪子，你開發的模組，這裡面有哪些是你的思考，這些思考解決了什麼問題，建立了什麼價值。
其他，個人發揮
簡歷其實完全可以進行一定的個人發揮，但還是要堅持一點，你要發揮的東西必須是有價值的，與眾不同的！如果強行湊內容，顯得自己涉獵範圍很廣，那不如不寫
-
業務貢獻：
如果你擔任了一定的業務與管理職責，儘管不是PM，但有很多業務思考，你覺得這是你的一大優勢，足以構成亮點，那麼就可以寫進去，這年頭增長駭客的興起，這其實是一個很稀缺的能力
-
開源貢獻：
有些人就貼了個Github地址，寫在簡歷裡很顯眼的一行，和專案經歷/工作經歷同一層級。遵循有亮點就表現出來，沒亮點不如不寫的原則，不如針對Github裡的Repo，挑1～2個出來，介紹一下（如果只想貼個Github地址，不如移到聯絡方式裡，一帶而過）
-
個人部落格：
有些人貼了個部落格地址，也是簡簡單單一個 URL 放在那裡，和專案經歷/工作經歷同一層級。還是那句話要麼突出亮點，要麼乾脆不寫。部落格如果堅持更新，你的博文更新頻率，1年半年內寫了多少篇文章，總共多少W字，都可以在這裡進行展示。如果從更新頻次或者數量上不夠亮點，那麼挑你覺得你最好的1～2篇文章（被廣泛傳播過的/你技術鑽研最深的），URL直接附在簡歷裡，簡單介紹，讓面試官品評
-
個人獎項：
這個東西其實如果是大公司（一些被市場上廣泛認可的大公司）的一些很有份量的獎項（內部獎項，績效），可以在這裡提一提。但提的時候應該強調，你的這個獎，整個公司總共多少人，有多少人能獲這個獎。你的績效，整個部門總共多少人，有多少比例能夠拿到這個績效。（這個東西見仁見智，也有可能公司的獎項並不能被面試關認可，自己把握）
簡歷篇幅
我始終是覺得如何把自己的最重點/最亮點的一面，用1頁A4紙充分展現，那麼這份簡歷就足夠了。其他的太多日常普通的工作，完全可以不提了，相信我，所有人都在寫反覆的在一個又一個專案經驗裡寫“完成專案的日常功能需求迭代”，“保證專案的穩定”，“與產品/前端/後端溝通，參與需求評審”，這種所有人都寫的東西，其實根沒寫沒有任何區別，面試官用眼睛一掃而過，根本不會停留多少註意力。
但其實也不是強行要壓縮在1張A4紙範圍內，但我覺得一定不能超過2頁A4紙，時間比較久遠的經歷，非常普通平庸的專案經歷，乾脆就捨棄吧。
記住一句話：
用最簡潔的篇幅，展現出你個人獨一無二的亮點。
我一直在強調展現你個人的亮點，個人的競爭力。有可能對於不同公司，不同招聘崗位，看中的簡歷加分項是不同的，如果條件允許，完全可以對每一份投遞的職位都進行特殊的定製，而不必非得一份簡歷，海投一切職位。
對於不同的職位側重，在有限的篇幅裡，你應該展現出適合這份職位的最有價值的“亮點”
準備多分簡歷這事不做強求，其實就看你對一些公司一些職位寄予多大的希望了，當你特別特別想去一家公司的時候，這種簡歷定製絕對值得
在面試交流中，體現競爭力
面試這個環節，在這裡還是先灌一個雞湯，或者說一個面試的指導思想
-
不要糾結結果，關註並且表達出來你的思考過程
確實很多公司面試是希望找到能立刻進入工作，能立刻幹活，有豐富經驗的人。但相信我，大公司或者說有發展眼光的公司都會很關註一個人的潛力。潛力這個詞很虛，面試官如果需要在個把小時內透過溝通瞭解一個人的潛力，就需要瞭解一個人的思維過程，進一步判斷一個人解決未知為題的思維方法，從而對候選人的潛力進行一個判斷。所以表達出你的思考非常重要！
面試官的風格
很多人在交流面試經驗的時候，會提起自己遇到的面試官，什麼樣的風格都有
-
有讓你手寫程式碼的
-
有照著面試題問，或者做卷子的
-
有聊技術聊業務，聊專案經歷的
-
有自己也不太懂套你技術方案的（傳說中有。。。）
-
有裝B難為人的（傳說中有。。。）
一開始先不以最壞心態來揣測面試官（畢竟如果你覺得面試官咄咄逼人，是否側面說明這個職位團隊不適合你，雙向選擇），就以平常心來看待如何能將你的優點，你的知識深度展現出來，讓無論是什麼樣的面試官都能get到。你不能要求你一定遇到你習慣的面試官風格，但還是有固定的方式來展現自己。
問題與回答
遇到你十分肯定的問題，自信點直接說出答案。
遇到你內心模稜兩可的問題，也完全可以適當的和麵試官針對問題進行交流。有可能是問題的前提條件以及範圍界定你沒理解清晰，也有可能是你拿不準這個問題要考慮到多深的複雜度，所有在你推理思考出答案的過程中有疑問的點，甚至是思考過程中有一處不會，其實都是可以和麵試官交流。這個過程中就體現裡你的邏輯思考能力，是否能答出最終100%完美的結果並不重要，能讓面試官去充分考察你的潛力。潛力這個很虛的詞，就是透過不斷地與面試官思維上碰撞和交流，讓對方感受到的。
遇到完全沒接觸過的問題，如果你真的這個方向涉獵都很少，不如直接和麵試官說，沒有太大關係，換下一個。
遇到分歧
這裡或許有一些面試官的小花招或者小心思在裡面。有些時候你其實說對了，面試官心裡也知道你是對的，一個勁的追著你問“你確認是這樣麼？”。有些時候你看著題目就覺得彆扭，或者面試官給的引導就有點奇怪，有可能面試官做的一些設計在裡面希望你發現或者提出漏洞。我想說的是不見得所有的面試官都會這樣，但不排除確實有這種情況。當然也會有面試官本身理解就錯了所以對你提出的質疑也有問題的情況。
在你並不清楚面試官是什麼樣的套路下，現場表現出來的情況就是，你和麵試官之間遇到了分歧。分歧其實沒啥，還是我說的從分歧點出發，展示出你的思考過程，邏輯過程，甚至可以在溝通中表達出你以前做過的看過的類似問題，雖然不是直接匹配但能側面為你的回答佐證。
不要不懂裝懂，但如果你經過了你自己的思考後還是對面試官存疑，把你的思考拿出來，無論結果怎樣，思考過程都是有價值的。
遇到問專案經歷
前邊在介紹如何寫簡歷的時候就已經給大家強調，專案經驗應該是突出你的亮點，突出你做東西的難度，突出你思考的深度。如果面試官針對你的專案經歷來進一步詢問，這應該是一個巨大的機會，是一個展示你自己的 show time。簡歷裡幾行字表達不出來的東西此時此刻就是最好的呈現時機。
展示你的專案經歷的過程，就是展示你在當初做這個專案的思考過程，遵循為什麼要做，怎麼做，收益怎麼樣的固定套路來進行表達，這個套路其實也適合職位晉升面試答辯。歸根結底，這個套路本就應該是把一個專案做好做漂亮做的有深度的必備深入思考過程。
-
為什麼要做？
有什麼業務背景？是否有老舊疑難雜症？這個事情是否屬於業界難題，業界也不是很成熟？是不是因為我們業務的特殊原因導致勢在必行？這裡面有什麼預見到的坑必須解決？
-
怎麼做？
經歷過技術選型沒？對比過市場上的幾種技術方案優缺點？你查閱了怎樣深度的相關資料來解決問題？你設計成什麼樣？結構有多複雜？擴充套件性如何？你覺得你這麼設計有啥優點？深入到了什麼深度的程式碼底層？Cover了多頻繁的產品未來可預見的變化需求？
-
收益怎麼樣？
有多少業務接入了你的這個功能？這個效能，流暢度達到了多少？訪問量PVUV多少？這個專案收益怎麼衡量的？是否符合預期？
遇到開放性話題，無從回答
開放性話題你不善表達，所以不知道怎麼回答？車軲轆話說了很多遍了，思考過程。不會做沒有問題，按著自己腦子裡已有的知識概念，找面試官反覆確認場景和問題，把你腦海中關聯的知識點篩選出來，從中進行推理，然後進一步和麵試官溝通確認。開放性話題一般面試官也是做好準備進行引導的，如果你收到了一些引導或者提示，可以繼續跟著思考下去，哪怕沒有直接得到最終答案，把階段性的思考過程與面試官互動，獲得進一步的引導。
多想，把你怎麼想的表達出來，你怎麼想的過程是有價值的，能夠體現你個人邏輯與思維能力的，是一種競爭力。
如果只是悶頭不說話，悶頭一個人使勁想，你想了再多也傳達不到面試官，一個良好的相互交流過程才有助於面試官瞭解你
在工作生活中，增強競爭力
在準備面試的過程中，按著各種套路手段總結自己的簡歷的時候，有些人會發現平日裡的專案經驗都是完成日常的基礎業務迭代，提煉不出所謂的亮點，如果沒有平日的積累，光靠面試準備抱佛腳儼然是不行的。
在日常的工作生活中，如果你有機會被安排去做一些有深度，有難度，大專案，自然是好的，你可能不需要怎麼用心，就能在日常專案開發中順利的實現個人成長（側面也說明，一個好的公司，好的部門，好的團隊，好的平臺對於個體而言是有很大很大的促進因素的）
如果你的日常工作生活，都是無聊透頂的，無休止的畫介面，拉網路請求刷 TableView。如何在這樣的工作環境下，收穫個人技術的提升呢？
總結思考
再平凡的工作，也需要不斷的反思，不斷的回顧，要有一顆程式碼潔癖的心，不能容忍不優雅的程式碼。
簡單舉幾個例子有助於理解，但實際工作中包括但不限於這些例子
-
一次業務迭代因為時間緊任務重，快速懟上程式碼上線了，當專案完成了，回顧一下這裡面的程式碼有沒有倉促，不合理，再時間充裕的情況下把他改好。
-
多次產品業務迭代，都是在修改同一功能模組，每次都改動成本很大，是否說明這個模組在最初的架構設計之中不足以cover可預期的產品功能迭代，是否可以和產品溝通瞭解一下未來的趨勢，然後著手徹底最佳化一下功能模組的原始架構，讓你的程式碼保持優雅，讓未來的需求變更更輕鬆
-
是否發現專案程式碼中存在很多看似差不多，只有略微差異，但卻被重覆複製了很多份散落在工程各處的程式碼？是否意味著這些糙快猛趕緊上線弄出來的程式碼應該被重新思考，重新規劃與架構？
枯燥的日常工作，不能成為停止總結思考的藉口。程式員應該是腦力工作者，不是重覆機械性寫程式碼的體力工作者。如果你的工作非常單調，重覆，程式員的Style應該是想辦法，改進/自研開發工具，讓單調/重覆的工作變得自動/半自動化，解放自己的生產力。
發現問題
如果你所在的團隊，沒有機會讓你參與一個有深度有難度聽起來就NB上天的專案，這也不是問題。沒有誰會在剛畢業什麼都不懂的時候，就被安排到一個牛逼到爆炸的專案組，坐等導師帶著，手把手就蹭著牛逼專案直接從菜鳥變成大神。
真正需要培養的，是一雙自驅的發現問題，發現最佳化點的眼睛。自己尋找方向，自己尋找標的，然後付諸行動。剛剛入門的菜鳥，帶著這樣的眼睛，從小的地方自驅提出最佳化，自驅解決。就能證明你比別人的思考更多，更深，更有競爭力，就更容易獲得高難度專案的機會。
簡單舉幾個例子有助於理解，但實際工作中包括但不限於這些例子
-
現在業內有了一些新的技術，這些技術我們能用在產品上，能帶來收益，自驅進行探索，最終落地形成收益。
-
工程中有一段功能實現已經趨於落後陳舊，程式碼中存在問題與隱患，自驅提出最佳化與改進。
-
團隊的開發人力總是浪費在一些不需要多少思考的重覆性工作上，為了提高研發效率，自驅的提出一些改進的技術Topic。
-
關註研發中的各項統計資料，發現其中的邏輯關聯性，自驅的提出一些產品最佳化的點，哪怕是研發提出來的
-
產品研發中總會面臨一些不可抗力，作業系統禁止，手機廠商禁止，許可權不透過，因此技術上總會有一些妥協，這些妥協的問題有沒有一些自驅的可以繞過的方案？
探尋本源
對待所用的技術選型，技術方案，三方框架，也要有一種探尋本源的精神。簡單的說對原始碼有刨根問底的意願，再往深了說，對編譯原理，作業系統，圖形渲染等機制有底層探索的意願，不要甘心於只做一個調包俠。
經常會有人說“管他什麼作業系統，底層原始碼，老夫寫程式碼就是一把梭，複製貼上，抄起鍵盤就是乾”，也會有人有疑問“關心原始碼幹嘛？會用不就行了”，這其實就是一個知其然，知其所以然的問題。
知其然表示，你只能依靠檔案，介面，API說明，去瞭解熟悉掌握一個框架的使用，如果像CocoaTouch這樣的成千上萬的API，如果只想做到知其然，難道只能靠官方檔案/谷歌搜尋/StackOverFlow去開發了麼？純經驗論？做過的人告訴你這個東西應該怎麼寫，你寫過了才記住？
知其所以然則表示，在去查閱檔案介面的同時，還去深入瞭解框架底層的運作機理，當有你不瞭解的需求給過來的時候，儘管你並不知道是否API已經開放了這個功能和能力，但透過對運作機理的理解你能先有大概的判斷，甚至能透過底層/中間層的核心中樞程式碼，反推找到外層那個不好查閱的介面呼叫，如果相關介面不滿足，你也充分有能力去改進支援。甚至哪一天你不滿足於三方框架，而根據同樣的原理機制，自己實現一套自己用的順的自研框架。
對於三方框架來說，知其所以然就是他們的原始碼，那麼對於各類開發語言來說，知其所以然是什麼呢？是作業系統，編譯原理，圖形渲染機制等等。
註意這裡說的是意願，不是要人人抱一本龍書，沒任何生產實踐的情況下硬啃下來全套編譯原理，而是希望你在學習瞭解一個事物一個框架的情況下，不要止步在外層呼叫，遇到一個case，可以根據這個case嘗試深入，帶著case去理解底層程式碼。同理遇到一個case也可以深入到作業系統機制，甚至編譯原理之中，君不見很多啟動效能最佳化的方案來源於什麼？為什麼有的語言能熱更新，有的不能？帶著case，帶著探究本源的意願，去發現一個個更深的技術領域。
探尋本源 How Why What
這裡我先原樣Copy一段@真阿當 老師的微博，這段微博我真的是非常非常認可
一位同學找我聊進階的困惑:
“面了下網易，阿裡相關的職位，感覺還是有些差距的。我感覺可能是有一個瓶頸期了。
感覺在技術高度，視野的高度不夠。很多東西都是我從未思考，或者接觸過的。又或者說是存在於我日常中，但我無法感知到。這些層面的東西，在面試的時候是比較懵的。
具體原因很難說，感覺是一種不知道自己不知道的狀態。”
這位同學的狀態很典型。
曾經我寫過一篇文章，講”元知識”。什麼意思呢?知識可以分為”道”與”術”，對應於”why”、“how”和”what”，在技術圈how和what一直在變，還存在很多派別，why基本不變，how變化較慢，what變化最快，也數量最多。
很多人是從what切入的，並且停留在what這裡，過了適應期就開始自滿了。有些人會去分析how和why。然後有了自己的判斷，有了深度。然後有些人會去繼續尋找更多的別的領域的why和how，而不是糾結在過多的what裡。然後很奇妙的，why和why之間會形成互補和聯接，how和how之間殊途同歸，學what如有神助般迅速。
舉個例子，解耦，封裝，多人合作，分層是why，mvc的路由、ORM、模板引擎和OO是how，ROR、django和angular是what。
挖how和why是重點。怎麼挖呢?我個人的經驗是多讀好書，多看資訊，多做練習，多總結，去悟。”悟”這件事，鮮有人在做總結，需要創造性的能力和一堆歷練，所以無法像what那樣，有滿世界的知識搬運工。
我當時看到這個微博的時候就非常的認可，覺得和我想表達的探尋本源，有著同樣的論點。尤其是最近經常有很多開玩笑的說法，“別再更新Vue了，感覺學不過來了”，“RN、Weex、又出來個Flutter，感覺學不過來了”，“美團又出了個EasyReact，RAC還沒學完”。歸根結底，感覺學不過來的都是在關註what，其實真正需要理解與領悟的應該是how 與 why
●編號308，輸入編號直達本文
●輸入m獲取文章目錄
Web開發
更多推薦《18個技術類微信公眾號》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
