development

這篇文章是關於Go語言的新系列開始。 Go是一種令人驚嘆、簡單、現代且快速的程式語言。 它是編譯型的、開源的、強類型的。 它是由Google工程師創建的，目標如下： 讓他們的專案編譯（和運行）更快 簡單易懂，人們可以在很短的時間內上手 具有足夠的低級功能，但也避免了一些過於低級的問題 可攜性強（編譯的Go程序是二進位文件，不需要其他文件來運行，並且跨平台，因此可以輕鬆分發） 乏味、穩定、可預測，提供少量犯錯的機會 方便利用多處理器系統的優點 它旨在成為C和C++的替代品。 此外，由於其兼容性特性，它可以與C和C++代碼庫一起使用。 Go可用於許多不同的需求，既可以解決簡單的需求，也可以解決非常複雜的需求。 您可以創建命令行工具、網路伺服器，並且在許多不同的情境中被廣泛使用。 Docker和Kubernetes都是使用Go編寫的。 我最喜歡的靜態網站生成器（Hugo）是用Go編寫的。 Caddy，一個相當流行的網頁伺服器，也是用Go編寫的。 有很多不同的常用工具在底層使用這個程式語言。 本手冊將向您介紹這個程式語言。 在我們深入研究語言的具體細節之前，以下是您應該知道的一些事項。 首先，https://go.dev是這個程式語言的主頁。這將成為您的首選資源： 從https://go.dev/doc/install下載Go二進制文件（go命令和其他相關工具） 參考官方Go文檔https://go.dev/doc/ 查看所有Go封包https://pkg.go.dev/ 訪問Go Playgroundhttps://go.dev/play/ …等等 前往https://go.dev/doc/install，並下載適合您操作系統的套件。 運行安裝程式，在流程結束時，您將在終端機中可以使用go命令： 打開終端機，運行go version，您應該看到類似於這樣的內容： 注意：在運行該程式之前，您可能需要打開一個新的終端機，因為安裝程式將Go二進制文件夾添加到了路徑中。 Go安裝文件的具體位置取決於您的操作系統。 在macOS中，它位於/usr/local/go，並且二進制文件位於/usr/local/go/bin。 在Windows上，它將位於C:\Program Files\go。 Windows和Mac的安裝程式將自動設置Go二進制文件路徑。 在macOS上，您還可以通過使用brew install golang通過Homebrew安裝Go。這樣將更容易進行後續的更新。 在Linux上，您需要在解壓縮Linux套件到/usr/local/go之後，將Go二進制文件夾添加到終端機路徑中，具體方法如下： echo 'export PATH=$PATH:/usr/local/go/bin' >> $HOME/.profile source $HOME/.profile 我推薦使用VS Code（又稱VS Code）作為您的編輯器。 閱讀有關**在VS Code中使用Go**的指南，快速進行“上手”設置。至少安裝Go擴展。 這個擴展將為您提供更簡單的生活，它提供IntelliSense（語法高亮顯示、自動完成、懸停提示、錯誤突出顯示…）和其他功能，如自動格式化、安裝封包的菜單選項、測試等等。 我建議您在VS Code設置中啟用“在保存時格式化”和“在粘貼時格式化”功能： 在Go中，注釋使用了通常的C/C++/JavaScript/Java語法： // 這是單行注釋 /* 多行 注釋 */ 該語言沒有語義上重要的空格。與C、C++、Rust、Java、JavaScript一樣，不同於Python，其中空格具有意義，用於創建塊而不是花括號。 分號是可選的，就像JavaScript一樣。而不像C、C++、Rust或Java。 Go對縮排和視覺順序非常重視。 當我們安裝Go時，還可以使用gofmt命令行工具來格式化Go程序。VS Code在幕後使用該工具來格式化Go源文件。 這非常有趣和創新，因為格式化和類似“應該將花括號放在循環定義的同一行還是下一行”的問題是一個巨大的浪費時間的問題。 語言創建者定義了規則，每個人都使用這些規則。...

VS Code（VSCode）是一個功能強大，越來越受歡迎的編輯器。了解VS Code為什麼受歡迎，以及開發人員的主要功能。 介紹 應該轉用VS Code嗎？為什麼？ 入門 資源管理器 搜尋 原始碼控制 調試器 擴充功能 終端 命令面板 主題 自定義 其他配置選項 最適合編碼的字體 工作區 編輯 IntelliSense 代碼格式化 錯誤和警告 鍵盤快捷鍵 鍵盤映射 代碼段 擴充功能展示 VS Code命令行界面 解決高CPU使用問題 介紹 從一開始，編輯器就是一個奇特的存在。一些人會竭力捍衛他們選擇的編輯器。在Unix世界中，你會遇到諸如“Emacs vs vi”之類的爭論，而我對於為什麼要花這麼多時間討論一個編輯器的優點和缺點感到好奇。 在過去的幾年中，我使用過很多編輯器和集成開發環境（IDE）。我還記得TextMate，TextWrangler，Espresso，BBEdit，XCode，Coda，Brackets，Sublime Text，Atom，vim和PHPStorm。IDE和編輯器之間的區別主要在於功能集和複雜性。 相對於IDE，我更喜歡使用編輯器，因為它更快速且不會妨礙工作。在過去的12個月中，我一直在使用VS Code，這是微軟開源的編輯器，它迅速成為我最喜歡的編輯器。 應該轉用VS Code嗎？為什麼？ 如果你想知道是否應該使用VS Code，讓我說，是的，你應該從你目前使用的其他編輯器中切換到VS Code。 這個編輯器基於微軟幾十年的編輯器經驗而建立。 該編輯器的代碼完全是開源的，並且使用它無需支付費用。 它使用Electron作為基礎，使其能夠跨平台運行在Mac、Windows和Linux上。它使用Node.js構建，並且可以使用JavaScript進行擴展（這對於開發者而言是一個優勝）。 它非常快速，在使用Sublime Text之後，它是我使用過的最快速的編輯器。 它贏得了社區的熱情追捧：有數千個擴展，一些是官方的，一些是由社區製作的，而且它在調查中也名列前茅。 微軟每個月都會發布新版本。頻繁的更新促進創新，微軟正在聆聽用戶的需求，同時保持平台盡可能穩定（在我使用VS Code的一年中，幾乎每天使用它，我從未遇到過任何問題）。 入門 VS Code的主頁是https://code.visualstudio.com/。 訪問該網站下載該編輯器的最新穩定版本。 安裝過程取決於該平台，你應該已經熟悉了。 當你第一次啟動編輯器時，你將看到歡迎畫面： 左側的工具欄上有5個圖標，它們提供： 文件總管 搜索 原始碼控制 調試器 擴充功能 資源管理器 讓我們從資源管理器（播音註）開始探索。 按下側邊欄的“打開文件夾”按鈕，或者在歡迎頁面上點擊“打開文件夾…”鏈接。這兩者都會打開文件選擇器視圖。 選擇一個包含源代碼（甚至只是文本文件）的文件夾，然後打開它。 VS Code將在視圖中顯示該文件夾的內容： 右邊的空視圖顯示了一些快速操作和它們的鍵盤快捷鍵。...

學會如何在Node.js程序中讀取和使用環境變數。 環境變數非常有用，因為我們可以避免在代碼中輸入API密鑰和其他敏感數據，並且將其錯誤地提交到GitHub中。 現代部署平台如Vercel和Netlify（以及其他平台）都有方法讓我們通過它們的界面添加環境變數。 Node.js的process核心模塊提供了env屬性，該屬性包含了在啟動進程時設置的所有環境變數。 下面是一個示例，訪問了NODE_ENV環境變數，該變數默認設置為development。 注意：process不需要“require”，它會自動可用 process.env.NODE\_ENV // "development" 將其設置為“production”之前，運行腳本將告訴Node這是一個生產環境。 同樣，您可以訪問所設置的任何自定義環境變數。 這裡為API_KEY和API_SECRET設置了2個變量。 API\_KEY=123123 API\_SECRET=456456 node app.js 我們可以通過以下方式在Node.js中獲取它們。 process.env.API\_KEY // "123123" process.env.API\_SECRET // "456456" 您可以將環境變數寫入.env文件（應將其添加到.gitignore中以防止提交到GitHub），然後運行以下命令。 npm install dotenv 在您的主要Node文件的開頭，添加以下代碼。 require('dotenv').config() 通過這種方式，您可以避免在node命令之前在命令行中列出環境變數，這些變數將自動被應用程序使用。 注意：某些工具，例如Next.js，會自動將在.env中定義的環境變數提供給程序，而不需要使用dotenv。

當你想要建立一個新應用程式時，你有兩個選擇。 第一個選擇是使用你已經熟悉的技術來建立。如果你熟悉 React，那就繼續使用 React。 另一個選擇是選擇全新的技術堆疊。如果你熟悉 React，你可能會選擇使用 Svelte 或 Vue.js。如果你熟悉 Swift，你可能會選擇使用 React Native。 這是一個困難的問題，因為作為一個開發者，我認為我們應該平衡對某個技術的深入了解，成為該技術的專家，以及對各種技術都有一定的了解。 如果你所有的應用都使用 React，你就永遠不會知道 Vue.js 的優勢。相反的情況也是如此。 當 Twitter 或 Reddit 上出現關於 Vue vs React（或其他任何東西）的「在線戰爭」時，大多數時候，一方的支持者對另一方並不是非常了解，只是根據其他人的話來進行討論。 但在選擇技術堆疊之前，很少有時間能夠探索所有選項。 通常情況下，我可能會堅持使用我最熟悉的技術堆疊，目前恰好是 React 和 Next.js，除非我確定或認為其他技術是最佳選擇。三年後，我的默認選擇可能完全不同。我並沒有對工具產生依賴，我不是一個 React 開發者。我只是一個碰巧是軟體工程師的人，碰巧經常使用 React。 很久以前，我非常深入地研究了一個技術堆疊，然後一個新的項目出現了，其中使用 Node.js 或許是更好的選擇。我們作為一個團隊決定全力支持 Node.js，儘管我們遇到了很多未知的問題，但我認為這是一個不錯的選擇。 每次切換到新的技術堆疊時，你知道你正在放棄什麼，但你不知道你真正要面對什麼。 但這就是你建立專業知識的方式。下一個項目你就會知道這是否是一個好的選擇。只有時間能夠告訴你。