CodeLove 學院 - 免費自學作業包＆新手友善討論區，幫你轉職工程師！

👉 讀技術文章 👉 上自學課程 👉 討論區交流

🔍 搜尋結果：寫測試

使用 Python 和 Pytest 自動化 API 測試

0個讚 0留言 61瀏覽

Tony 精選技術文章翻譯 · 11月13日

最受軟體開發人員推薦的 20 本書

0個讚 0留言 45瀏覽

Tony 精選技術文章翻譯 · 11月11日

初級到資深 Web 開發人員：技能樹說明

原文出處：https://dev.to/aswin2001barath/junior-to-senior-web-developer-roadmap-breakdown-1525 您是初級開發人員，正在努力爬上公司的階梯並成為高級開發人員嗎？您是一名感到迷茫、不知道從哪裡開始的全端開發人員嗎？ 🤔 嗯，您來對地方了！ 😎 這是初級開發人員成為受人尊敬的高級開發人員的逐步路線圖👨‍💻 ### 先決條件 - 基本的 HTML、CSS 和 JavaScript 知識。 - **MERN**（MongoDB、ExpressJS、ReactJS、NodeJS）或 **PERN**（PostgreSQL、ExpressJS、ReactJS、NodeJS）堆疊知識很有幫助，但不是必要的。以下是路線圖中基本技術的細分，您可以在成為高級開發人員的過程中逐步遵循這些技術👨‍💻 ### SSH SSH 在安全遠端通訊中發揮著重要作用。透過熟悉 SSH 基礎知識、其命令、加密方法、SSH 金鑰管理以及將 SSH 應用於實際應用程式，您就可以順利成為高級開發人員。 - **到底什麼是 SSH？** - SSH 是 **S**ecure **Sh**ell 的縮寫，是一種旨在在兩台電腦之間建立安全通訊的協定。（不用擔心這些花哨的術語——協議只是一堆規則，而 SSH 是一種特定類型的協議。） - **SSH 指令**：SSH 的主要用途之一是在遠端電腦上執行指令。這意味著您可以建立與伺服器的連接並使用 SSH 命令與其互動。 - **加密**：要真正掌握 SSH，了解加密等關鍵概念非常重要，其中涉及對稱和非對稱加密技術以及雜湊。這些概念為更深入地理解 SSH 的安全機制奠定了基礎。 - **SSH 金鑰**：SSH 的一個組成部分是使用 SSH 金鑰。這些密鑰由公鑰和私鑰組成。了解如何在伺服器上產生、管理和安全地儲存這些金鑰對於有效使用 SSH 至關重要。 - 練習並測試您的 SSH 技能： - 練習 SSH 技能的一個好方法是將本地電腦連接到 **GitHub** 等平台或 **DigitalOcean** 等雲端供應商。這種實務經驗將有助於鞏固您對 SSH 概念的理解。 - 想像這樣的場景：“您的 Web 應用程式一夜之間神秘地從伺服器上消失。您的任務是使用 SSH 將所有專案檔案恢復到伺服器上。”成功完成此任務可以展示您的 SSH 技能和解決問題的能力。基本上，如果你能做到這一點，那你就太棒了！ ### 表現：效能優化是您成為高級開發人員的關鍵技能。以下技術將幫助您確保應用程式平穩且有效率地執行。透過掌握它們，您將成為性能大師。 **I) 網路優化：** - **最小化檔案**：最小化檔案至關重要，因為較小的檔案會導致更快的載入時間。這不僅可以增強使用者體驗，還可以降低專案的頻寬成本。在網路速度不同的行動裝置造訪網站的時代，這一點尤其重要。 - 1. **檔案壓縮**：較小的檔案意味著使用者的下載速度更快。了解如何使用 GZIP 等檔案壓縮技術來最小化檔案大小，以減少 HTML、CSS 和 JavaScript 等基於文字的檔案的大小。 - 2. **影像最佳化**：透過調整大小、壓縮和選擇正確的影像格式來優化影像可以顯著減小檔案大小。 ImageMagick 等工具或 TinyPNG 等線上服務可以幫助您完成此過程。 - **改善應用程式的交付**：改進的交付可以加快頁面載入時間，這可以直接影響用戶的參與度和保留率。這對於全球可存取性和確保全球用戶獲得一致的體驗也至關重要。 - 1. **內容交付網絡(CDN)**：CDN 是一種分散式伺服器網絡，策略性地位於全球範圍內，用於從地理位置更靠近用戶的伺服器交付Web 內容，例如圖像、腳本和影片，從而更快的加載時間並減少延遲。作為初級開發人員，了解如何利用 CDN 來增強交付。 - 2. **HTTP/2 協定**：HTTP/2 是萬維網使用的 HTTP 網路協定的主要修訂版。它透過同時發送多個檔案並透過多路復用、壓縮和標頭優化等功能實現更快的載入時間來增強網站效能。實作 HTTP/2 協定可以顯著改善交付。 - 練習並測試您的網路優化技能： - 效能測試：初級開發人員可以透過使用 Google 的 PageSpeed Insights、GTmetrix 或 WebPageTest 等工具進行效能測試來進行練習。這些工具評估網站的效能並提供改進建議。 - 真實世界專案：初級開發人員可以透過參與真實世界專案進行練習。從頭開始建立和優化網站或 Web 應用程式可以提供實施網路優化的實務經驗。 **II) 前端優化：** - **關鍵渲染路徑以及如何改進它：** - 了解和優化關鍵渲染路徑對於使您的網站快速加載至關重要。它涉及優化從用戶請求網頁到視覺上完整的事件順序。關鍵面向包括最大限度地減少 CSS 和 JavaScript 等渲染阻塞資源、利用瀏覽器快取以及利用非同步載入技術。 - **漸進式 Web 應用程式 (PWA) 與程式碼最佳化：** - 開發漸進式 Web 應用程式涉及最佳化程式碼以獲得卓越的使用者體驗。 PWA 是一種 Web 應用程式，可提供類似本機應用程式的體驗，具有離線功能、推播通知和快速載入時間等功能。程式碼優化實踐包括高效的快取策略和最大限度地減少 JavaScript 執行，同時確保互動順暢。 - **建立離線就緒的漸進式 Web 應用程式 (PWA)：** - 了解如何開發離線工作的 PWA，甚至使用 JavaScript、HTML 和 CSS 將其提交到應用程式商店。離線功能、快取和響應式設計是確保 PWA 無縫運作（無論使用者的網路連線為何）的重要組成部分。 - **程式碼分割：** - 程式碼分割是一種透過將 JavaScript 分成按需載入的較小套件來增強網站效能的策略。這種做法減少了初始載入時間並改善了整體使用者體驗，尤其是在較慢的網路連線上。 - **React 和 Redux 應用程式的智慧渲染：** - 透過智慧渲染技術提高 React 和 Redux 應用程式的速度。這涉及優化元件渲染和狀態管理，減少不必要的重新渲染，並確保您的應用程式快速響應用戶互動。 - 練習並測試您的知識： - 透過實際改善網站（例如公司登陸頁面）來提升您的技能。實施您在實際專案中學到的效能最佳化，然後測試結果。這種實務經驗對於鞏固您在前端優化方面的專業知識非常寶貴。 **III) 後端優化** 後端優化以及實踐和測試是確保您的應用程式能夠處理不斷增長的用戶群並提供高效、可靠的服務的基礎。 - **內容交付網路 (CDN)：** - 內容交付網絡是分散式伺服器網絡，用於儲存網站內容的快取副本。這些伺服器策略性地分佈在全球各地，允許用戶從地理位置較近的伺服器存取資料。這可以減少延遲、加速內容交付並增強用戶體驗。 - **擴充資料庫：** - 擴展資料庫涉及擴展資料庫的容量和效能以處理增加的資料和流量。技術包括垂直擴展（向單一伺服器加入更多資源）或水平擴展（加入更多伺服器來分配負載），確保您的應用程式在成長時保持回應靈敏且可靠。 - **壓縮來自後端的回應：** - 壓縮來自後端的回應意味著減少從伺服器發送到客戶端的資料大小。 GZIP 壓縮等技術可以顯著減小響應大小，從而縮短載入時間並減少頻寬消耗。 - **快取:** - 快取涉及將經常存取的資料或內容儲存在記憶體或磁碟上，以便更快地檢索。實施快取策略可以縮短回應時間、減少伺服器負載並增強應用程式的整體效能。 - **負載平衡和負載測試：** - 實作負載平衡器對於在多個伺服器之間分配傳入網路流量至關重要。負載平衡可確保沒有任何一台伺服器不堪負荷，從而提高資源利用率並提高可靠性。 - 負載測試模擬現實條件，以辨識效能瓶頸、確保可擴充性並最佳化您的基礎架構。 - 練習並測試您的知識： - 實作負載平衡器。 - 對專案實際執行負載測試。 ### 前端框架與概念前端開發是您成為資深開發人員的基石。熟悉這些概念將為網路開發事業的蓬勃發展鋪路。 - **React 和 Redux**：React 和 Redux 是建立動態單頁應用程式的首選函式庫。首先掌握 React 基礎知識並建立一個專案。然後，深入研究 Redux，了解狀態管理並建立應用程式以實現可擴展性。 - **Webpack4 + Parcel**：Webpack4 和 Parcel 是用於捆綁專案文件和優化生產包的最新工具。獲得使用 Webpack 設定專案的實務經驗。 - 練習並測試你的技能： - 透過使用 React 和 Redux 建立專案來測試您的知識。 - 了解使用 Webpack 設定專案的細節。 ### 測試：測試是一個重要的主題，但也經常被初學者和初級開發人員忘記。公司喜歡測試。因此，如果您知道如何編寫單元測試和整合測試，您將編寫更好的軟體。 - **軟體測試 101：** 了解什麼是測試、測試類型、目前 Web 開發世界中的測試環境、測試工具和函式庫的類型是什麼、如何使用它們以及如何設定一切。 - **Jest**：用於測試的頂級庫之一。學習編寫同步和非同步測試、編寫模擬並產生覆蓋率報告 - **React 測試**：然後深入為您的 React 應用程式編寫測試。學習使用快照測試和酵素來編寫智慧測試，以避免應用程式中出現錯誤。到此結束時，您應該了解整個測試環境，並可以輕鬆地編寫您遇到的任何測試。 ### 打字稿： TypeScript 是目前 Web 開發環境中最熱門的話題之一。 - **靜態類型**：了解靜態類型的基礎知識。了解為什麼 JavaScript 沒有靜態型別而是動態型別。 - **Typescript 101**：了解什麼是 TypeScript、如何使用 TypeScript、有哪些不同類型以及如何將它們新增到您的專案中。 - **React 中的 Typescript**：最終學習如何將 TypeScript 新增到您自己的 React 專案中。再次確保您掌握這些主題。 ### SPA + 伺服器端 - **伺服器端渲染 (SSR)**：透過伺服器端渲染深入研究 Web 渲染的起源。了解為什麼 SSR 在 Web 開發中曾經並且仍然有用。了解為什麼有些公司繼續依賴 SSR 來滿足特定需求。探索 React 中伺服器端渲染的實現，並權衡這種方法的優缺點。 - **客戶端渲染 (CSR)**：深入了解單頁應用程式 (SPA) 中的客戶端渲染。了解企業社會責任的優點和缺點。了解何時選擇客戶端渲染而不是伺服器端渲染。了解如何實作客戶端渲染並評估兩種渲染方法的優缺點。 - **Next.js**：探索 Next.js，這是一個簡化伺服器端動態應用程式所建立的函式庫。了解 Next.js 如何促進伺服器端渲染和互動式資料驅動 Web 應用程式的開發。在本節結束時，您將準備好決定是否需要為您的專案使用單頁應用程式或伺服器端呈現的應用程式。 ### 安全： - **前端安全性最佳化**：學習跨網站腳本和 SQL 注入等註入攻擊。練習這些以了解它們是如何工作的。 - **後端安全優化**：了解有關後端安全的更多資訊以及管理敏感資料的最佳實踐。 - **道德駭客 101**：學習基本的道德駭客技術，以便我們在建立應用程式時能夠學習如何保護自己。因此，在學習這些概念後，當您使用最新的提示和技巧以及實施最新的工具和技術來建立安全應用程式時，您必須充滿信心。 ### 碼頭工人： **Docker** 是一個容器化平台，可讓您將應用程式及其相依性打包到可移植、隔離的容器中。這些容器可以在從開發到生產的不同環境中一致運作。 Docker 是一個絕對會讓你驚嘆不已的工具。 - **容器**： - 首先深入了解容器及其對公司建立和管理應用程式的方式的深遠影響。 - 容器支援輕量級、一致且易於複製的環境，徹底改變了軟體開發和部署。 - **Docker 101**：製作容器 - 透過了解如何建立 Docker 檔案和建立自己的容器來了解 Docker 的基礎知識。 - 這些基礎知識構成了使用 Docker 輕鬆封裝和分發應用程式的基礎。 - **Docker-compose**：編排容器 - 探索 Docker-compose，一個用於編排多容器 Docker 應用程式的工具。 - 了解如何將多個容器作為單一服務進行定義、配置和管理，從而簡化複雜應用程式的部署。 - **微服務與單體架構**： - 在整體架構中，單一大型程式碼庫處理所有應用程式功能，這使得更新和擴展具有挑戰性。 - 容器支援微服務方法，其中應用程式被分為更小的、獨立的服務，可以單獨開發、部署和擴展。這種轉變提供了靈活性、可擴展性並提高了資源利用率。 - 容器（如 Docker）有助於從整體架構轉向微服務。因此，請詳細了解每種架構的優缺點。 - 練習並測試您的 Docker 技能： - 了解如何將 Redis 伺服器、Postgres 資料庫和 API 伺服器全部組合到一個 docker 容器中，以便它們都透過一個命令執行。在本節和操作專案之後，每當我們部署應用程式時，我們都會對 Docker 感到非常滿意。 ### Redis： Redis 是最受歡迎、最常用的資料庫之一，是一種鍵值儲存。 - **資料庫 101**：深入研究資料庫主題，深入了解各種類型的資料庫以及它們如何適應資料儲存解決方案的前景。 - **什麼是 Redis？：** - Redis 是一個開源的記憶體鍵值儲存資料庫。 - 它在資料儲存和檢索方面表現出色，使其成為需要高速資料存取的應用程式的多功能選擇。 - **Redis 101**：學習如何使用 Redis。了解如何使用 Redis 進行快取以使我們的網站更快並進行會話管理。 - **Redis CLI**：了解如何使用 Redis CLI。 - **練習您的 Redis 技能**：啟動我們自己的 Redis 伺服器。 - **鍵值資料庫及其作用：** - 像 Redis 這樣的鍵值資料庫提供了一種簡單而有效的資料儲存方式。 - 它們將資料儲存為鍵和對應值對，從而實現快速資料檢索。 - 這些資料庫在快速資料存取至關重要的場景中尤其有價值，例如快取、會話管理和即時應用程式。 - **何時使用 Redis 等資料庫：** - Redis 非常適合速度和資料一致性至關重要的用例。 - 考慮使用 Redis 來快取經常存取的資料、管理使用者會話、為即時應用程式提供支援以及確保對關鍵資訊的低延遲存取。 ### 會話 + JWT 使用您的 React 專案，了解如何建立網站的整個動態部分：即使用以下技術的使用者管理。 - **會話驗證**：了解如何建立新的個人資料頁面。了解如何使用基於會話的身份驗證（其中將使用 cookie）並了解如何實現它。 - **令牌身份驗證**：了解有關令牌身份驗證（例如 JWT 令牌）的更多資訊。了解每種身份驗證類型的優缺點。 - **安全性身分驗證流程**：了解如何實施可以在您選擇的任何應用程式中實施的安全性身分驗證流程。 - 練習您的 Redis 技能：學習如何使用和實施 Redis 進行會話管理 - 這樣我們就有受保護的路線 - 此外，這樣，只要我們有登入功能，我們就可以使用該系統，因為我們知道它是安全的並且遵循最佳實踐。 ### 亞馬遜網路服務（「AWS」）： Amazon Web Services，通常稱為 **AWS**，是一個強大的雲端平台，它改變了公司的營運方式，提供了無與倫比的可擴展性和效率。 #### AWS 101： - **什麼是 AWS（亞馬遜網路服務）？：** - AWS 是一個雲端運算平台，提供廣泛的服務，包括運算能力、儲存、資料庫、機器學習等。 - 它提供可擴展的按需資源，使企業能夠創新和發展，而無需管理實體基礎設施的負擔。 - **基礎設施即服務 (IaaS)：** - AWS 提供基礎架構即服務，讓使用者透過網際網路配置和管理虛擬化運算資源。 - 這種方法消除了對本地硬體的需求，並提供了靈活性和可擴展性。 - **平台即服務 (PaaS)：** - AWS 將其服務擴展到平台即服務，使開發人員能夠建置、部署和管理應用程式，而無需擔心底層基礎設施。 - 這使開發人員能夠專注於編寫程式碼和交付價值。 - **使用 AWS 進行擴充：** - AWS 使公司能夠有效擴展，並根據需要提供對資源的存取。 - 它允許企業將其能力與需求相匹配，類似於Google、亞馬遜和微軟等科技巨頭，確保他們能夠無縫地為客戶提供服務。 - **AWS Lambda** 是一種無伺服器運算服務，使開發人員能夠執行程式碼來回應事件，而無需管理伺服器。它提供了一種經濟高效、可擴展且簡單的方式來執行雲端中的功能。 - **Serverless 101**：了解如何使用 Serverless 框架。 - 練習您的 AWS 技能：了解如何將 AWS Lambda 實施到您的 React 應用程式中。最後，您將充滿信心地使用 AWS 並建立雲端中的功能。 ###CI/CD 當我們將所有內容聯繫在一起並建立瞭如何編寫優秀軟體和優秀應用程式的整體圖景之後；了解如何實際建立良好的流程以及如何實際將應用程式部署到生產中。 - **持續整合**：了解有關良好持續整合實踐以及如何實施這些良好實踐和良好工具的更多資訊。 - **持續交付**：了解有關良好持續交付實踐以及如何實施這些良好實踐和良好工具的更多資訊。 - **持續部署**：了解有關良好持續部署實踐以及如何實施這些良好實踐和良好工具的更多資訊。 - 練習 CI/CD 技能：了解如何在專案中實施 Circle CI (CI/CD) 工具 - 確保您的開發團隊從一開始就擁有正確的工具和正確的流程 - 成功編寫錯誤更少、程式碼更簡潔的應用程式。 ### 額外位 - **程式碼分析**：了解當您第一次開始一個有大量文件並且不是您自己編寫程式碼的專案時該怎麼做！了解真正優化的提示和技巧。 - **建立高品質應用程式的一般最佳實踐**。 ### 軟技能 - 在本部落格中，我主要關注成為高級開發人員過程中的技術方面。然而，有效溝通和情緒智商等軟技能也發揮著至關重要的作用。 - [開發人員的七大軟技能及其學習方法](https://academy.zerotomastery.io/a/aff_pp6yfnkw/external?affcode=441520_dcwk-s8s)：要更深入地探索各種軟技能，請考慮請參閱資深開發人員兼程式講師Andrei Neagoie 撰寫的部落格。 ### 筆記 - 不同的公司可能對高級 Web 開發人員有不同的期望，因此請務必進行一些額外的研究來客製化您的開發路徑。最後，在學習了上述所有主題之後，所有這些事情對您來說都會有意義。您將能夠將所有這些事情實施到您自己的專案、您自己的公司。您將了解它們中的每一個是如何連接的。最重要的是，與其他需要數年時間學習這些技能的初級開發人員相比，借助本路線圖可以快速學習這些內容。 ### 最佳資源 - [初級到高級 Web 開發人員路線圖部落格系列](https://dev.to/aswin2001barath/series/24357)：一個部落格系列，我將學習並分享上述每個主題的知識。 - [不要成為初級開發人員：從初級到高級的路線圖](https://academy.zerotomastery.io/a/aff_5s8ff6y7/external?affcode=441520_dcwk-s8s)：Andrei Neagoie 的詳細路線圖部落格（a高級開發人員）提供免費資源的連結。 - **零到精通課程**：[完整的初級到高級Web 開發人員路線圖課程](https://academy.zerotomastery.io/a/aff_hpwn5xy9/external?affcode=441520_dcwk-s8s)：Andrei 的綜合課程Neagoie（同一高級開發人員）涵蓋了上述所有主題。 **我是誰？** - 我是 Aswin Barath，軟體工程迷，喜歡建立 Web 應用程式，現在在我自由職業生涯的繁忙時間透過[部落格](https://medium.com/techsoftware) 分享我的知識。 - 我也是像您一樣的初級開發人員，學習如何成為高級開發人員並在過程中分享我的知識。 - 這是我所有社交活動的連結，按平台分類在一個位置：https://linktr.ee/AswinBarath **謝謝** 非常感謝您閱讀我的部落格🙂。

0個讚 0留言 37瀏覽

Tony 精選技術文章翻譯 · 11月10日

2024 年的 React 生態系統

0個讚 0留言 20瀏覽

Tony 精選技術文章翻譯 · 10月24日

React 生態系 2024 年推薦總整理

0個讚 0留言 169瀏覽

Tony 精選技術文章翻譯 · 09月19日

寫單元測試的五個技巧分享

測試程式碼是軟體開發最重要的方面之一，因為它可以確保產品的品質、可擴展性和可靠性。但是，如果沒有任何指導，編寫有效的測試可能會很困難。測試程式碼可能比實際功能的程式碼更複雜、更難維護！原文出處：https://dev.to/one-beyond/the-5-principles-of-unit-testing-1p5f ## 1.精簡和準確的測試測試程式碼必須**簡單且易於使用**。任何查看測試的人都應該立即知道測試的內容及其目的是什麼。開發測試應該以很少的精力和時間投入帶來巨大的價值。 > _您是否需要超過 30 秒的時間來閱讀和理解您的測試？重寫它！_ 測試“覆蓋率”是重點嗎？不！ **僅測試必要的部份就好**。為了敏捷性和簡單性，最好放棄一些測試，**只測試主要業務邏輯和主要邊緣情況就好**。 ## 2.測試行為，而不是元件實作不要檢查程式碼中的每一行和內部變數。測試時，您應該**專注於結果**。即使方法內的程式碼被重構，結果也應該永遠保持不變！這樣，如果程式碼庫發生更改，您**不需要重寫測試**。 ``` // Wrong ❌ - Test behaviour describe('Evaluation Service', () => { describe('Register Students', () => { it('Should add new students to the evaluation service', () => { const studentJosh = { id: 1, name: 'Josh McLovin', average: 6.98, } evaluationService.addStudent(studentJosh) expect(evaluationService._students[0].name).toBe('Josh') expect(evaluationService._students[0].average).toBe(6.98) }) }) }) ``` ``` // Right ✅ - Test behaviour describe('Evaluation Service', () => { describe('Register Students', () => { it('Should add new students to the evaluation service', () => { const studentJosh = { id: 1, name: 'Josh McLovin', average: 6.98, } evaluationService.addStudent(studentJosh) expect(evaluationService.getStudentAverage('Josh')).toBe(6.98) }) }) }) ``` ## 3. 關於命名和結構：AAA 模式您是否曾經遇到過名為“_它應該[...]正確_”的失敗測試，但花了幾分鐘才找到問題所在？良好命名和結構可以讓您快速且準確地找到任何失敗的測試，最終節省您的寶貴時間。因此，讓我們深入探討兩個關鍵原則，以便在下次測試時牢記： ### 3.1 經過深思熟慮的測試命名：在命名您的測試時，請嘗試合併以下資訊： - **正在測試什麼**？ - **什麼情況**？ - **預期結果**是什麼？ ``` // Right ✅ - Test naming // 1. What is being tested: describe('Evaluation Service', () => { describe('Evaluate Students', () => { // 2 & 3. Context and expected result it('If the student grade is below the minimum grade, student should be suspended', () => { const students = [ { name: 'Mark', grade: 4.25 }, { name: 'Colin', grade: 6.7 }, { name: 'Ben', grade: 5.3 }, ] const result = evaluationService.evaluateStudents({ students, minGrade: 5 }) expect(result['Mark']).toBe('suspended') }) }) }) ``` ### 3.2 測試程式碼結構的AAA模式：如果您想維護一個可讀且易於理解的測試套件，請按如下方式建立測試： - **安排**：設定模擬所需情況所需的所有程式碼。這可以包括初始化變數、模擬響應、實例化被測單元等。 - **行為**：執行正在測試的內容，通常在一行程式碼中。 - **斷言**：檢查得到的結果是否為預期的結果。與上面的一樣，這應該只需要一行。 ``` // Right - AAA Testing Pattern describe('Evaluation Service', () => { describe('Average Calculation', () => { it('Should calculate the average grade of all the students', () => { // Arrange: create an object with the student names and their grades const students = [ { name: 'Mark', grade: 4 }, { name: 'Colin', grade: 10 }, { name: 'Ben', grade: 7 }, { name: 'Tim', grade: 3 }, ] // Act: execute the getAverage method const avg = evaluationService.getAverage(students) // Assert: check if the result is the expected one -> (4+10+7+3)/4 = 6 expect(avg).toEqual(6) }) }) }) ``` ##4。確定性和隔離測試如果一個失敗的測試使您的整個套件變紅，那麼您可能沒有以正確的方式處理它！測試應該**獨立和隔離**，一次針對並處理一個特定邏輯，從而完成更快、更穩定的測試套件。 **如果您不**獨立編寫測試會發生什麼？ - 您將無法找出錯誤和問題的**確切原因和位置**。 - 重構測試時，您必須**更新和同步多個測試**。 - 您將無法以任何順序執行測試，這可能會導致**破壞或跳過某些斷言或期望**。 ## 5。基於屬性的測試和真實資料厭倦了在測試中編寫大量可能的輸入？基於屬性的測試可以為您做到這一點！……那是什麼？基於屬性的測試建立了數百種可能的組合，強調了測試並**增加了發現以前未被注意到的錯誤的機會**。這種方法甚至可以傳回可能導致意外結果的輸入。 [JSVerify](https://github.com/jsverify/jsverify) 或 [Fast-Check](https://github.com/dubzzz/fast-check) 等函式庫提供了促進基於屬性的測試的基本工具。但是，如果您不想深入進行如此廣泛的測試，那麼盡可能利用**真實資料**至關重要。像“abc”或“1234”這樣的輸入可能會在實際失敗時錯誤地通過測試。 ``` // Wrong ❌ - False Positive - Test that passes even though it shouldn't class EvaluationService { _students = []; addStudent(student) { // Add the student if the name has no numbers if(!student.name.matches(/^([^0-9]*)$/)){ this._students.push(student); } } } describe('Evaluation Service', () => { describe('Register Students', () => { it('Should add students to the Evaluation service', () => { const mockStudent = { id: 2, name: 'username', average: 7 } // Won't fail because the name is a string without number -> We are not checking what happens if the user // inputs a name with a number. evaluationService.addStudent(mockStudent) expect(evaluationService.getStudentAverage('username')).toBe(7) }) }) }) // In the example above, we are making a test so the test passes, instead of looking for edge cases with realistic data ``` ##額外提示！如果您在測試元件中的任何邏輯時遇到困難，這可能反映出您也許應該將元件邏輯分解為更小、更容易且可測試的程式碼片段！總而言之，遵循此最佳實踐可能會帶來一種新的、可讀且可維護的方法來測試您喜愛的生產程式碼。 > 經過測試的應用程式才是可靠的應用程式！

0個讚 0留言 135瀏覽

Tony 精選技術文章翻譯 · 12月19日

德國資深架構師：給新手工程師的幾點建議

一名資深的德國軟體架構師 Jeroen De Dauw，寫了一篇很好的文章，給新手工程師一些寫程式的建議。 - 原文出處：https://dev.to/jeroendedauw/advice-for-junior-developers-30am --- ## 給新手工程師的一般建議 ### 1. 程式碼不是重點作為開發者，我們喜歡寫程式。大多數工程師希望收到的任務明確，可以不用管技術之外的事情，專心解決有趣的技術挑戰。請花足夠的心力去確認，您正在解決正確的問題。引用管理學大師 Peter Drucker 的話：高效率地去做一件根本沒必要的事情，結果依然是完全沒意義。儘早、經常去搜集回饋，透過「持續交付」來向真正的用戶互動，成為敏捷（Agile）的工程師。軟體開發成本高昂，現實世界專案的絕大部份工作都是在維護而已。再加上目標應該是對用戶、對生意有幫助，所以結論就是：寫程式最好的方法，經常是完全不寫。引用比爾蓋茲的話：用程式碼有幾行來衡量工程進度，就像用重量來衡量飛機的製造進度。另請參閱：YAGNI 原則、KISS 原則、The Last Responsible Moment 文章。 ### 2. 軟體設計很重要在我開發生涯的前五年，我以為軟體設計是架構師或其他特殊職位的人在做的事。我以為開發者專注在完成任務即可，以為軟體設計、最佳實踐、寫測試這些，都不關我的事。我的程式能跑，我的生產力很高，我以為這樣就對了。直到我閱讀了 Robert C. Martin 的 Clean Code，這書刺激了我對軟體設計的關注，並包含許多範例與啟發。其中最啟發我的是：走得快的唯一方法，就是走得好。也就是說，如果你把事情搞得一團糟，結果只會讓你速度更慢。學習寫出設計良好的乾淨程式碼，需要時間和精力。而且剛開始的時候，會寫比較慢，並且會犯錯誤。 ### 3. 使用最佳實踐寫測試通常會有幫助。雖有例外，但大多數時候，寫自動化測試會大有幫助。寫測試就是一種最佳實踐。如果你不太會寫測試，請遵循最佳實踐並為所有內容寫測試。**開始時，盲目遵循最佳實踐比遵循自己弱弱的判斷要好**。一段時間之後，您將知道怎麼寫測試比較有效，並能夠區分您搞砸了和不值得編寫測試的情況。因為 bug 變少了、重構起來更輕鬆了，您將開始理解測試帶來的深入的價值。**到有了自己的判斷力後，您將能夠超越最佳實踐**。此建議適用於您在學習任何最佳實踐的新手時期。自動化測試只是一個例子。有個陷阱要注意，明智的最佳實踐，與荒謬、適得其反的做法之間，只有一線之隔。因為大多數程式碼都很亂，而且大多數開發者（包括資深人員）不了解軟體設計的基礎知識，因此事情就更複雜了。有一個好的指導者很重要。除此之外，根據我自己的經驗，要小心只存在您的語言、框架社群的最佳實踐。尋找那些已經存在了幾十年的長青建議比較好。 --- ## 給新手工程師的技術建議 ### 4. 寫測試寫自動化測試。也許在寫程式之前先寫測試，例如運用測試驅動開發（TDD）。這讓您可以輕鬆反覆驗證幾段程式是否正確，而不用一直手動跑測試、除錯。 > 你覺得先寫測試很煩嗎？但之後再忙著抓 bug 有比較好？更重要的是，測試為您重構時提供了額外保障。你需要持續重構來保持程式乾淨。沒有可靠的測試保障，程式碼就可能越變越亂。如果您的程式碼設計不佳，例如使用繼承進行重用，或使用靜態函數，則編寫測試會很困難。另一方面，如果您有遵循 SOLID 原則、沒有全局依賴項，那麼寫出好的測試並不困難。設計好測試也很重要，因為糟糕的測試只會拖慢開發速度。避免將測試綁定到被測程式碼的實作細節或系統結構。 ### 5. 不要用繼承來做到程式碼重用這是讓人以為是最佳實踐的其中一個反例。我的建議是：剛開始時，根本就不要用繼承來做到程式碼重用。這通常都幫助有限，而且帶來一大堆麻煩。請多用組合、少用繼承（關鍵字：composition over inheritance）。 ### 6. 寫出 OOP 程式碼學習 SOLID 原則，避免寫出 STUPID 原則的程式碼 ( https://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/ )。理解這些原則和反模式非常有價值。創造一些真正的物件。只有靜態方法的類別，根本不算是物件導向。盡量避免完全使用靜態寫法。 ### 7. 寫出函數式程式碼不要把函數式程式設計，跟指令式程式設計搞混了。重點不是完全切換到函數式語言。而是學習使用函數式風格的優點。例如減少狀態、讓函數專心一件事。另請參閱：https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell ### 8. 程式碼稍微重複沒關係將一大塊程式碼到處複製貼上當然很不好。有尊嚴的開發者很快就發現這一點，並開始遵循某種形式的：不重複自己原則 Don't Repeat Yourself （DRY）。不幸的是，對 DRY 的追求往往會導致過度工程和額外的複雜性。所以會有一條新原則：寫兩次原則 Write Everything Twice（WET）。也就是僅在第三次出現重複時，才動手改善重複段落。 ### 9. 型別、命名、註解試著寫一些能夠表達自我的程式碼，避免寫註解。 > 每次寫註解時，都應該要皺一下眉頭，感受到自己的表達能力有點失敗。 —— Robert C. Martin 註解很危險，因為有可能說謊。程式碼可以不更新註解就修改，那一開始的註解就變錯誤了。這種情況下，註解不但沒幫助，還會誤導到別人。要寫出能夠表達自我的程式碼： - **一個函數只做一件事** 因為只做一件事，就能給一個清楚的命名。 - **減少狀態** - **使用型別** 定義清楚的型別，加上跑測試，能讓系統更穩定。 - **減少混合型別** 避免可以同時是整數、布林值或字串的參數或回傳值。如果讓每個函數專心一件事，這自然會做到。 - **寫測試** 良好的全面測試，也同時會是程式碼的使用說明範例。 Robert C. Martin 的書 Clean Code 在命名和寫註解方面有提供一些很好的經驗法則。 --- 以上，希望對大家有幫助！

1個讚 0留言 12,862瀏覽

Tony 精選技術文章翻譯 · 12月02日

軟體工程師：面試的時候，你應該問公司的 36 個重要問題

面試的時候，通常面試官會問：你有什麼問題想問我們嗎？就跟公司面試你一樣，其實你也在面試公司。應該把握機會問對問題。這邊有幾個重要問題，給你參考，下次面試可以問問看。 - 原文出處：https://dev.to/semaphore/36-questions-to-ask-your-future-software-employer-552g --- # 可以問人資的問題面試通常會先跟人資聊聊，有些問題可以先問他們。建議可以問一下公司的運作方式以及面試流程。 ## 關於職位 **1. 公司為什麼要招人？** 這是個暖身問題。可以了解公司的大致狀態。缺人是因為在擴編？還是有人剛離職呢？ **2. 這個職位上一個人怎麼樣了？他們是辭職了，還是被開除？** 如果不是擴編，那可以先搞清楚這職位剛發生什麼事。弄清楚這段，可以更了解公司對這個職位的期望。 **3. 公司的離職率是多少？去年僱用了多少開發人員，又有多少人辭職了？團隊中待最久、跟最新進的人員分別是多久？** 這問題可以嗅出一些端倪。高流動率代表工作條件有點問題。可能得不到直接答覆，但別擔心，後面的流程有機會深入討論。 **4.到職流程如何運作？面試過程的下一步是什麼？** 獲取準備下一步所需的資訊。 ## 關於員工生活 **5. 公司是否投資於員工發展、培訓或認證？是否有用於學習活動或參加研討會的預算？** 公司當然喜歡積極進修的員工。所以員工至少要有一點時間能學習或參加活動。如果他們有提供進修預算，那非常加分。 **6. 公司允許遠端工作嗎？我應該在辦公室待多少天？遠端工作者的比例是多少？** 疫情讓遠端成為常態。有些公司 100% 遠端工作。有些公司則是混合辦公。你需要知道公司是哪種。如果是完全遠端，你要問一下有沒有定期的團建活動，或是聚餐之類的。 **7. 有補助去共享空間工作嗎？** 有些人在家很難專心。這時可以考慮去租共享工作空間。 **8. 有育嬰假嗎？有無薪假嗎？病假和特休等等，怎麼安排？** 如果應徵公告沒有寫清楚，你可以這時先問清楚相關規則。 --- # 技術面試後要問的問題這時你應該在跟技術人員交談。可能是未來的同事、技術主管、或技術長。藉此機會暸解工作環境。有些問題可以防止踩雷。 ## 關於每日作息 **9. 通常我一周開幾次會議？** 會議一定會有，但有些公司實在開太多了。這問題可幫助評估，工作時會不會一直被打斷。 **10. 公司有 CI/CD 嗎？或者其他開發流程呢？** DevOps、Scrum、Lean 和 Agile 等術語已被濫用到沒什麼意義了。CI/CD 的意義清楚多了。公司有實踐嗎？如果沒有，代表團隊依賴手動部署、測試。當然，也有CI/CD不可行的地方。但 99% 的情況下，利大於弊。 **11. 多久部署一次？如何部署？** 關於 CI/CD ，需要知道一天部署幾次。這代表部署流程多順暢。除非是受到政府監管的產業，不然手動、久久部署一次，代表緩慢又低效率的開發文化。 **12. 你們使用 TDD 還是 BDD？如何寫測試？** 測試驅動開發和行為驅動開發對生產力很有幫助。無論是不是在測試團隊，都應該知道一下公司的測試習慣。如果公司完全不寫測試，那就要小心了。 **13. 你們如何追蹤錯誤/問題？寫功能和修理之間的比例是多少？** 這能幫助了解技術債。有技術債是正常的，但如果太多，你可能就一直在救火、整理超亂的程式碼。 **14. 你們偏好哪種：系統穩定或者快速上新功能？你們對技術債的態度是什麼？** 直接問技術債的態度，但也要知道滿足客戶需求的重視程度。 **15. 文件完整嗎？有程式碼風格指南嗎？有現成的測試規格嗎？** 了解一下文件的習慣。可以詢問 API 規範、技術文件、風格指南、用戶故事之類的。文件不夠通常代表你需要一直開會、一直詢問同事。測試本身就是一種文件，所以有寫測試也很重要。 ## 工具和文件 **16. 使用什麼版本控制系統？** 如果沒有在用版本控制，建議直接換別間面試。除非你在面試技術長或者技術副總之類的。這情況，要詢問能否導入。如果能，你需要很痛苦的花幾個月導入，談薪水的時候要一併考慮進去。 **17. 使用什麼技術/語言/框架？** 不熟悉也沒關係。通常幾週內就都能上手。 **18. 我可以使用我 ${最愛的 IDE} 嗎？** 用自己最愛的，最棒。 **19.公司有提供設備嗎？我有設備的全部權限嗎？我可以用自己的設備嗎？** 如果在自己的電腦上沒有根權限，代表公司不信任員工。 ## 開發團隊文化 **20. 你為什麼選擇加入這家公司？** 如果跟面試官聊開了，請問一些個人問題。了解你將要為之工作或與之共事的人的價值觀，是很有價值的。 **21. 團隊有多大？新手與資深工程師的比例是多少？** 試著深入了解團隊組成與規模。如果你是應徵初階職位，同事大部分都是資深人士，那就是好事一件。 **22. 有多少女性員工？公司有確保員工多樣性的流程嗎？** 了解一下團隊都是同一種人、或者具有很高多樣性。這對工作氛圍也有影響。 **23. 你在這家公司犯過的最大錯誤是什麼？** 我喜歡這個問題，因為它與「生成式文化」的概念有關。生成式文化是一種風險共擔、鼓勵創新、人們不會因失敗而受到譴責（而是被用作學習機會）的文化。當人們在心理上感到安全，他們會把握更多機會並進行更多嘗試，從而實現創新。反例則是，病態或官僚文化。在這種情況下，人們傾向於「謹慎行事」——以免因失敗而受到懲罰。這絕對是很差的工作環境，對你的工作跟心情都很不好。 ## 工作與生活的平衡 **24. 人們平均每週工作多少小時？人們通常什麼時候下班？** 你需要每天早點回家、好好享受生活，才能持續打拼。長期過勞代表團隊生產力很差，只能透過加班彌補。 **25. 有 on-call 的時間表嗎？標準工時以及您對加班的期望？我將多久 on-call 一次？緊急情況或人們被迫加班的頻率有多高？** 這個問題是對上一個問題的補充。一個月通常要加班幾次？大量加班、習慣性的周末工作以及不頻繁、手動部署，是工作與生活不平衡的跡象。如果公司有這些危險信號，請繼續貨比三家。 **26. 我是否需要一直在 Slack/Teams 上面，還是可以分批處理我的工作？** 我常常在沒有鍵盤的時候解決問題。常常在散步或洗澡的時候有新想法。能夠離開電腦散步一下，生產力會更好。 --- # 向經理、首席執行長或創辦人提出的問題痛苦的技術面試完成後，你可能會見到經理、首席執行長、甚至創辦人。可以把握機會了解公司在市場上的表現、也能讓公司知道你對公司很有興趣。 ## 關於公司 **27. 有公司運作 SOP 嗎？** 查看各種 SOP 可以知道公司的運作方式，讓新員工快速進入狀況。 **28. 公司是怎麼賺錢的？損益兩平了嗎？成長速度有多快？** 如果在面試新創公司，獲利需要好幾年的時間，而且機率不高。所以，你其實正在賭一個高風險、高報酬的事情。您的專業成長通常會反應到公司的成長。如果你追求穩定並打算待好幾年，那麼選擇一家現金流穩定的老牌公司比較好。 **29. 公司或團隊現在面臨的最大挑戰和機會是什麼？** 開放式問題可以讓你深入了解公司的目標和管理層的心態。檢查您的職涯目標是否與公司的目標一致。 **30. 您認為未來 5/10 年後，公司會在哪？** 面試的時候，被問這個是最難回答的。所以你當然也要問公司，這樣才公平。 **31. 公司如何設定季度/年度目標？這一季/今年的目標是？** 如果沒有公司或團隊目標，那麼您要么是在與錯誤的人交談，要么是在與錯誤的公司交談。對公司的目標表現出興趣，更重要的是，了解當季、當年的優先事項。是否使用 OKR 管理？如果沒有，那是用什麼規劃目標？如何評估成效？ ## 關於職位 **32. 你如何定義我這個職位的成功？你希望我在頭 3 個月內完成什麼？您將如何評估我在試用期的表現？您如何確定某人是否適合您的公司？** 你需要了解試用期如何評估。 **33. 績效考核如何進行？升遷流程如何運作？績效考核與加薪掛鉤嗎？** 您和您的主管可能對成功有不同定義。但績效評估使您、您的主管和公司保持一致。雖然很可怕，但能促進人員和公司的持續改進。這是主管提供回饋、認可成就並提供職業發展指導的好時間。沒有績效評估，就沒有回饋，晉升或加薪的機會也很小。 **34. 我有多少自主權來決定要做什麼？工作的優先順序如何？是否有分配用於副專案/實驗的時間？** 弄清楚有多大自主空間，藉此了解團隊目前專注什麼。如果有分配用於副專案/實驗的時間，那就太幸運囉。 ## 提升職業生涯 **35. 我的主管會定期進行一對一的交流嗎？** 一對一對於讓你和主管保持一致非常重要 **36. 我可以為 XXX 開源專案做貢獻嗎？可以去研討會演講嗎？是否需要任何批准？** 如果你有這些興趣，就要問問。這些都是職業發展的寶貴機會。 --- # 結論公司會展現好的一面，吸引面試者。你需要看穿表面宣傳、弄清楚真實狀況。找到有興趣的問題，不斷提問，直到放心為止。不要問你本來就該知道的事情。職位描述看清楚，公司網站跟之前的對話看清楚，問重複問題會很鳥。祝你好運，感謝閱讀！

0個讚 0留言 841瀏覽

Tony 精選技術文章翻譯 · 11月30日

資深軟體工程師：10年經驗教會我的20件事情！

在軟體產業工作超過十年之後，我總結出了二十條原則，跟大家分享如下： - 原文出處：https://dev.to/ondrejsevcik/20-principles-i-learned-from-10-years-of-developing-software-5354 1. **謙虛**——世界上沒有無所不知的工程師，你也一樣。 2. **先讓它能跑，再讓它正確**——可能的話，再讓它更快。 3. **修改時再優化**——寧可出現重複，也不要出現錯誤的抽象化設計。 4. **始終寫測試**——如果您不寫測試，那麼您就是在手動測試。 5. **解決 80% 的使用情境就好**——你永遠無法解決所有人的問題。 6. **盡量用函數式編程**——比較容易理解。如果您的程式碼需要博士學位才能看懂，那你的方法有點問題。 7. **刪除越多程式碼越好** 8. **足夠好勝於完美**——不要僅僅因為它不完美，就放棄有意義的改進。 9. **私下批評，公開表揚** 10. **做筆記**——如果你認為你會記住它，那你就是在自欺欺人。 11. **與您的用戶溝通**——最好的軟體是由對用戶有同理心的工程師開發的。 12. **有意識地學習**——練習時要牢記一個明確而具體的目標 - 你想要改進什麼以及如何改進（刻意練習）。 13. **不要過早概括**——等到你有至少 3 段重複的程式碼，再進行抽象化（又名：三規則）。 14. **修復破損的窗戶**——代碼中的一段技術債會導致另一段技術債。您的程式碼很快將變得難以管理。 15. **解決問題**——不管是誰的錯，都是你要負責解決。 16. **做有用的事，而不是時髦的事**——先和一個小團隊一起嘗試。如果可行，請擴大實施。如果不行，則中止。 17. **良好的休息才有最佳成果**——定期休息對於獲得最佳表現至關重要。你也不會認為專業短跑運動員一直在短跑吧。 18. **採取小步驟**——大的重寫是行不通的。您將在過程中失去動力和注意力。試著每天發布更新。它使您可以在必要時，自由地調整重點。 19. **表揚出色的工作**——我們在動物身上觀察到的這件事，同時也適用於人類。當你表揚人們的好表現而不是懲罰他們的壞表現時，你會得到更好的結果。 20. **完美的代碼不存在**——最好接受這事實，而不是浪費時間、追逐不可能的事情。

0個讚 0留言 320瀏覽