切換到新語言始終是一大步,尤其是當您的團隊成員只有一個時有該語言的先前經(jīng)驗?,F(xiàn)在,Stream 的主要編程語言從 Python 切換到了 Go。這篇文章將解釋stream決定放棄 Python 并轉向 Go 的一些原因。
成都服務器托管,成都創(chuàng)新互聯(lián)公司提供包括服務器租用、成都天府聯(lián)通服務器托管、帶寬租用、云主機、機柜租用、主機租用托管、CDN網(wǎng)站加速、申請域名等業(yè)務的一體化完整服務。電話咨詢:18982081108
Go 非???。性能類似于 Java 或 C++。對于用例,Go 通常比 Python 快 40 倍。
對于許多應用程序來說,編程語言只是應用程序和數(shù)據(jù)庫之間的粘合劑。語言本身的性能通常并不重要。然而,Stream 是一個API 提供商,為 700 家公司和超過 5 億最終用戶提供提要和聊天平臺。多年來,我們一直在優(yōu)化 Cassandra、PostgreSQL、Redis 等,但最終,您會達到所使用語言的極限。Python 是一門很棒的語言,但對于序列化/反序列化、排名和聚合等用例,它的性能相當緩慢。我們經(jīng)常遇到性能問題,Cassandra 需要 1 毫秒來檢索數(shù)據(jù),而 Python 會花費接下來的 10 毫秒將其轉換為對象。
看看我如何開始 Go 教程中的一小段 Go 代碼。(這是一個很棒的教程,也是學習 Go 的一個很好的起點。)
如果您是 Go 新手,那么在閱讀那個小代碼片段時不會有太多讓您感到驚訝的事情。它展示了多個賦值、數(shù)據(jù)結構、指針、格式和一個內(nèi)置的 HTTP 庫。當我第一次開始編程時,我一直喜歡使用 Python 更高級的功能。Python 允許您在編寫代碼時獲得相當?shù)膭?chuàng)意。例如,您可以:
這些功能玩起來很有趣,但是,正如大多數(shù)程序員會同意的那樣,在閱讀別人的作品時,它們通常會使代碼更難理解。Go 迫使你堅持基礎。這使得閱讀任何人的代碼并立即了解發(fā)生了什么變得非常容易。 注意:當然,它實際上有多“容易”取決于您的用例。如果你想創(chuàng)建一個基本的 CRUD API,我仍然推薦 Django + DRF或 Rails。
作為一門語言,Go 試圖讓事情變得簡單。它沒有引入許多新概念。重點是創(chuàng)建一種非常快速且易于使用的簡單語言。它唯一具有創(chuàng)新性的領域是 goroutine 和通道。(100% 正確CSP的概念始于 1977 年,所以這項創(chuàng)新更多是對舊思想的一種新方法。)Goroutines 是 Go 的輕量級線程方法,通道是 goroutines 之間通信的首選方式。Goroutines 的創(chuàng)建非常便宜,并且只需要幾 KB 的額外內(nèi)存。因為 Goroutine 非常輕量,所以有可能同時運行數(shù)百甚至數(shù)千個。您可以使用通道在 goroutine 之間進行通信。Go 運行時處理所有復雜性。goroutines 和基于通道的并發(fā)方法使得使用所有可用的 CPU 內(nèi)核和處理并發(fā) IO 變得非常容易——所有這些都不會使開發(fā)復雜化。與 Python/Java 相比,在 goroutine 上運行函數(shù)需要最少的樣板代碼。您只需在函數(shù)調(diào)用前加上關鍵字“go”:
Go 的并發(fā)方法很容易使用。與 Node 相比,這是一種有趣的方法,開發(fā)人員必須密切關注異步代碼的處理方式。Go 中并發(fā)的另一個重要方面是競爭檢測器。這樣可以很容易地確定異步代碼中是否存在任何競爭條件。
我們目前用 Go 編寫的最大的微服務編譯需要 4 秒。與以編譯速度慢而聞名的 Java 和 C++ 等語言相比,Go 的快速編譯時間是一項重大的生產(chǎn)力勝利。我喜歡在程序編譯的時候摸魚,但在我還記得代碼應該做什么的同時完成事情會更好。
首先,讓我們從顯而易見的開始:與 C++ 和 Java 等舊語言相比,Go 開發(fā)人員的數(shù)量并不多。根據(jù)StackOverflow的數(shù)據(jù), 38% 的開發(fā)人員知道 Java, 19.3% 的人知道 C++,只有 4.6% 的人知道 Go。GitHub 數(shù)據(jù)顯示了類似的趨勢:Go 比 Erlang、Scala 和 Elixir 等語言使用更廣泛,但不如 Java 和 C++ 流行。幸運的是,Go 是一種非常簡單易學的語言。它提供了您需要的基本功能,僅此而已。它引入的新概念是“延遲”聲明和內(nèi)置的并發(fā)管理與“goroutines”和通道。(對于純粹主義者來說:Go 并不是第一種實現(xiàn)這些概念的語言,只是第一種使它們流行起來的語言。)任何加入團隊的 Python、Elixir、C++、Scala 或 Java 開發(fā)人員都可以在一個月內(nèi)在 Go 上發(fā)揮作用,因為它的簡單性。與許多其他語言相比,我們發(fā)現(xiàn)組建 Go 開發(fā)人員團隊更容易。如果您在博爾德和阿姆斯特丹等競爭激烈的生態(tài)系統(tǒng)中招聘人員,這是一項重要的優(yōu)勢。
對于我們這樣規(guī)模的團隊(約 20 人)來說,生態(tài)系統(tǒng)很重要。如果您必須重新發(fā)明每一個小功能,您根本無法為您的客戶創(chuàng)造價值。Go 對我們使用的工具有很好的支持。實體庫已經(jīng)可用于 Redis、RabbitMQ、PostgreSQL、模板解析、任務調(diào)度、表達式解析和 RocksDB。與 Rust 或 Elixir 等其他較新的語言相比,Go 的生態(tài)系統(tǒng)是一個重大勝利。它當然不如 Java、Python 或 Node 之類的語言好,但它很可靠,而且對于許多基本需求,你會發(fā)現(xiàn)已經(jīng)有高質(zhì)量的包可用。
Gofmt 是一個很棒的命令行實用程序,內(nèi)置在 Go 編譯器中,用于格式化代碼。就功能而言,它與 Python 的 autopep8 非常相似。我們大多數(shù)人并不真正喜歡爭論制表符與空格。格式的一致性很重要,但實際的格式標準并不那么重要。Gofmt 通過使用一種正式的方式來格式化您的代碼來避免所有這些討論。
Go 對協(xié)議緩沖區(qū)和 gRPC 具有一流的支持。這兩個工具非常適合構建需要通過 RPC 通信的微服務。您只需要編寫一個清單,在其中定義可以進行的 RPC 調(diào)用以及它們采用的參數(shù)。然后從這個清單中自動生成服務器和客戶端代碼。生成的代碼既快速又具有非常小的網(wǎng)絡占用空間并且易于使用。從同一個清單中,您甚至可以為許多不同的語言生成客戶端代碼,例如 C++、Java、Python 和 Ruby。因此,內(nèi)部流量不再有模棱兩可的 REST 端點,您每次都必須編寫幾乎相同的客戶端和服務器代碼。.
Go 沒有像 Rails 用于 Ruby、Django 用于 Python 或 Laravel 用于 PHP 那樣的單一主導框架。這是 Go 社區(qū)內(nèi)激烈爭論的話題,因為許多人主張你不應該一開始就使用框架。我完全同意這對于某些用例是正確的。但是,如果有人想構建一個簡單的 CRUD API,他們將更容易使用 Django/DJRF、Rails Laravel 或Phoenix。對于 Stream 的用例,我們更喜歡不使用框架。然而,對于許多希望提供簡單 CRUD API 的新項目來說,缺乏主導框架將是一個嚴重的劣勢。
Go 通過簡單地從函數(shù)返回錯誤并期望調(diào)用代碼來處理錯誤(或?qū)⑵浞祷氐秸{(diào)用堆棧)來處理錯誤。雖然這種方法有效,但很容易失去問題的范圍,以確保您可以向用戶提供有意義的錯誤。錯誤包通過允許您向錯誤添加上下文和堆棧跟蹤來解決此問題。另一個問題是很容易忘記處理錯誤。像 errcheck 和 megacheck 這樣的靜態(tài)分析工具可以方便地避免犯這些錯誤。雖然這些變通辦法效果很好,但感覺不太對勁。您希望該語言支持正確的錯誤處理。
Go 的包管理絕不是完美的。默認情況下,它無法指定特定版本的依賴項,也無法創(chuàng)建可重現(xiàn)的構建。Python、Node 和 Ruby 都有更好的包管理系統(tǒng)。但是,使用正確的工具,Go 的包管理工作得很好。您可以使用Dep來管理您的依賴項,以允許指定和固定版本。除此之外,我們還貢獻了一個名為的開源工具VirtualGo,它可以更輕松地處理用 Go 編寫的多個項目。
我們進行的一個有趣的實驗是在 Python 中使用我們的排名提要功能并在 Go 中重寫它??纯催@個排名方法的例子:
Python 和 Go 代碼都需要執(zhí)行以下操作來支持這種排名方法:
開發(fā) Python 版本的排名代碼大約花了 3 天時間。這包括編寫代碼、單元測試和文檔。接下來,我們花了大約 2 周的時間優(yōu)化代碼。其中一項優(yōu)化是將分數(shù)表達式 (simple_gauss(time)*popularity) 轉換為抽象語法樹. 我們還實現(xiàn)了緩存邏輯,可以在未來的特定時間預先計算分數(shù)。相比之下,開發(fā)此代碼的 Go 版本大約需要 4 天時間。性能不需要任何進一步的優(yōu)化。因此,雖然 Python 的最初開發(fā)速度更快,但基于 Go 的版本最終需要我們團隊的工作量大大減少。另外一個好處是,Go 代碼的執(zhí)行速度比我們高度優(yōu)化的 Python 代碼快大約 40 倍。現(xiàn)在,這只是我們通過切換到 Go 體驗到的性能提升的一個示例。
與 Python 相比,我們系統(tǒng)的其他一些組件在 Go 中構建所需的時間要多得多。作為一個總體趨勢,我們看到 開發(fā) Go 代碼需要更多的努力。但是,我們花更少的時間 優(yōu)化 代碼以提高性能。
我們評估的另一種語言是Elixir.。Elixir 建立在 Erlang 虛擬機之上。這是一種迷人的語言,我們之所以考慮它,是因為我們的一名團隊成員在 Erlang 方面擁有豐富的經(jīng)驗。對于我們的用例,我們注意到 Go 的原始性能要好得多。Go 和 Elixir 都可以很好地服務數(shù)千個并發(fā)請求。但是,如果您查看單個請求的性能,Go 對于我們的用例來說要快得多。我們選擇 Go 而不是 Elixir 的另一個原因是生態(tài)系統(tǒng)。對于我們需要的組件,Go 有更成熟的庫,而在許多情況下,Elixir 庫還沒有準備好用于生產(chǎn)環(huán)境。培訓/尋找開發(fā)人員使用 Elixir 也更加困難。這些原因使天平向 Go 傾斜。Elixir 的 Phoenix 框架看起來很棒,絕對值得一看。
Go 是一種非常高性能的語言,對并發(fā)有很好的支持。它幾乎與 C++ 和 Java 等語言一樣快。雖然與 Python 或 Ruby 相比,使用 Go 構建東西確實需要更多時間,但您將節(jié)省大量用于優(yōu)化代碼的時間。我們在Stream有一個小型開發(fā)團隊,為超過 5 億最終用戶提供動力和聊天。Go 結合了 強大的生態(tài)系統(tǒng) 、新開發(fā)人員的 輕松入門、快速的性能 、對并發(fā)的 可靠支持和高效的編程環(huán)境 ,使其成為一個不錯的選擇。Stream 仍然在我們的儀表板、站點和機器學習中利用 Python 來提供個性化的訂閱源. 我們不會很快與 Python 說再見,但今后所有性能密集型代碼都將使用 Go 編寫。我們新的聊天 API也完全用 Go 編寫。
從收到飛書的面試通知的興奮期待,到收到面試失敗的沮喪,短短一周而已。
剛收到hr的面試通知時,內(nèi)心挺激動的,終于摸到大廠的門檻了。多少年過去了,一直在小廠里掙扎,沒感受過大廠的光環(huán)。于是開始了短暫的面試準備。
首先,去網(wǎng)上搜一下面試經(jīng)歷,初步看了下面試過程和問題,了解面試難度和范圍。發(fā)現(xiàn)他們家面試對算法尤為看重,然后了解到面試的難度不小,會問得很深。然后,找了一些更全面的面試準備材料。
接下來開始正式準備,分為三個方向,一是加強算法練習,二是技術面問題準備,三是對項目進行梳理。每天晚上下班之后,固定到leetcode上刷一道算法題。每天空余時間,都看下常見面試問題集合,進行技術復習。上班的路上回想自己做過的項目,梳理項目的技術點、難點、背景,深入挖掘項目的價值。
就這樣過了一周的時間,到了要趕鴨子上架的時候。面試時間約了晚上8點,我7點從公司走路回宿舍,花了40分鐘終于趕到。沒吃上一口飯,馬上打開電腦,準備好面試環(huán)境,還剩8分鐘,面試官還沒上線。我去拿了一瓶牛奶將就對付一下肚子。
8點一到,面試官準時上線,是個年輕的小伙子,沒有禿頭,也沒有白頭發(fā)。一看就是技術宅的那種。進入面試環(huán)境,老套路,先自我介紹。這部分我之前有稍微準備了一點,避免一上場就腦袋空白。介紹了教育、工作、項目、技術方面的內(nèi)容。然后面試官開始問題問題了。
問題一:介紹項目中如何做接口優(yōu)化的。這塊我印象比較深刻,所以回答的思路比較清晰。
問題二:使用緩存有哪些問題?說了緩存一致性和緩存穿透問題,并給出了解決方案。
問題三:緩存寫滿了,這時如何處理。給了好幾種解決方案,并講解了優(yōu)缺點。
問題四:秒殺場景下,寫緩存失敗如何處理。這個當時回答有誤,和面試官討論之后,改正了思路。
問題五:對于HTTP和HTTPS的認識。談了HTTP的發(fā)展過程,以及HTTPS和HTTP的區(qū)別。
問題六:HTTPS如何做到安全,講了大體思路,在描述TLS加密時卡殼了,這塊了解地不深。
問題七:開始算法了,求解二叉樹兩個節(jié)點的最近祖先。給了求解思路,探討了時間復時間度和空間復雜度。
然后面試結束了,問我的意愿,我說我想做網(wǎng)絡方面的業(yè)務,想做java大方向。面試官說他們用的語言是GO,然后我知道要涼了。
過了兩天,果不其然,收到面試失敗的通知。
這次面試給我的感覺其實不錯的,有點可惜,還是沒有邁進大廠。不過這次面試,讓我學到了一些東西。技術是需要時間沉淀的,項目一定要重視,面試一定會通過項目了解個人的思維、技術、性格等等方面。大處著眼,小處著手,切忌眼高手低。
好了,最后自我安慰下,不忘初心,方得始終。
這個問題說來話長,我先表達一下我的觀點,Go語言從語法層面提供區(qū)分錯誤和異常的機制是很好的做法,比自己用單個返回值做值判斷要方便很多。
上面看到很多知乎大牛把異常和錯誤混在一起說,有認為Go沒有異常機制的,有認為Go純粹只有異常機制的,我覺得這些觀點都太片面了。
具體對于錯誤和異常的討論,我轉發(fā)一下前陣子寫的一篇日志拋磚引玉吧。
============================
最近連續(xù)遇到朋友問我項目里錯誤和異常管理的事情,之前也多次跟團隊強調(diào)過錯誤和異常管理的一些概念,所以趁今天有動力就趕緊寫一篇Go語言項目錯誤和異常管理的經(jīng)驗分享。
首先我們要理清:什么是錯誤、什么是異常、為什么需要管理。然后才是怎樣管理。
錯誤和異常從語言機制上面講,就是error和panic的區(qū)別,放到別的語言也一樣,別的語言沒有error類型,但是有錯誤碼之類的,沒有panic,但是有throw之類的。
在語言層面它們是兩種概念,導致的是兩種不同的結果。如果程序遇到錯誤不處理,那么可能進一步的產(chǎn)生業(yè)務上的錯誤,比如給用戶多扣錢了,或者進一步產(chǎn)生了異常;如果程序遇到異常不處理,那么結果就是進程異常退出。
在項目里面是不是應該處理所有的錯誤情況和捕捉所有的異常呢?我只能說,你可以這么做,但是估計效果不會太好。我的理由是:
如果所有東西都處理和記錄,那么重要信息可能被淹沒在信息的海洋里。
不應該處理的錯誤被處理了,很容易導出BUG暴露不出來,直到出現(xiàn)更嚴重錯誤的時候才暴露出問題,到時候排查就很困難了,因為已經(jīng)不是錯誤的第一現(xiàn)場。
所以錯誤和異常最好能按一定的規(guī)則進行分類和管理,在第一時間能暴露錯誤和還原現(xiàn)場。
對于錯誤處理,Erlang有一個很好的概念叫速錯,就是有錯誤第一時間暴露它。我們的項目從Erlang到Go一直是沿用這一設計原則。但是應用這個原則的前提是先得區(qū)分錯誤和異常這兩個概念。
錯誤和異常上面已經(jīng)提到了,從語言機制層面比較容易區(qū)分它們,但是語言取決于人為,什么情況下用錯誤表達,什么情況下用異常表達,就得有一套規(guī)則,否則很容易出現(xiàn)全部靠異常來做錯誤處理的情況,似乎Java項目特別容易出現(xiàn)這樣的設計。
這里我先假想有這樣一個業(yè)務:游戲玩家通過購買按鈕,用銅錢購買寶石。
在實現(xiàn)這個業(yè)務的時候,程序邏輯會進一步分化成客戶端邏輯和服務端邏輯,客戶端邏輯又進一步因為設計方式的不同分化成兩種結構:胖客戶端結構、瘦客戶端結構。
胖客戶端結構,有更多的本地數(shù)據(jù)和懂得更多的業(yè)務邏輯,所以在胖客戶端結構的應用中,以上的業(yè)務會實現(xiàn)成這樣:客戶端檢查緩存中的銅錢數(shù)量,銅錢數(shù)量足夠的時候購買按鈕為可用的亮起狀態(tài),用戶點擊購買按鈕后客戶端發(fā)送購買請求到服務端;服務端收到請求后校驗用戶的銅錢數(shù)量,如果銅錢數(shù)量不足就拋出異常,終止請求過程并斷開客戶端的連接,如果銅錢數(shù)量足夠就進一步完成寶石購買過程,這里不繼續(xù)描述正常過程。
因為正常的客戶端是有一步數(shù)據(jù)校驗的過程的,所以當服務端收到不合理的請求(銅錢不足以購買寶石)時,拋出異常比返回錯誤更為合理,因為這個請求只可能來自兩種客戶端:外掛或者有BUG的客戶端。如果不通過拋出異常來終止業(yè)務過程和斷開客戶端連接,那么程序的錯誤就很難被第一時間發(fā)現(xiàn),攻擊行為也很難被發(fā)現(xiàn)。
我們再回頭看瘦客戶端結構的設計,瘦客戶端不會存有太多狀態(tài)數(shù)據(jù)和用戶數(shù)據(jù)也不清楚業(yè)務邏輯,所以客戶端的設計會是這樣:用戶點擊購買按鈕,客戶端發(fā)送購買請求;服務端收到請求后檢查銅錢數(shù)量,數(shù)量不足就返回數(shù)量不足的錯誤碼,數(shù)量足夠就繼續(xù)完成業(yè)務并返回成功信息;客戶端收到服務端的處理結果后,在界面上做出反映。
在這種結構下,銅錢不足就變成了業(yè)務邏輯范圍內(nèi)的一種失敗情況,但不能提升為異常,否則銅錢不足的用戶一點購買按鈕都會出錯掉線。
所以,異常和錯誤在不同程序結構下是互相轉換的,我們沒辦法一句話的給所有類型所有結構的程序一個統(tǒng)一的異常和錯誤分類規(guī)則。
但是,異常和錯誤的分類是有跡可循的。比如上面提到的痩客戶端結構,銅錢不足是業(yè)務邏輯范圍內(nèi)的一種失敗情況,它屬于業(yè)務錯誤,再比如程序邏輯上嘗試請求某個URL,最多三次,重試三次的過程中請求失敗是錯誤,重試到第三次,失敗就被提升為異常了。
所以我們可以這樣來歸類異常和錯誤:不會終止程序邏輯運行的歸類為錯誤,會終止程序邏輯運行的歸類為異常。
因為錯誤不會終止邏輯運行,所以錯誤是邏輯的一部分,比如上面提到的瘦客戶端結構,銅錢不足的錯誤就是業(yè)務邏輯處理過程中需要考慮和處理的一個邏輯分支。而異常就是那些不應該出現(xiàn)在業(yè)務邏輯中的東西,比如上面提到的胖客戶端結構,銅錢不足已經(jīng)不是業(yè)務邏輯需要考慮的一部分了,所以它應該是一個異常。
錯誤和異常的分類需要通過一定的思維訓練來強化分類能力,就類似于面向?qū)ο蟮脑O計方式一樣的,技術實現(xiàn)就擺在那邊,但是要用好需要不斷的思維訓練不斷的歸類和總結,以上提到的歸類方式希望可以作為一個參考,期待大家能發(fā)現(xiàn)更多更有效的歸類方式。
接下來我們講一下速錯和Go語言里面怎么做到速錯。
速錯我最早接觸是在做的時候就體驗到的,當然跟Erlang的速錯不完全一致,那時候也沒有那么高大上的一個名字,但是對待異常的理念是一樣的。
在.NET項目開發(fā)的時候,有經(jīng)驗的程序員都應該知道,不能隨便re-throw,就是catch錯誤再拋出,原因是異常的第一現(xiàn)場會被破壞,堆棧跟蹤信息會丟失,因為外部最后拿到異常的堆棧跟蹤信息,是最后那次throw的異常的堆棧跟蹤信息;其次,不能隨便try catch,隨便catch很容易導出異常暴露不出來,升級為更嚴重的業(yè)務漏洞。
到了Erlang時期,大家學到了速錯概念,簡單來講就是:讓它掛。只有掛了你才會第一時間知道錯誤,但是Erlang的掛,只是Erlang進程的異常退出,不會導致整個Erlang節(jié)點退出,所以它掛的影響層面比較低。
在Go語言項目中,雖然有類似Erlang進程的Goroutine,但是Goroutine如果panic了,并且沒有recover,那么整個Go進程就會異常退出。所以我們在Go語言項目中要應用速錯的設計理念,就要對Goroutine做一定的管理。
在我們的游戲服務端項目中,我把Goroutine按掛掉后的結果分為兩類:1、掛掉后不影響其他業(yè)務或功能的;2、掛掉后業(yè)務就無法正常進行的。
第一類Goroutine典型的有:處理各個玩家請求的Goroutine,因為每個玩家連接各自有一個Goroutine,所以掛掉了只會影響單個玩家,不會影響整體業(yè)務進行。
第二類Goroutine典型的有:數(shù)據(jù)庫同步用的Goroutine,如果它掛了,數(shù)據(jù)就無法同步到數(shù)據(jù)庫,游戲如果繼續(xù)運行下去只會導致數(shù)據(jù)回檔,還不如讓整個游戲都異常退出。
這樣一分類,就可以比較清楚哪些Goroutine該做recover處理,哪些不該做recover處理了。
那么在做recover處理時,要怎樣才能盡量保留第一現(xiàn)場來幫組開發(fā)者排查問題原因呢?我們項目中通常是會在最外層的recover中把錯誤和堆棧跟蹤信息記進日志,同時把關鍵的業(yè)務信息,比如:用戶ID、來源IP、請求數(shù)據(jù)等也一起記錄進去。
為此,我們還特地設計了一個庫,用來格式化輸出堆棧跟蹤信息和對象信息,項目地址:funny/debug · GitHub
通篇寫下來發(fā)現(xiàn)比我預期的長很多,所以這里我做一下歸納總結,幫組大家理解這篇文章所要表達的:
錯誤和異常需要分類和管理,不能一概而論
錯誤和異常的分類可以以是否終止業(yè)務過程作為標準
錯誤是業(yè)務過程的一部分,異常不是
不要隨便捕獲異常,更不要隨便捕獲再重新拋出異常
Go語言項目需要把Goroutine分為兩類,區(qū)別處理異常
在捕獲到異常時,需要盡可能的保留第一現(xiàn)場的關鍵數(shù)據(jù)
以上僅為一家之言,拋磚引玉,希望對大家有所幫助。
我是有web開發(fā)經(jīng)驗,但是完全不懂go語言,算是0基礎吧,感覺學起來還行。平時是在慕課網(wǎng)看GO開發(fā)工程師體系課,先從簡單的語言基礎學,然后會涉及全棧項目、微服務、分布式,從安排上看挺貼合企業(yè)實際生產(chǎn),總體感覺還算可以。
文章標題:go語言面試項目經(jīng)驗,Go語言面試題
本文網(wǎng)址:http://jinyejixie.com/article42/hopohc.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供企業(yè)建站、軟件開發(fā)、手機網(wǎng)站建設、網(wǎng)站設計、企業(yè)網(wǎng)站制作、虛擬主機
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)