|
編輯｜小智 戳閱讀原文，獲得短信提醒，不錯過下次InfoQ大咖說直播！ 回復(fù)： 選型 ，獲取完整視頻回顧。 杜歡，滴滴出行技術(shù)總監(jiān)，負(fù)責(zé)滴滴小巴業(yè)務(wù)的技術(shù)管理工作。在互聯(lián)網(wǎng)領(lǐng)域已經(jīng)有十年工作經(jīng)驗，曾就職于微軟、百度，也曾自主創(chuàng)業(yè)兩次，來到滴滴之后也經(jīng)歷過很多項目和業(yè)務(wù)的變化，是一個“什么都懂”工程師，對前端、客戶端、服務(wù)端、運維等方面都有不少實戰(zhàn)經(jīng)驗。平時是一個 ACG 宅，也喜歡閱讀各種技術(shù)和非技術(shù)的文章擴大視野，不愿主動交談，但一旦放松了就聊到停不下來。 今天會聊技術(shù)選型這個話題，主要就是因為我經(jīng)歷相對比較豐富，親歷過不少項目選型的過程，自己也做過不少靠譜或者不靠譜的決策，在這個方面也有些自己的思考。我想先從幾個案例開始，像講故事一樣聊聊選型背后的事，作為話題的開始。 在我剛開始工作時就經(jīng)歷過一次很大的選型事件，我是這件事情的旁觀者。當(dāng)時公司希望做一個非常酷炫的手機界面系統(tǒng)，恰逢 Windows Vista 一系列新技術(shù)的發(fā)布，包括 WPF、Silverlight、C# 這些技術(shù)非?；穑緦λ鼈儽в袠O高的期望，所以就想第一時間用在新一代 Windows Mobile 上面。確實界面開發(fā)和各種效果可以做的很酷炫也節(jié)省了界面開發(fā)時間，但是很尷尬的遇到了另外一個問題，性能問題。 這些東西都是跑在移動設(shè)備上面，當(dāng)年的移動設(shè)備內(nèi)存能有 32MB，CPU 能到 1GHz 就很不錯了，根本不能很好的支撐這一整套界面系統(tǒng)對性能的要求。后來，當(dāng)公司發(fā)現(xiàn)確實在當(dāng)時的硬件環(huán)境下突破性能問題，就對所有界面做了一次重寫，回到了用 C++ 和各種 API 傳統(tǒng)寫界面方式上才解決問題，這里面涉及到將近一千名工程師一年多的時間，可以說是個很大的人力和時間的損失。 當(dāng)時我還不是很理解，為什么公司不能更早一點止損，后來我慢慢發(fā)現(xiàn)，這真的是當(dāng)局者迷，當(dāng)一個決策作出之后大家就天然的希望能通過努力來解決眼前的問題，結(jié)果反而越陷越深。這也意味著最初選型的時候得十分謹(jǐn)慎，特別是選型影響面巨大時保守點會更好。 后來加入了真正的互聯(lián)網(wǎng)公司，我看到了技術(shù)選型是穩(wěn)定壓倒一切。比如 gcc、linux 內(nèi)核這些非常底層和關(guān)鍵的東西，在互聯(lián)網(wǎng)公司里基本不會去追最新版，只是保持了解和跟進，非常克制的將一些 patch 和功能引入到線上環(huán)境，真正上線也會經(jīng)歷相當(dāng)久的灰度驗證過程。 我印象挺深的是當(dāng)年（2009 年）對 lighttpd 和 apache 的選型，當(dāng)時 lighttpd 單機性能明顯優(yōu)于 apache，同時也支持 php 擴展，能夠以 mod 形式運行 php，看起來使用 lighttpd 全面替換 apache 就好了，但實際上為了業(yè)務(wù)穩(wěn)定性，真正的用法是將 lighttpd 做反向代理，后面還是使用 apache + mod_php 來提供服務(wù)。這里面的思考就是對于一個新技術(shù)的天然不信任，在技術(shù)接受程度還不夠高且公司內(nèi)沒有人能吃透這個技術(shù)的情況下，不愿意讓自己的業(yè)務(wù)做第一個吃螃蟹的人。 謹(jǐn)慎確實是個美德，不過如果在一個非常追求速度的業(yè)務(wù)里，這可能也意味著過于保守，會延誤時機。 我在自己創(chuàng)業(yè)的過程中選型就比較激進，也玩的比較 high。 比如我會積極的使用 MongoDB，我對它靈活的數(shù)據(jù)結(jié)構(gòu)、強大的查詢語句和內(nèi)置的高可用機制等非常認(rèn)可，當(dāng)它剛剛 1.0 的時候就將它用在一些不重要的數(shù)據(jù)上，后來等到 2.x 發(fā)布后就開始嘗試用在新業(yè)務(wù)上作為核心數(shù)據(jù)庫。我也曾經(jīng)遇到一些嚴(yán)重的坑，比如數(shù)據(jù)損壞、擴容不及時造成停機等，但是由于業(yè)務(wù)對這些問題容忍度較高，同時也有一些兜底方案，所以還不至于成為業(yè)務(wù)瓶頸，總體來說利大于弊，可以節(jié)省業(yè)務(wù)開發(fā)人員的寶貴時間。 我也曾決策使用 Node.js 作為主力服務(wù)器開發(fā)工具，當(dāng)時（2013 年）因為客戶端要使用 Javascript 作為主力語言，服務(wù)端和客戶端會有不少能夠復(fù)用的代碼，所以挺想使用 Node.js 來提升開發(fā)效率。 為了驗證 Node.js 是否靠譜，我自己通讀了源碼、閱讀了不少相關(guān)文章、看了下官方 release note 及社區(qū)活躍程度（github issues、stackoverflow 討論等）、還做了一些基本的壓測，最后的結(jié)論是，它的性能可以滿足要求，在穩(wěn)定性方面基本合格，考慮到只是用它做無狀態(tài)服務(wù)，且單臺服務(wù)器上都會跑多個實例（當(dāng)時使用 supervisord 管理），簡單的崩潰不會對系統(tǒng)有明顯影響，再加上當(dāng)時確實也有些公司將它作為主力服務(wù)，所以最終選擇了它。 后來加入滴滴后，我在技術(shù)選型方面綜合了以前所有的經(jīng)驗，有做得好的，也有犯錯的時候。 2015 年滴滴有一個很大的內(nèi)部代碼重構(gòu)項目，涉及到服務(wù)端和客戶端大量代碼?？蛻舳说募夹g(shù)選型做的相對較好，針對當(dāng)時代碼庫多業(yè)務(wù)耦合嚴(yán)重，大家開發(fā)時候模塊間沖突頻繁的問題，評估并引入了 cocoapods 和 maven/gradle 作為 iOS 和 Android 的項目拆分工具，并且通過代碼重構(gòu)，將客戶端項目分成幾個獨立的倉庫，可以讓業(yè)務(wù)獨立開發(fā)的同時，也能通過構(gòu)建腳本輕松的整合成一個完成的 app。 服務(wù)端的選型則比較錯誤，當(dāng)時考慮到滴滴的業(yè)務(wù)模式非常類似于 erlang 的 actor 模型，一個叫車流程會涉及到非常多可復(fù)用的 actor，如果我們直接實現(xiàn)一個分布式的 actor 模型和數(shù)據(jù)流管理機制，那么很多問題就迎刃而解了。可是當(dāng)時并不存在一套這樣的機制，我們自己在實現(xiàn)的時候采用 Go + kafka 分別實現(xiàn) actor 和數(shù)據(jù)流存儲，過程中遇到了 kafka 消息丟失不好定位、actor 模型過于抽象不容易在整個團隊貫徹執(zhí)行等問題，最終放棄了整個方案。 技術(shù)選型關(guān)鍵需要思考三個角度：技術(shù)、業(yè)務(wù)和人。 技術(shù)選型首先考慮的當(dāng)然是技術(shù)本身，這里提到的技術(shù)包括語言、框架、工具、設(shè)計模式、開發(fā)模式等。 在選擇技術(shù)時有兩個大原則。第一，要取其長避其短；第二，要關(guān)注技術(shù)的發(fā)展前景。 每種技術(shù)都是有它特定的適用場景的，“沒有銀彈”。開發(fā)者經(jīng)常犯的錯誤就是盲目追新，當(dāng)一個新語言、框架、工具出現(xiàn)后，特別是開發(fā)者自己學(xué)會了這種新技術(shù)后，就會有種“拿著錘子找釘子”的感覺，將新技術(shù)濫用于各種項目。 比如最近幾年 Go 在國內(nèi)很火，我自己也非常使用它開發(fā)項目，但絕對不應(yīng)該將它用于所有項目。Go 的優(yōu)點是上手快、運行時性能高、方便的使用多核運算能力等，經(jīng)常被提起的特性是超輕線程 goroutine、內(nèi)置的內(nèi)存隊列 chan、極快的編譯速度，非常適合于編寫各種無狀態(tài)應(yīng)用服務(wù)，無需使用任何的第三方框架都能輕松寫出一個高性能的 http 服務(wù)。 但它的缺點也非常明顯，最痛的一點是 gc。Go 在設(shè)計之初就號稱要實現(xiàn)一個世界上最優(yōu)秀的 gc，可惜直到今天也還差的較遠，最近一年才實現(xiàn)了 jvm 幾年前就做到的并發(fā) gc，并且沒有很好的方法解決內(nèi)存碎片和對象過多帶來的性能問題。這些缺陷使得 Go 不太適合做有狀態(tài)服務(wù)，特別不適合做內(nèi)存管理相關(guān)的服務(wù)，在這些場景里面還是 C/C++ 更加可靠。 技術(shù)的發(fā)展前景也是一個重要考慮因素。有些技術(shù)設(shè)計的很好，比如我個人挺喜歡一個叫做 Io 的語言，但我不會把它用于真實項目，因為這個語言缺乏社區(qū)和長期支持，就算設(shè)計理念寫的再好，里面也必然有各種 bug 和不足，如果沒人能夠解決就會帶來嚴(yán)重的問題。技術(shù)的“前景”可以從幾個維度來判斷，有沒有長期規(guī)劃、有沒有持續(xù)投入的人或者社區(qū)、問題解決的速度如何、業(yè)界使用案例及口碑、源碼質(zhì)量。 選擇一個技術(shù)最低限的標(biāo)準(zhǔn)是，技術(shù)的生命周期必須顯著長于項目的生命周期。想象一下，如果項目還沒做完這個技術(shù)就不被維護了，那將是怎樣一種窘境。拿去年很火的 Vue.js 來說，尤大在規(guī)劃、投入和解決問題速度方面都沒有問題，這是這個技術(shù)能火起來的基本保障，再加上設(shè)計優(yōu)雅、源碼確實寫的不錯，它的成功并不偶然?？梢灶A(yù)見，隨著尤大全職開發(fā)這個框架并且社區(qū)貢獻者越來越多，Vue.js 能持續(xù)幾年應(yīng)該問題不大。 滴滴的 web app，比如微信錢包里面的滴滴入口，就在去年年底全面改用 Vue.js 重構(gòu)了一版，我們就是看中了 Vue.js 在移動應(yīng)用開發(fā)中的優(yōu)勢再加上對它的前景有信心。在重構(gòu)前，我們?yōu)榱舜_認(rèn) Vue.js 真的能承擔(dān)如此大任，公共前端團隊在 2016 年花了半年的時間整體梳理和評估了 Vue.js 1.0 和 2.0 的全部源碼，為此還出了一本書，在公司大規(guī)模使用前也在滴滴小巴業(yè)務(wù)和行程分享功能里做了試點，效果非常不錯，最終才真正下定決心廣泛推廣。 技術(shù)的發(fā)展前景是動態(tài)變化的，當(dāng)一個技術(shù)走向了末路，我們也應(yīng)該勇敢的揚棄。拿 jQuery 為例，最開始它是前端開發(fā)的必需品，當(dāng)時很多前端同學(xué)離開了 $ 函數(shù)就不會寫代碼了，它在簡化 DOM 操作、抹平瀏覽器間差異做出了極其重要的貢獻。但是隨著瀏覽器越來越標(biāo)準(zhǔn)和趨同，jQuery 的亮點已經(jīng)不再吸引人，它的插件開發(fā)模式逐步被模塊化開發(fā)給取代，再加上各種歷史包袱，它所適用的項目也會變得越來越少，新項目在選型的時候就不推薦優(yōu)先考慮 jQuery 了。 對于一家大型公司來說，其核心業(yè)務(wù)的技術(shù)選型更需謹(jǐn)慎，看前景時甚至需要考慮技術(shù)的獨立性。依然把 Go 當(dāng)做一個例子，當(dāng)前核心 Go Authors 基本都受雇于 Google，也沒有一個獨立運作的基金會來負(fù)責(zé)語言的長期維護，更沒有一個公開透明的決策機制來決定語言的未來，假如 Google 出于某種原因停止投入或者改變語言的發(fā)展方向，那么這對一家大型公司來說可能會是毀滅性打擊。立志于成為一家千億美元規(guī)模的公司，或者是 Google 的潛在競爭對手，在選擇使用 Go 時就應(yīng)該更加謹(jǐn)慎，不要盲從。 技術(shù)選型必須貼著業(yè)務(wù)來選擇，不同業(yè)務(wù)階段會有不同的選型方式。 處于初創(chuàng)期的業(yè)務(wù)，選型的關(guān)鍵詞是“靈活”。只要一個技術(shù)夠用且開發(fā)效率足夠高，那么就可以選擇它。初創(chuàng)的業(yè)務(wù)往往帶有風(fēng)險性和不確定性，朝令夕改、反復(fù)試錯是常態(tài)，技術(shù)必須適應(yīng)業(yè)務(wù)的節(jié)奏，然后才是其他方面。MongoDB 是一個很好的例子，相比 MySQL，它的數(shù)據(jù)結(jié)構(gòu)靈活多變，相比一般的 KV 存儲，它又具有類似 SQL 的復(fù)雜查詢能力，再加上它內(nèi)置的傻瓜式高可用和水平擴展機制，讓它能夠很好的適應(yīng)初創(chuàng)業(yè)務(wù)對效率的追求。 等業(yè)務(wù)進入穩(wěn)定期，選型的關(guān)鍵詞是“可靠”。技術(shù)始終是業(yè)務(wù)的基石，當(dāng)業(yè)務(wù)穩(wěn)定了技術(shù)不穩(wěn)，那就會成為業(yè)務(wù)的一塊短板，就必須要修正。當(dāng)年 Twitter 放棄 RoR 選擇 Java 系框架，這就是個很好的例子。RoR 以快速開發(fā)著稱，但同時 ruby 的性能非常有限，Twitter 工程團隊針對 ruby 虛擬機做了非常多性能優(yōu)化可是依然不能達到預(yù)期，再加上當(dāng)時的 Twitter 為了提升前端體驗，全面使用模塊化和異步化的方法加載頁面，服務(wù)端已經(jīng)基本不怎么負(fù)責(zé)渲染頁面，而專注于提供各種 RESTful API，RoR 的優(yōu)勢也不太明顯了。 當(dāng)業(yè)務(wù)步入維護期，選型的關(guān)鍵詞是“妥協(xié)”。代碼永遠有變亂的趨勢，一般經(jīng)過一兩年就有必要對代碼來一次大一點的重構(gòu)。在這種時候，必須得正視各種遺留代碼的遷移成本，如果改變技術(shù)選型會帶來遺留代碼重寫，這背后帶來的代價業(yè)務(wù)無法承受，那么我們就不得不考慮在現(xiàn)有技術(shù)選型之上做一些小修小補或者螺旋式上升的重構(gòu)。 正因為技術(shù)選型和業(yè)務(wù)相關(guān)，我們能夠觀察到一些很明顯的現(xiàn)象：新技術(shù)往往被早期創(chuàng)業(yè)團隊或大公司的新興業(yè)務(wù)使用；中大型公司的核心業(yè)務(wù)則更傾向于用一些穩(wěn)定了幾年的技術(shù)；一個公司如果長期使用一種技術(shù)，就會傾向于一直使用下去，甚至連版本都不更新的使用下去。這現(xiàn)象背后都是有道理的。 技術(shù)選型過程中最終影響決策的還是人本身，這里要強調(diào)一下，我說的“人”是指的個人，而不是團隊。 技術(shù)選型的決策流程一定得專制。決策者可以在調(diào)研的時候體恤民情，并把團隊現(xiàn)狀當(dāng)做一個因素考慮進來，但絕對不能采用類似“少數(shù)服從多數(shù)”、“按著大家習(xí)慣來”的方式選型。專制可以使技術(shù)選型更加的客觀，考慮的更加全面，并且使得權(quán)責(zé)統(tǒng)一。 并不是每個人都懂得怎么為項目負(fù)責(zé)，一個基層的開發(fā)人員思考的更多的可能是技術(shù)是否有挑戰(zhàn)、能否做出彩、甚至未來好不好找工作，這些主觀因素可能會給選型帶來災(zāi)難性的后果。專制也使得“螺旋式上升”成為可能，很多時候我們沒法一蹴而就的使用某種技術(shù)，這時候需要有一個領(lǐng)路人，帶著大家堅定的朝一條曲折的路線前進才能獲得成功。 技術(shù)選型也非常依賴于人的能力。選型是一件很難被標(biāo)準(zhǔn)化的過程，選型的決策質(zhì)量跟人的眼界、經(jīng)驗、業(yè)務(wù)敏感度、邏輯性等息息相關(guān)。就我自己來說，我在面臨一個選型問題時首先考慮的是去學(xué)習(xí)，看看公司內(nèi)外類似的問題如何解決的，避免自己閉門造車，然后思考所有的可能性，列舉最核心需要考慮的因素，心里列一個方案優(yōu)劣對比，最后將這些邏輯整理清楚，落地成一個決策。 滴滴在決策客戶端動態(tài)化方向時就是以這樣的方式來進行的，我們將業(yè)界所有可能的方案都拿出來，理解他們的優(yōu)缺點，然后在某次會議上幾個核心同學(xué)在白板上列了一張表格，以考慮的因素為行，可能的方案為列，分別評估各個方案在每種因素里的優(yōu)劣勢，最終確定了一個結(jié)論。我們選擇的路是偏向于客戶端開發(fā)的動態(tài)化方案，在保留所有代碼和工具鏈的前提下做到對開發(fā)者透明的動態(tài)化，這樣能讓整體遷移和維護代價變得最小，當(dāng)然，這條路開發(fā)難度也相當(dāng)大，幸好我們當(dāng)時也找到了最合適的人，我們依然可以在能接受的時間里實現(xiàn)整個方案。 可以看到，要想做好技術(shù)選型還是挺難的，要想做好得有足夠的知識積累和實際踩坑的經(jīng)歷才行。如果一個不太懂得如何選型的新人想學(xué)著做好這件事，那可以先從小項目開始做嘗試，慢慢積累經(jīng)驗。技術(shù)選型對人來說最重要的還是“邏輯性”，每一個決策背后都藏著許多假設(shè)和事實，我們通過不斷挑戰(zhàn)這些背后的東西來逐步成長。 比如在需要使用緩存來加快數(shù)據(jù)訪問速度的場景中，我們可能會很自然的選擇 redis 作為緩存服務(wù)。這看似“直覺”的決策，背后也是由一系列假設(shè)和事實組成?？梢詥栕约阂贿B串問題，看看在具體的場景下這個決策是不是真的正確，例如，緩存服務(wù)有沒有 redis 之外的選項、是否可以在內(nèi)存里直接緩存、redis 是否穩(wěn)定、redis 性能是否滿足需求、數(shù)據(jù)庫訪問速度瓶頸究竟在哪等等問題，很可能最終結(jié)果還是“ 使用 redis 做緩存”這個直觀方案，但正因為有分析的過程，讓我們在下一次做決策可以更迅速、更自信。 技術(shù)選型是個很需要經(jīng)驗的活，得有大量的信息積累和輸入，再根據(jù)具體現(xiàn)實情況輸出一個結(jié)果。我們在選型的時候最忌諱的是臨時抱佛腳、用網(wǎng)上收集一些碎片知識來決策，這是非常危險的，我們得確保自己所有思考都是基于以前的事實，還要弄清楚這些事實背后的假設(shè)，這都需要讓知識內(nèi)化形成經(jīng)驗。 我一直在想，“經(jīng)驗”的本質(zhì)是什么，有什么方法能夠確定自己的經(jīng)驗增長了，而不是不斷在重復(fù)一些很熟悉的東西。我現(xiàn)在的結(jié)論是，經(jīng)驗等于“知識索引”的完備程度。 我們一生中會積累很多的知識，如果把我們的大腦比作數(shù)據(jù)庫的話，那我們一定有一部分腦存儲貢獻給了內(nèi)容的索引，它能幫助我們將關(guān)聯(lián)知識更快的取出來，并且輔助決策。經(jīng)驗增長等同于我們知識索引的增長，意味著我們能輕易的調(diào)動更多的關(guān)聯(lián)知識來做更全面的決策。 要想建立好這個知識索引，我們得保持技術(shù)敏感性和廣度，也就是要做到持續(xù)的信息輸入、內(nèi)化，并發(fā)現(xiàn)信息之間的關(guān)聯(lián)性，建立索引，記下來。說起來容易，做起來還是挺有難度的。 首先難在信息輸入量大，忘記了怎么辦。我們的大腦不是磁盤，不常用的知識就會忘記，忘記了就跟沒看過是一回事。我的經(jīng)驗是一定要對知識進行壓縮，記住的是最關(guān)鍵的細(xì)節(jié)，并且反復(fù)的去回味這個細(xì)節(jié)。 比如我學(xué)習(xí)各種語言的時候就會非常留意一些最有特色的語法特性和應(yīng)用場景，像 C++，我一直記得很早以前看過的細(xì)節(jié)，像編譯器默認(rèn)會生成哪些類方法，默認(rèn)析構(gòu)、拷貝構(gòu)造、operator = 等，默認(rèn)生成的類方法有哪些場景需要顯示禁用，什么時候要在構(gòu)造函數(shù)用 explicit 等，我看這些細(xì)節(jié)已經(jīng)超過十五年的時間了，依然記憶尤新。 看起來好像有點難度，實際上不難，大家想想自己學(xué)過的英文單詞，再怎么樣最常見的幾百個英文單詞還是能清楚的記得含義的，而技術(shù)的知識點其實壓縮之后會遠小于英文單詞的個數(shù)，記憶負(fù)擔(dān)不會有想象中那么大。 然后難在信息更新速度太快，跟不上技術(shù)發(fā)展怎么辦。我學(xué)習(xí)了非常多技術(shù)之后就會發(fā)現(xiàn)這確實是個難解的問題，像前端開發(fā)，每年都會有新的框架和開發(fā)方式出現(xiàn)，ES7 的語法如果不去提前了解，過兩年可能連 Javascript 語法都看不懂了。 我在這個問題上也是有些焦慮的，不過多少還是有應(yīng)對的方式，就是堅持碎片化學(xué)習(xí)，增量更新過時的內(nèi)容，只要形成習(xí)慣也還是能夠慢慢的找到自己的節(jié)奏。如果有些技術(shù)實在細(xì)節(jié)太多，比如 Node.js 這種，我以前曾經(jīng)通讀過源碼，仔細(xì)研究過內(nèi)部設(shè)計，但隨著它不斷發(fā)展現(xiàn)在我也不太敢說對它內(nèi)部有多熟悉，那我會考慮大膽的放棄追新，等著我可能需要用它的時候再統(tǒng)一更新到最新的知識。 最后難在信息究竟如何存入知識索引，知識太零散形成不了體系，建不了索引怎么辦。最入門的做法是看書，看別人是怎么將知識變成一個個章節(jié)的信息。要想掌握建立索引背后的方法論，我的經(jīng)驗是先從兩個相近的技術(shù)開始，找到建索引的感覺，然后再鋪開去學(xué)習(xí)更多知識。有這樣困惑的開發(fā)者往往在學(xué)習(xí)方面有些貪心，覺得自己記性好可以囫圇吞棗式的將知識強行內(nèi)化，這樣做短期可以，長期還是會遺忘，也形成不了經(jīng)驗。 其實技術(shù)知識之間非常像，有很多共性的點可以挖掘。比如客戶端和前端開發(fā)，各個框架在 View 生命周期管理、消息派發(fā)機制等方面非常像，后端開發(fā)則更加的套路化，無論用那種語言，最基本的分布式服務(wù)原理、緩存、隊列、數(shù)據(jù)庫等基礎(chǔ)組件原理，都萬變不離其宗。 如果我們更宏觀的看每個領(lǐng)域，甚至于都能發(fā)現(xiàn)領(lǐng)域之間的知識體系劃分也很類似。作為表現(xiàn)層的前端和客戶端，知識體系都可以分為語言、API、工程化、框架和設(shè)計模式。比如前端的語言包括 HTML、CSS、Javascript 和一些稍小眾的 TypeScript、CoffeeScript 等，API 就是各種標(biāo)準(zhǔn)、接口的使用、能夠?qū)崿F(xiàn)的效果、平臺限制等，工程化就是各種打包工具、代碼轉(zhuǎn)化工具、輔助開發(fā)工具等，框架就是像 Vue、React 等，設(shè)計模式就是像 PWA、redux 等。 相應(yīng)的，剛剛說的這些知識都能找到在 iOS 或 Android 里幾乎對應(yīng)的知識，無非換了一些細(xì)節(jié)，這里我就不繼續(xù)展開了。服務(wù)端也是這樣，知識體系最頂層的部分也很少，具體到細(xì)節(jié)，只是要了解每一個實現(xiàn)背后的優(yōu)劣。 總結(jié)一下，技術(shù)選型依賴于經(jīng)驗，經(jīng)驗又來源于知識索引的建設(shè)，這依賴于平時的總結(jié)和不斷的新知識輸入，技術(shù)是一輩子的事，必須得投入大量時間維持狀態(tài)。學(xué)無止盡，大家一起共勉。 今日薦號
StuQInfoQ推出的IT教育平臺——斯達克學(xué)院（StuQ ） 為技術(shù)人提供系統(tǒng)實戰(zhàn)課程 學(xué)習(xí)微服務(wù)，機器學(xué)習(xí)，iOS開發(fā)最潮流技術(shù) 回復(fù)“課程”獲得熱門課程介紹和優(yōu)惠碼 微信ID:stuq2015 今日薦文點擊下方圖片即可閱讀 
騰訊HTTPS性能優(yōu)化實踐 |
|
|
