🔍 搜尋結果:寫測試

🔍 搜尋結果:寫測試

使用 Python 和 Pytest 自動化 API 測試

您是否想過如何使用 python 測試您的 API?在本文中,我們將學習如何使用 Python 和 pytest 框架來測試我們的 API。 對於本教程,您需要安裝 python,您可以在[此處](https://www.python.org/downloads/)下載它 --- ### 簡介: - [什麼是 Python 和 Pytest 框架](#what-is-python-and-pytest-framework) - [我們專案的設定](#configuration-of-our-project) - [使用python建立虛擬環境](#creation-of-virtual-environment-with-python) - [測試的依賴關係設定](#setup-of-dependency-for-the-tests) - [建立我們的第一個測試](#creating-our-first-test) - [將被測試的 API 的定義](#definition-of-the-api-that-will-be-tested) - [建立我們的測試](#creating-our-test) - [重建我們的測試](#refactoring-our-tests) - [產生 html 報告結果](#generate-html-report-result) - [結論](#conclusion) --- ## 什麼是 Python 和 Pytest 框架 「Python」是一種高級通用程式語言,以其簡單性和可讀性而聞名。它由 Guido van Rossum 建立,於 1991 年首次發布。 Python 的設計易於學習,並且具有乾淨簡潔的語法,這使其成為初學者和經驗豐富的程式設計師的流行選擇。 「pytest」框架可以輕鬆編寫小型、可讀的測試,並且可以擴展以支援應用程式和程式庫的複雜功能測試。 --- ## 我們專案的配置 ### 用python建立虛擬環境 在開始建立之前,我們先來了解一下什麼是Python上的虛擬環境。 Python 中的虛擬環境是一個獨立的目錄或資料夾,可讓您為專案建立和管理隔離的 Python 環境。透過環境,您可以輕鬆管理依賴項,避免與不同版本的 python 發生衝突。 虛擬環境(除其他外)是: - 用於包含支援專案(庫或應用程式)所需的特定 Python 解釋器以及軟體庫和二進位檔案。預設情況下,它們與其他虛擬環境中的軟體以及作業系統中安裝的 Python 解釋器和庫隔離。 - 包含在專案目錄中的目錄中,通常名為“venv”或“.venv”,或在許多虛擬環境的容器目錄下,例如“~/.virtualenvs”。 - 未簽入原始碼控制系統(例如 Git)。 - 被認為是一次性的 - 應該很容易刪除並從頭開始重新建立它。您沒有在環境中放置任何專案程式碼 - 不被視為可移動或可複製 - 您只需在目標位置重新建立相同的環境。 您可以在[此處](https://docs.python.org/3/library/venv.html#venv-def)閱讀有關 python 環境的更多資訊。 #### 視窗 首先,為您的專案建立一個資料夾,然後打開 cmd 並使用命令 cd 導航到該資料夾: ``` cd tests_with_python ``` 如果您不知道資料夾在哪裡,可以執行命令“ls”,您將看到資料夾列表,並且可以瀏覽它們。在我們的專案資料夾中,執行以下命令: ``` python -m venv name_of_environment ``` 您的環境名稱可以是任何人,只需記住python 區分大小寫,請查看[PEP 8 風格指南](https://peps.python.org/pep-0008/) 以了解有關Python 約定的更多資訊. 要啟動我們的環境,我們使用以下命令: ``` name_of_environment\Scripts\Activate ``` 如果一切正確,您的環境將被激活,並且在 cmd 上您將看到如下所示: ``` (name_of_environment) C:\User\tests ``` 要停用您的環境,只需執行: ``` deactivate ``` #### Linux 或 MacOS 為您的專案建立一個資料夾,然後打開 cmd 並使用命令 cd 導航到該資料夾: ``` cd tests_with_python ``` 要啟動我們的環境,我們使用以下命令: ``` source name_of_environment/bin/activate ``` 如果一切正確,您的環境將被激活,並且在 cmd 上您將看到如下所示: ``` (name_of_environment) your_user_name tests % ``` 要停用您的環境,只需執行: ``` deactivate ``` ### 設定測試的依賴關係 當我們要測試 API 時,我們需要安裝依賴項來幫助我們進行測試,首先我們將安裝「requests」函式庫來幫助我們發出請求: PS:在執行此命令之前請確保您的環境已激活 ``` pip install requests ``` 為了進行測試,我們將安裝「pytests」框架: ``` pip install pytest ``` --- ## 建立我們的第一個測試 ### 將要測試的 API 的定義 在本教程中,我們將使用返回小行星列表的 Nasa API:[Asteroids - NeoWs](https://api.nasa.gov/#donkiGST),我們將測試檢索基於小行星列表的端點在他們最接近地球的日期。 關於API: - 基本網址:`https://api.nasa.gov/neo/rest/v1/feed` - 查詢參數: |參數|類型|預設|描述| | --------|---------|--------|--------------------| |start_date|YYYY-MM-DD|無|小行星搜尋的開始日期| |end_date|YYYY-MM-DD|start_date後7天|小行星搜尋的結束日期| |api_key|字串|DEMO_KEY|用於擴展用途的 api.nasa.gov 密鑰| 在本教程中,我們將重點放在三種類型的測試: - 合約:如果 API 能夠驗證傳送的查詢參數 - 狀態:狀態程式碼是否正確 - 身份驗證:即使這個API不需要令牌,我們也可以用它來做測試 我們的場景: |方法|測試|預期結果 | | --------|--------|--------------------| |獲取 |搜尋成功 | - 傳回狀態程式碼 200<br/> 正文回應包含小行星清單| |獲取 |無需任何查詢參數即可搜尋 | - 返回狀態碼403<br/>| |獲取 |僅搜尋開始日期| - 傳回狀態程式碼 200 <br/> 主體回應包含小行星清單| |獲取 |僅搜尋結束日期| - 傳回狀態程式碼 200 <br/> 主體回應包含小行星清單| |獲取 |在有效日期範圍內搜尋| - 傳回狀態碼 200<br/> - 正文回應包含所有非空白欄位| |獲取 |當開始日期大於結束日期時進行搜尋| - 傳回狀態程式碼 400 <br/>| |獲取 |使用無效的 API 令牌進行搜尋| - 傳回狀態程式碼 403 <br/> 主體回應包含小行星清單| ### 建立我們的測試 首先,我們將建立一個名為「tests.py」的文件,我們將在該文件中編寫測試。為了幫助我們使用良好的實踐並編寫良好的自動化測試,讓我們使用 [TDD(測試驅動開發)](https://www.browserstack.com/guide/what-is-test-driven-development?psafe_param=1?keyword=&campaignid=&adgroupid=&adid=8784011037660164696&utm_source=google&utm_medium=cpc&utm_platform=paidads&utm_content=602353912717&utm_campapaidads&utm_content=602353912717&utm_campa.utm_term=+&gad_source=1&gclid=CjwKCAiAxreqBhAxEiwAfGfndN8P705lwnkvEFnCz_lueR2hnhmZXgboBQEtKTaCIRbhcb1SXOxBYhoC-WoQAD_BwwE)技術。 該技術包括: - 紅色 - 進行失敗的測試 - 綠色 - 使此測試通過 - 重構 - 重構所做的事情,刪除重複的內容 為了編寫一套好的測試,我們將使用 3A 技術: - 安排:準備上下文。 - 行動:執行我們想要示範的行動。 - 斷言:表明我們預期的結果確實發生了。 從紅色開始,使用 3A 技術,我們將編寫第一個測試「成功搜尋小行星」: ``` import pytest def test_search_asteroids_with_sucess(): # Arrange: api_key = "DEMO_KEY" #Act: response = make_request(api_key) #Assertion: assert response.status_code == 200 # Validation of status code data = response.json() # Assertion of body response content: assert len(data) > 0 assert data["element_count"] > 0 ``` - 安排:我們建立一個變數來插入 api_key,在此步驟中,您可以插入執行測試所需的任何資料。通常,在這一步驟我們會建立模擬資料。 - Act:在這一步驟中我們呼叫了負責發出請求的方法 - 斷言:我們驗證回應 `方法或類別的名稱應以 test 開頭` 若要執行我們的測試,請在命令提示字元中執行: ``` pytest test.py ``` 我們將收到一個錯誤,因為我們沒有建立執行請求的方法: ``` test.py F [100%] ====================================================================== FAILURES ====================================================================== _________________________________________________________ test_search_asteroids_with_sucess __________________________________________________________ def test_search_asteroids_with_sucess(): > response = make_request() E NameError: name 'make_request' is not defined test.py:5: NameError ============================================================== short test summary info =============================================================== FAILED test.py::test_search_asteroids_with_sucess - NameError: name 'make_request' is not defined ================================================================= 1 failed in 0.01s ================================================================== ``` 現在,讓我們建立方法來執行請求: ``` import requests def make_request(api_key): base_url = "https://api.nasa.gov/neo/rest/v1/feed/" response = requests.get(f'{base_url}?api_key={api_key}') return response ``` 現在,再次執行我們的測試: ``` ================================================================ test session starts ================================================================= platform darwin -- Python 3.11.5, pytest-7.4.3, pluggy-1.3.0 rootdir: /Users/Documents/tests_python collected 1 item test.py . [100%] ================================================================= 1 passed in 20.22s ================================================================= ``` --- ## 重構我們的測試 現在我們已經了解如何使用 pytest 建立測試以及如何建立請求,我們可以編寫其他測試並開始重構測試。我們要做的第一個重構是從測試文件中刪除請求方法。我們將建立一個名為「make_requests.py」的新文件,其中將包含我們的請求,並將我們所做的請求移至此文件: ``` import requests def make_request(api_key): base_url = "https://api.nasa.gov/neo/rest/v1/feed/" response = requests.get(f'{base_url}?api_key={api_key}') return response ``` 現在,我們需要考慮在其他測試中重複使用此方法,因為我們需要為不同的測試傳遞不同的參數。我們可以透過很多方法來做到這一點,在本教程中,我們將參數的名稱從“api_key”更改為“query_parameters”。我們這樣做是為了讓我們的方法更加靈活,我們可以一次傳遞參數進行測試: ``` import requests def make_request(query_parameters): base_url = "https://api.nasa.gov/neo/rest/v1/feed/" response = requests.get(f'{base_url}?{query_parameters}') return response ``` 之後,我們需要更改我們的測試文件。我們將導入我們建立的這個方法: ``` from make_requests import make_request ``` 為了以更好的方式組織我們的測試,並遵循 pytest 文件的建議,我們將測試移至類別「TestClass」: 再次執行我們的測試: ``` ============================= test session starts ============================== collecting ... collected 7 items test.py::TestClass::test_search_asteroids_with_sucess test.py::TestClass::test_search_asteroids_with_query_parameters_empty test.py::TestClass::test_search_asteroids_with_start_date test.py::TestClass::test_search_asteroids_with_end_date test.py::TestClass::test_search_asteroids_in_valid_range test.py::TestClass::test_search_asteroids_in_invalid_range test.py::TestClass::test_search_asteroids_in_invalid_token ============================== 7 passed in 5.85s =============================== PASSED [ 14%]PASSED [ 28%]PASSED [ 42%]PASSED [ 57%]PASSED [ 71%]PASSED [ 85%]PASSED [100%] Process finished with exit code 0 ``` ### 產生 html 報告結果 為了更好地視覺化您的測試結果,我們可以使用 pytest-html-reporter 庫產生報告 html,為此,我們首先需要安裝該套件: ``` pip install pytest-html ``` 若要產生報告,請在執行測試時新增: ``` pytest test.py --html-report=./report/report.html ``` 將產生一個包含測試結果的 .html 文件,如下所示: ![report_example](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eol3v7iex84t7prmyb9c.png) ## 結論 本文是一篇教程,介紹如何開始使用 python 和 pytest 框架為 API 編寫自動化測試以及如何產生一個報告 html。 您可以在[此處](https://github.com/aliciamarianne1507/tests_python)存取本教學中使用的專案。 我希望這些內容對您有用。 如果您有任何疑問,請隨時與我聯繫! 親親,下週見💅🏼 --- 原文出處:https://dev.to/m4rri4nne/automating-your-api-tests-using-python-and-pytest-23cc

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

> _“信任,但驗證”_(“信任,但驗證”) > -- [俄羅斯諺語](https://en.wikipedia.org/wiki/Trust,_but_verify) --- 我整理了數十位程式設計師、經理、職業教練和其他行業專業人士的建議,為您帶來一份__軟體開發人員最推薦的20 本書__的清單,並附有一些簡短的摘要(亞馬遜提供)。我用於編制此清單的所有資料都可以作為 [GitHub 上的單一 Excel 工作簿](https://github.com/awwsmm/2020books) 免費提供。截至 __2019 年 10 月 19 日星期六__,我的元列表引用了 36 個來源,並包括 297 本獨特書籍的推薦。 我這樣做主要是為了幫助自己整理我在不久的將來想讀的書籍,同時也是為了幫助其他想要打下良好基礎,但可能會因網路上提出不同建議的不同列表而感到沮喪的人。當你可以綜合考慮_每個人的意見_時,為什麼要相信他們中的_一個_?不客氣,網路。 以下是我用來撰寫此清單的__經驗法則__: 1. 盡可能_不_包括_尋求_推薦的文章。 1. 對一本書的不同版本的推薦視為對同一本書的推薦,但對一篇文章內的多個版本的推薦不會重複計算。 1. 作者只_列出_他們已讀過或正在閱讀的書籍的文章_不_包括在內。文章必須以_推薦_書籍清單的形式呈現。 1. 包含針對特定_等級_開發人員(即 CTO、初級開發人員、新手)的清單。 1. 我嘗試跳過針對特定技術(即 PHP、CSS、Java)的列表,但有些列表中散佈著這些類型的書籍;關於所包含文章的每一本書都包含在我的書籍清單中,即使它是一本小說、特定於技術的或與程式設計無關的。 1. 儘管某些人的解釋可能略有不同,但就本列表而言,「軟體開發人員」、「軟體工程師」、「開發人員」、「程式設計師」和「編碼員」都是等效的。除非第 (5) 點也適用,否則包括針對上述任何內容的文章。 就我所知,這是__網路上最完整的軟體開發書籍推薦元列表__。我查看了 Google 返回的“圖書軟體開發人員”的“每一個結果”以及 Dev.To 上標題中包含“圖書”的每篇文章,這就是結果。如果您發現通用軟體開發的書籍推薦清單未包含在我在 GitHub 上的來源電子表格中,請告訴我。如果它符合我上面列出的標準,我很樂意將其加入到列表中。 言歸正傳,列表如下: --- ![Martin Fowler 的企業應用程式架構模式](https://thepracticaldev.s3.amazonaws.com/i/lee3yr9dzmevpfz8r6p3.jpg) ## \#20。 [企業應用架構模式](https://amzn.to/2jSqwQ5) ### 作者:Martin Fowler(_3 路並列 #19 和 #18_) #### 推薦 13.0% > 這本書其實是兩本書合而為一。第一部分是有關開發企業應用程式的簡短教程,您可以從頭到尾閱讀該教程以了解本書課程的範圍。下一部分,即本書的大部分內容,是對模式本身的詳細參考。每個模式都提供使用和實現訊息,以及詳細的 Java 或 C# 程式碼範例。整本書還配有豐富的UML圖來進一步解釋概念。 > > 有了這本書,您將擁有做出有關建立企業應用程式的重要架構決策所需的知識,以及建立它們時使用的經過驗證的模式。 > > -- [Amazon.com](https://amzn.to/2jSqwQ5) --- ![《清潔架構:軟體結構與設計工匠指南》,作者:Robert C.「Uncle Bob」Martin](https://thepracticaldev.s3.amazonaws.com/i/jeoyr1agokp3k43qtrzx.jpg) ## \#19。 [清潔架構:軟體結構與設計工匠指南](https://amzn.to/2jTxLHt) ### 作者:羅伯特·C·「鮑伯叔叔」·馬丁 #### 建議 13.0%(_3 路與 #20 和 #18 平手_) > - 了解軟體架構師需要實現什麼目標,以及實現它的核心規則和實踐 > - 掌握尋址功能、元件分離和資料管理的基本軟體設計原則 > - 了解程式設計範式如何透過限制開發人員可以執行的操作來施加紀律 > - 了解什麼是至關重要的,什麼只是“細節” > - 為 Web、資料庫、胖客戶端、控制台和嵌入式應用程式實施最佳的高級結構 > - 定義適當的邊界和層,並組織元件和服務 > - 了解設計和架構為何出錯,以及如何預防(或修復)這些故障 > > -- [Amazon.com](https://amzn.to/2jTxLHt) --- ![Donald Knuth 的電腦程式設計藝術](https://thepracticaldev.s3.amazonaws.com/i/26n7ggpj2vnte6s7s7b9.jpg) ## \#18。 [電腦程式設計的藝術](https://amzn.to/2XKk8Ik) ### 作者:唐納德高德納 #### 建議 13.0%(_3 路與 #20 和 #19 平手_) > 這部宏偉的傑作全面概述了各種演算法及其分析。現在,《電腦程式設計的藝術》已經是第三版了,其中包含作者的大量修訂,並包括許多新練習。 > > 儘管這本書是幾十年前構思的,但它仍然是一部永恆的經典。本書最大的優點之一是每一章都包含大量問題。作者精心挑選問題,並根據難度進行索引。解決大量此類問題將幫助您深入了解圍繞給定主題的問題。此外,練習還包含各種經典問題。 > > -- [Amazon.com](https://amzn.to/2XKk8Ik) --- ![程式碼:Charles Petzold 的電腦硬體和軟體的隱藏語言](https://thepracticaldev.s3.amazonaws.com/i/36uenl4hsq1v4n9o4olc.jpg) ## \#17。 [程式碼:電腦硬體與軟體的隱藏語言](https://amzn.to/2XYXZKA) ### 查爾斯·佩措爾德 #### 15.9% 推薦(_與 #16_ 並列) > 手電筒、英國入侵、黑貓和蹺蹺板與電腦有什麼關係?在《程式碼》中,他們向我們展示了操縱語言和發明新的相互交流方式的巧妙方式。透過 _CODE_,我們看到這種獨創性和我們人類的溝通衝動是如何推動過去兩個世紀的技術創新的。 > > 作者 Charles Petzold 使用日常物品和熟悉的語言系統(例如點字和莫爾斯電碼),為任何想了解電腦和其他智慧機器的秘密內部生活的人編織了一個富有啟發性的敘述。 > > 這是一個插圖巧妙且非常易於理解的故事,在整個過程中,您會發現自己獲得了理解當今 PC、數位媒體和網路世界的真實背景。無論您的技術水平如何,CODE 都會讓您著迷,甚至可能喚醒您內心的技術愛好者。 > > -- [Amazon.com](https://amzn.to/2XYXZKA) --- ![敏捷軟體開發:原則、模式與實踐,作者:Robert C.「Bob 叔叔」Martin](https://thepracticaldev.s3.amazonaws.com/i/qvta7nticfmwig5x68f7.jpg) ## \#16。 [敏捷軟體開發:原則、模式與實踐](https://amzn.to/2XT4fj3) ### 作者:羅伯特·C·「鮑伯叔叔」·馬丁 #### 15.9% 推薦(_與 #17_ 並列) > 本書由軟體開發人員為軟體開發人員撰寫,是最新軟體開發方法的獨特集合。作者包括 OOD、UML、設計模式、敏捷和 XP 方法,並詳細描述了 C++ 和 Java 中可重複使用程式的完整軟體設計。它使用實用的解決問題的方法,展示瞭如何開發物件導向的應用程式——從分析的早期階段,到底層設計,再到實現。引導讀者了解設計師的想法—展示整個軟體設計過程中出現的錯誤、死胡同和創意見解。本書涵蓋:靜力學和動力學;類設計原則;複雜性管理;包裝設計原理;分析與設計;模式和範式交叉。一一解釋 OOD 的原理,然後透過大量範例、完整的設計和案例研究來示範它們。涵蓋 C++ 和 OOD 應用程式中的陷阱、缺陷和解決方法,然後展示如何使用敏捷方法。詳細討論了大型軟體的設計和開發方法。對建築安全系統進行了三章深入的單一案例研究。適合想要了解如何使用最先進的方法設計物件導向軟體的軟體工程師、程式設計師和分析師。 > > -- [Amazon.com](https://amzn.to/2XT4fj3) --- ![Thomas H. Cormen、Charles E. Leiserson、Ronald L. Rivest 和 Clifford Stein 的演算法簡介](https://thepracticaldev.s3.amazonaws.com/i/3avr69imz4gk8t8osbqc.jpg) ## \#15。 [演算法介紹](https://amzn.to/2XRR81s) ### 作者:Thomas H. Cormen、Charles E. Leiserson、Ronald L. Rivest 與 Clifford Stein #### 建議 17.4%(_3 路與 #14 和 #13 平手_) > 有些演算法書籍嚴謹但不完整;其他的涵蓋大量材料但缺乏嚴謹性。 《演算法導論》獨特地結合了嚴謹性和全面性。本書深入涵蓋了廣泛的演算法,同時使各個層級的讀者都可以理解它們的設計和分析。每一章都相對獨立,可以作為學習單元。這些演算法以英語和偽程式碼進行描述,任何稍微編程過的人都可以閱讀。這些解釋保持基本,但沒有犧牲覆蓋深度或數學嚴謹性。 > > 第一版成為全球大學廣泛使用的教材以及專業人士的標準參考書。第二版新增了關於演算法的作用、機率分析和隨機演算法以及線性規劃的章節。第三版進行了全面修訂和更新。它包括關於 van Emde Boas 樹和多線程演算法的兩個全新章節,對遞歸章節(現在稱為“分而治之”)的大量補充,以及關於矩陣的附錄。它改進了動態規劃和貪婪演算法的處理,以及流網路材料中基於邊緣的流的新概念。此版本加入了許多練習和問題 > > -- [Amazon.com](https://amzn.to/2XRR81s) --- ![Head First 設計模式:Eric Freeman、Elizabeth Robson、Kathy Sierra 和 Bert Bales 編寫的大腦友善指南](https://thepracticaldev.s3.amazonaws.com/i/2k33el50lr3gnihj6zqo.jpg) ## \#14。 [Head First 設計模式:大腦友善指南](https://amzn.to/2XNEdxz) ### 作者:Eric Freeman、Elizabeth Robson、Kathy Sierra 和 Bert Bales #### 建議 17.4%(_3 路與 #15 和 #13 平手_) > 在任何特定時刻,都會有人遇到與您相同的軟體設計問題。而且,很可能其他人已經解決了您的問題。這一版的《Head First Design Patterns》(現已針對 Java 8 進行了更新)向您展示了開發人員用來建立實用、優雅、可重用且靈活的軟體的可靠、經過實際檢驗的模式。當你讀完本書時,你將能夠利用那些與軟體設計的野獸戰鬥並取得勝利的人的最佳設計實踐和經驗。 > > -- [Amazon.com](https://amzn.to/2XNEdxz) --- ![破解編碼面試:189 個程式設計問題和解決方案,作者:Gayle Laakmann McDowell](https://thepracticaldev.s3.amazonaws.com/i/glfijew89yb3sxnxiznu.jpg) ## \#13。 [破解程式設計面試:189題程式設計題及解答](https://amzn.to/2XPSwlg) ### 作者:蓋爾‧拉克曼‧麥克道威爾 #### 建議 17.4%(_3 路與 #15 和 #14 並列_) > - 189 道程式設計面試問題,從基礎知識到最棘手的演算法問題。 > - 如何匯出每個解決方案的演練,以便您可以學習如何自己實現。 > - 有關如何解決 189 個問題的提示,就像您在真實面試中得到的一樣。 > - 五種經過驗證的解決演算法問題的策略,讓你可以解決你沒見過的問題。 > - 廣泛涵蓋基本主題,例如大 O 時間、資料結構和核心演算法。 > - 深入了解 Google 和 Facebook 等頂尖公司如何聘用開發人員。 > - 準備和應對面試軟性方面的技巧:行為問題。 > - 對於面試官和公司:關於什麼是好的面試問題和招募流程的詳細資訊。 > > -- [Amazon.com](https://amzn.to/2XPSwlg) --- ![別讓我思考:Web 可用性的常識方法,作者:Steve Krug](https://thepracticaldev.s3.amazonaws.com/i/8d63yx8mnivrer5d08v6.jpg) ## \#12. [不要讓我思考:網路可用性的常識性方法](https://amzn.to/2XPjDwF) ### 史蒂夫·克魯格 #### 18.8% 推薦(_與#11_並列) > _Don't Make Me Think_ 是 Steve Krug 寫的一本關於人機互動和網路可用性的書。本書的前提是,一個好的軟體程式或網站應該讓使用者盡可能輕鬆、直接地完成他們的預期任務。克魯格指出,人們善於滿足問題,或採用第一個可用的解決方案來解決問題,因此設計應該利用這一點。他經常引用 Amazon.com 作為精心設計的網站的例子,該網站能夠實現高品質的交互,儘管該網站每天都變得越來越大、越來越複雜。 > > 這本書本身旨在成為簡潔(簡潔)和重點突出的寫作範例。根據該書的介紹,其目標是製作一篇可供高管在兩個小時的飛機飛行中閱讀的文本。 > > -- [維基百科](http://bit.ly/2XSAhLY) --- ![The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. “Uncle Bob” Martin](https://thepracticaldev.s3.amazonaws.com/i/8etf99rgjqkmvl0n12b8.jpg) ## \#11。 [The Clean Coder:專業程式設計師行為準則](https://amzn.to/2XMluCs) ### 作者:羅伯特·C·「鮑伯叔叔」·馬丁 #### 18.8% 推薦(_與 #12_ 並列) > 在不斷的不確定性和不間斷的壓力中忍受並取得成功的程式設計師有一個共同的屬性:他們非常關心建立軟體的實踐。他們把它當作一門手藝。他們是專業人士。 > > 在《乾淨的編碼器:專業程式設計師的行為準則》中,傳奇軟體專家 Robert C. Martin 介紹了真正的軟體工藝的學科、技術、工具和實踐。本書充滿了實用的建議——從估計和編碼到重構和測試。它涵蓋的不僅僅是技術:它是關於態度。馬丁展示瞭如何以榮譽、自尊和自豪的態度進行軟體開發;工作良好,工作乾淨;忠實地溝通和評估;清晰而誠實地面對困難的決定;並理解深刻的知識伴隨著採取行動的責任。 > > -- [Amazon.com](https://amzn.to/2XMluCs) --- ![軟技能:John Sonmez 的軟體開發人員生活手冊](https://thepracticaldev.s3.amazonaws.com/i/3cjtbj9vse8xzxa35po2.jpg) ## \#10. [軟體技能:軟體開發人員的生活手冊](https://amzn.to/2XR9u2y) ### 約翰‧桑梅茲 #### 23.2% 推薦(_與#11_並列) > _軟技能:軟體開發人員生活手冊_ 是作為技術專業人員全面、令人滿意的生活的指南。在其中,開發人員兼生活教練 John Sonmez 就重要的「軟」主題向開發人員提供建議,例如職業和生產力、個人理財和投資,甚至健身和人際關係。這本有趣的書由 71 個短章組成,邀請您隨心所欲地閱讀。每章末尾的「採取行動」部分向您展示如何快速獲得結果。軟技能將幫助您成為更好的程式設計師、更有價值的員工以及更快樂、更健康的人。 > > -- [Amazon.com](https://amzn.to/2XR9u2y) --- ![Peopleware:富有成效的專案和團隊,作者:Tom DeMarco 和 Timothy Lister](https://thepracticaldev.s3.amazonaws.com/i/pplphoinwajolqw6pdf9.jpg) ## \#9。 [Peopleware:高效率的專案與團隊](https://amzn.to/2XR6keY) ### 湯姆·德馬科和提摩西·利斯特 #### 23.2% 推薦(_與 #12_ 並列) > _Peopleware_ 是一本有關軟體組織管理的熱門書籍。書的第一章聲稱,「我們工作的主要問題本質上與其說是技術問題,不如說是社會學問題」。這本書探討了社會學或「政治」議題,例如團隊化學反應和團隊凝聚力、工作環境中的「流動時間」和安靜以及高流動成本。其他主題包括個人工作觀點與企業意識形態之間的衝突、企業熵、「團隊滅絕」和工作空間理論。 > > 作者將大多數主題呈現為由一些具體故事或其他資訊支持的原則。例如,「義大利麵晚餐」一章介紹了一個虛構的例子,一位經理邀請一個新團隊來吃晚飯,然後讓他們作為一個團隊購買和準備飯菜,以便讓一線團隊取得成功。其他章節使用現實生活中的故事或引用各種研究來說明所提出的原則 > > -- [維基百科](http://bit.ly/2XMFrJf) --- ![Jon Bentley 的程式設計珍珠](https://thepracticaldev.s3.amazonaws.com/i/fa7x5erzt1qryzis8784.jpg) ## \#8。 [程式珍珠](https://amzn.to/2XNxWlf) ### 喬恩‧本特利 #### 26.1% 推薦 > 電腦程式設計有很多面貌。弗雷德布魯克斯 (Fred Brooks) 在《人月神話》中描繪了一幅宏偉的圖畫。他的文章強調了管理在大型軟體專案中的關鍵作用。 Steve McConnell 在 Code Complete 中更詳細地教授了良好的程式設計風格。這些書中的主題是優秀軟體的關鍵,也是專業程式設計師的標誌。然而不幸的是,這些合理的工程原理的熟練應用並不總是令人興奮——直到軟體按時完成並且不出意外地工作。 > > 本書中的專欄介紹了該行業更迷人的方面:編程珍珠,其起源超出了紮實的工程,而是在洞察力和創造力的領域。正如天然珍珠是從激怒牡蠣的沙粒中生長出來的一樣,這些編程珍珠也是從激怒真正程式設計師的實際問題中生長出來的。這些程式很有趣,並且教授重要的程式技術和基本設計原理。 > > -- [Amazon.com](https://amzn.to/2XNxWlf) --- ![有效處理 Michael Feathers 的遺留程式碼](https://thepracticaldev.s3.amazonaws.com/i/4bls25qdhatgaz2vvmz5.jpg) ## \#7。 [有效處理遺留程式碼](https://amzn.to/2Y5hNvR) ### 麥可費瑟斯 #### 27.5% 推薦(_與#6_並列) > 你的程式碼容易修改嗎?當你改變它時,你能得到幾乎即時的回饋嗎?你到底懂不懂呢?如果這些問題中任何一個的答案是否定的,那麼您就有遺留程式碼,並且它會消耗您的開發工作的時間和金錢。 > > 在本書中,Michael Feathers 提供了從頭到尾的策略,以便更有效地處理大型、未經測試的遺留程式碼庫。本書借鑒了邁克爾為其著名的物件導師研討會建立的材料:邁克爾在指導中使用的技術,幫助數百名開發人員、技術經理和測試人員控制他們的遺留系統。涵蓋的主題包括: > > - 了解軟體變更的機制:新增功能、修復錯誤、改進設計、優化效能 > - 將遺留程式碼放入測試工具中 > - 編寫測試來防止引入新問題 > - 可用於任何語言或平台的技術 - 包含 Java、C++、C 和 C# 範例 > - 準確地辨識需要更改程式碼的位置 > - 處理非物件導向的遺留系統 > - 處理看起來沒有任何結構的應用程式 > > -- [Amazon.com](https://amzn.to/2Y5hNvR) --- ![人月神話:Frederick P. Brooks 的軟體工程論文](https://thepracticaldev.s3.amazonaws.com/i/wd3l2w6s5mzbu1gwf7b8.jpg) ## \#6。 [人月神話:軟體工程論文](https://amzn.to/2XMoXAY) ### 作者:弗雷德里克·P·布魯克斯 #### 27.5% 推薦(_與 #7_ 並列) > 很少有關於軟體專案管理的書籍能像《人月神話》一樣具有影響力和永恆性。 Fred Brooks 融合了軟體工程事實和發人深省的觀點,為任何管理複雜專案的人提供了見解。這些文章借鑒了他作為 IBM System/360 電腦系列以及其大型軟體系統 OS/360 專案經理的經驗。現在,在他的書首次出版 20 年後,布魯克斯重新審視了他最初的想法,並加入了新的想法和建議,無論是對於已經熟悉他的作品的讀者還是第一次發現它的讀者。 > > -- [Amazon.com](https://amzn.to/2XMoXAY) #### 在 Dev.To 上閱讀[我對《人月神話》的評論](https://dev.to/awwsmm/book-review-the-mythical-man-month-1995-1hpn) --- ![重構:改進現有程式碼的設計,作者:Martin Fowler](https://thepracticaldev.s3.amazonaws.com/i/3iai8x9pod62ge1f38su.jpg) ## \#5。 [重構:改進現有程式碼的設計](https://amzn.to/2XQ2KlF) ### 馬丁·福勒 #### 33.3% 推薦(_與#4_並列) > 二十多年來,全世界經驗豐富的程式設計師一直依靠 Martin Fowler 的_重構_來改進現有程式碼的設計並增強軟體的可維護性,並使現有程式碼更易於理解。 > > 這個備受期待的新版本已經全面更新,以反映程式設計領域的重大變化。 _Refactoring_,第二版,提供更新的重構目錄,包括 JavaScript 程式碼範例,以及演示無需類別的重構的新功能範例。 > > 與原版一樣,此版本解釋了什麼是重構;為什麼你應該重構;如何辨識需要重構的程式碼;以及如何真正成功地做到這一點,無論您使用什麼語言。 > > - 了解重構的流程和一般原則 > - 快速應用有用的重構,使程式更易於理解和更改 > - 辨識程式碼中預示重構機會的“難聞氣味” > - 探索重構,每個重構都有解釋、動機、機制和簡單的範例 > - 為您的重建置立可靠的測試 > - 認識重構的權衡與障礙 > > -- [Amazon.com](https://amzn.to/2XQ2KlF) --- ![設計模式:可重複使用物件導向軟體的元素,作者:Erich Gamma、Richard Helm 和 Ralph Johnson](https://thepracticaldev.s3.amazonaws.com/i/8orec0j061cf2ypavhqt.jpg) ## \#4。 [設計模式:可重複使用物件導向軟體的要素](https://amzn.to/2jY1a37) ### 作者:Erich Gamma、Richard Helm 與 Ralph Johnson #### 33.3% 推薦(_與 #5_ 並列) > 本書不是物件導向技術或設計的介紹。許多書已經在這方面做得很好......這也不是一篇高級論文。這是一本關於設計模式的書,描述了物件導向軟體設計中特定問題的簡單而優雅的解決方案...一旦您理解了設計模式並有一個「啊哈!」的感覺。 (不僅僅是與它們的「嗯?」體驗,您將永遠不會以相同的方式思考物件導向的設計。您將擁有可以使您自己的設計更加靈活、模組化、可重用和易於理解的見解- -這就是您首先對物件導向技術感興趣的原因,對吧? > > -- [Amazon.com](https://amzn.to/2jY1a37) --- ![程式碼完整:軟體建立實用手冊,作者:Steve McConnell](https://thepracticaldev.s3.amazonaws.com/i/sf7gm1y7ld56iytxpzbb.jpg) ## \#3。 [程式碼大全:軟體建置實用手冊](https://amzn.to/2jY2PWp) ### 史蒂夫麥康奈爾 #### 44.9% 推薦 > Steve McConnell 的原始《Code Complete》被廣泛認為是最好的實用程式指南之一,十多年來一直在幫助開發人員編寫更好的軟體。現在,這本經典書籍已通過前沿實踐和數百個新程式碼示例進行了全面更新和修訂,闡釋了軟體建置的藝術和科學。麥康奈爾從研究、學術界和日常商業實踐中獲得了豐富的知識體系,將最有效的技術和必須了解的原則綜合成清晰、務實的指導。無論您的經驗水平、開發環境或專案規模如何,本書都會啟發並激發您的思考,並幫助您建立最高品質的程式碼。 > > - 發現永恆的技術和策略,幫助您: > - 最小複雜度、最大創造力的設計 > - 獲得協作開發的好處 > - 應用防禦性程式設計技術來減少和清除錯誤 > - 利用機會重構或改進程式碼,並安全地進行 > - 使用適合您專案的施工實踐 > - 快速有效地除錯問題 > - 及早正確解決關鍵施工問題 > - 將品質貫穿專案的開始、中期和結束階段 > > -- [Amazon.com](https://amzn.to/2jY2PWp) --- ![《實用程式設計師:從熟練工到大師》,作者:Andrew Hunt 和 Dave Thomas](https://thepracticaldev.s3.amazonaws.com/i/9ckxzwb9a5vc6lpl3fhq.jpg) ## \#2。 [務實的程式設計師:從新手到大師](https://amzn.to/2jY48Vh) ### 安德魯·亨特和戴夫·托馬斯 #### 47.8% 推薦 > 程式設計師是經過訓練的工匠,可以使用一組特定的工具(編輯器、物件管理器、版本追蹤器)來產生將在某些環境(硬體元件上的作業系統)中執行的特定類型的產品(程式).與其他工藝一樣,電腦程式設計催生了一系列智慧,其中大部分不是在大學或認證課程中教授的。隨著時間的推移,大多數程式設計師透過獨立實驗掌握了所謂的技巧。在《務實的程式設計師》中,安德魯·亨特和大衛·托馬斯將他們在各自作為軟體設計師和程式碼編寫者的職業生涯中發現的許多真理編入了法律。 > > 作者的一些實用主義要點是具體的,其實施路徑也很明確。例如,他們建議讀者學習一種文字編輯器,並將其用於所有用途。他們還建議即使是最小的專案也使用版本追蹤軟體,並宣傳學習正規表示式語法和文字操作語言的優點。其他(也許更有價值)的建議則更加輕鬆。在除錯部分,有人指出,“如果您看到蹄印,請想到馬,而不是斑馬。”也就是說,懷疑一切,但開始在最明顯的地方尋找問題。有一些關於估算時間和費用以及將測試整合到開發過程中的建議。你需要一本《務實的程式設計師》有兩個原因:它比你費心去表達的更清晰地展示了你自己累積的智慧,它向你介紹了你可能還沒有考慮過的工作方法。正在工作的程式設計師會喜歡這本書。 > > -- [大衛沃爾來自 Amazon.com](https://amzn.to/2jY48Vh) --- ## 最後,最受軟體開發人員推薦的一本書: --- ![《乾淨的程式碼:敏捷軟體工藝手冊》,作者:Robert C.「Bob 叔叔」Martin](https://thepracticaldev.s3.amazonaws.com/i/jlpbbbl4ity80ottuins.jpg) ## \#1。 [整潔程式碼:敏捷軟體流程手冊](https://amzn.to/2k1ogG7) ### 作者:羅伯特·C·「鮑伯叔叔」·馬丁 #### 52.2% 推薦 > 即使是糟糕的程式碼也能運作。但如果程式碼不乾淨,它可能會讓開發組織陷入困境。每年,都會因為程式碼編寫不當而浪費無數的時間和大量資源。但事實並非一定如此。 > > 著名軟體專家 Robert C. Martin 在《乾淨程式碼:敏捷軟體工藝手冊》中提出了革命性範例。 Martin 與Object Mentor 的同事合作,將他們「即時」清理程式碼的最佳敏捷實踐提煉成一本書,這本書將向您灌輸軟體工匠的價值觀,並使您成為更好的程式設計師——但前提是您工作在它。 > > 您將從事什麼類型的工作?你將閱讀程式碼——大量的程式碼。你將面臨著思考該程式碼哪些是正確的、哪些是錯誤的挑戰。更重要的是,您將面臨重新評估您的專業價值觀和對您的技能的承諾的挑戰。 > > _Clean Code_ 分為三個部分。第一部分描述了編寫簡潔程式碼的原則、模式和實踐。第二部分由幾個日益複雜的案例研究組成。每個案例研究都是一次清理程式碼的練習,即將存在一些問題的程式碼庫轉變為健全且高效的程式碼庫。第三部分是回報:一章包含一系列啟發式方法和建立案例研究時收集的「氣味」。結果是一個知識庫,描述了我們編寫、閱讀和清理程式碼時的思維方式。 > > 讀者將從本書中解脫出來 > - 如何區分好程式碼和壞程式碼 > - 如何寫好程式碼以及如何將壞程式碼轉換為好程式碼 > - 如何建立好名字、好函數、好物件、好類 > - 如何格式化程式碼以獲得最大的可讀性 > - 如何在不模糊程式碼邏輯的情況下實現完整的錯誤處理 > - 如何進行單元測試並實踐測試驅動開發 > - 對於任何有興趣產生更好程式碼的開發人員、軟體工程師、專案經理、團隊領導或系統分析師來說,這本書都是必讀的。 > > -- [Amazon.com](https://amzn.to/2k1ogG7) --- 上述「建議百分比」是包含該書的所有調查清單的比例。因此,即使一本書只有“12.5% 的推薦度”,也意味著平均每 8 個開發人員中就有 1 個已經閱讀過該書並推薦給其他開發人員。上述所有書籍都通過了八分之一的門檻。 更令人驚訝的是前 10 名的書籍。平均每 4 個開發人員中有 __1 人推薦 10 到 6 本書。每 3 人中就有 1 人推薦書籍#5 和#4。排名前三的書籍《__Code Complete__》、《The Pragmatic Programmer__》和《__Clean Code__》受到大約__其他軟體開發人員__的推薦。這對現代社會最關鍵的行業之一產生了巨大影響。如果您想加強您的軟體開發知識,但您尚未閱讀這三本書,那麼您的同事很可能會建議您這樣做。 --- --- 如果您喜歡上面的文章,也許您想關注我在 [Dev.To](https://dev.to/awwsmm) 上的工作?或在 [The Tweeter](https://twitter.com/_awwsmm) 上閱讀我的愚蠢推文?或[請我喝杯咖啡](https://ko-fi.com/awwsmm)? (我有令人衰弱的咖啡因成癮。) 不管怎樣,感謝您的光臨! --- 原文出處:https://dev.to/awwsmm/20-most-recommended-books-for-software-developers-5578

初級到資深 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 **謝謝** 非常感謝您閱讀我的部落格🙂。

2024 年的 React 生態系統

原文出處:https://dev.to/avinashvagh/react-ecosystem-in-2024-418k 2024 年,React 將慶祝其成立 11 週年,值得期待 React 生態系統中令人興奮的發展。在本部落格中,我們將基於 2023 年發生的情況以及來年的預期,探討生態系統的各個面向。 ## 1. 路由 路由一直是Web開發的關鍵部分,在2023年,我們看到了各種各樣的路由解決方案。讓我們看看2024年會發生什麼: - **React Router:** React Router 仍然是 React 應用程式中處理路由的基本選擇。憑藉其廣泛的文檔和活躍的社區,它仍然是應用程式中聲明式路由的可靠選擇。 - **React Query:** Tanstack 的 React Query 在 2023 年流行的基礎上,旨在增強資料擷取和狀態管理。它簡化了 React 應用程式中管理、快取和同步資料的過程。 - **Next.js:** Next.js 是一個建立在 React 之上的框架,預計將保持其作為具有靈活路由選項的伺服器渲染 React 應用程式首選的地位。它的官方文件是 Next.js 應用程式中路由的寶貴資源。 2024 年,React 充滿活力的生態系統將繼續蓬勃發展,為開發人員提供豐富的工具和函式庫。請繼續關注 React 世界的更多更新和進步。 ## 2. 客戶端狀態管理 客戶端狀態管理是現代 Web 開發的一個重要方面,可以在前端應用程式中實現高效的資料處理。 Redux Toolkit 和 Zustand 是兩種流行的用戶端狀態管理解決方案。以下是兩者的簡要概述: ### 1. **Redux 工具包** - **網址:** [Redux 工具包](https://redux-toolkit.js.org/) Redux Toolkit 是一個建立在 Redux 之上的綜合狀態管理函式庫,Redux 是 React 應用程式中成熟的狀態管理函式庫。它提供了一組工具和最佳實踐,以可預測且高效的方式簡化狀態管理流程。 Redux Toolkit 的結構化方法(包括 actions、reducer 和 store)非常適合複雜的大型專案。它提倡採用集中式和聲明式的狀態管理方法。 ### 2. **條件** - **示範:** [狀態示範](https://state-demo.pmnd.rs/) Zustand 是一個輕量級且靈活的狀態管理庫,專為小型專案或喜歡更簡單解決方案的開發人員而設計。它簡化了狀態管理,無需複雜的設定和概念。 Zustand 以其簡單性和易用性而聞名,這使其成為小型應用程式和重視更輕量級方法的人的絕佳選擇。 在 Redux Toolkit 和 Zustand 之間進行選擇時,請考慮專案的複雜性以及您對 Redux 的熟悉程度。 Redux Toolkit 是大型、結構化應用程式的絕佳選擇,而 Zustand 則非常適合需要快速、簡單的狀態管理解決方案的小型專案。 ## 3.伺服器狀態管理 伺服器狀態管理是 Web 開發的一個重要方面,特別是對於跨客戶端和伺服器的應用程式。以下是兩個可以幫助您有效管理伺服器狀態的關鍵庫: ### 1. **TanStack 查詢** - **文件:** [TanStack 查詢](https://tanstack.com/query/latest) TanStack Query 是一個強大且靈活的狀態管理庫,用於處理應用程式中的伺服器狀態。它允許您輕鬆地從伺服器獲取、快取和更新資料。該程式庫提供自動快取、高效資料擷取以及自訂 API 端點的功能等功能。對於需要即時資料更新和高效資料同步的應用程式來說,它是管理伺服器狀態的絕佳選擇。 ### 2. **Redux 工具包 - RTK 查詢** - **文件:** [Redux 工具包 - RTK 查詢](https://redux-toolkit.js.org/rtk-query/overview) RTK Query 是 Redux Toolkit 生態系統的一部分,提供管理伺服器狀態的全面解決方案。它以可預測且高效的方式簡化了發出 API 請求、快取資料和更新狀態的過程。 RTK Query 與 Redux 無縫集成,對於使用 Redux 進行狀態管理的應用程式來說是一個絕佳的選擇。它提倡最佳實踐並提供結構化方法來處理伺服器狀態。 選擇伺服器狀態管理庫時,請考慮您的專案需求、資料擷取需求的複雜性以及您對 Redux 的熟悉程度(如果您選擇 RTK 查詢)。這兩個庫都提供了用於管理應用程式中的伺服器狀態的強大解決方案。 ## 4. 表單處理 表單處理是建立 Web 應用程式的關鍵部分,尤其是在 React 中。用於表單處理的兩個流行的程式庫是 Formik 和 React Hook Form。概述如下: ### 1. **甲酸** - **網址:** [Formik](https://formik.org/) Formik 是在 React 中建立表單最常用的函式庫。它提供了一組實用程式和元件,可以輕鬆管理表單狀態、驗證和提交。雖然它是一個流行的選擇,但截至最新消息,Formik 並未得到積極維護,這可能會影響其與未來 React 更新和不斷發展的最佳實踐的兼容性。使用 Formik 的唯一缺點是它不被維護。 Formik 文件/網站甚至不鼓勵在新專案中使用 Formik。 ### 2. **反應鉤子形式** - **網址:** [React Hook 表單](https://www.react-hook-form.com/) React Hook Form 是一個現代表單函式庫,它利用 React hooks 來有效地處理表單狀態和驗證。它得到積極維護,並提供輕量級且直觀的 API。 React Hook Form 以其效能和靈活性而聞名,使其成為在 React 應用程式中處理表單的絕佳選擇。 在 Formik 和 React Hook Form 之間進行選擇時,請考慮維護和專案的特定要求等因素。根據最新消息,React Hook Form 因其積極的開發和現代的表單處理方法而成為推薦選擇。 ## 5. 測試 測試是軟體開發過程的關鍵部分,有各種工具和程式庫可協助開發人員編寫有效的測試。以下是一些用於測試的資源和工具: ### 1. **ViTest** - **網址:** [ViTest](https://vitest.dev/) ViTest 是一個由 vite 支援的單元測試框架。它提供了一種為 React、Vue、Svelte 等應用程式編寫單元測試、元件測試和端到端測試的簡單方法。如果您使用 React,ViTest 可以透過全面的測試來幫助您確保程式碼的可靠性和品質。 ### 2. **React 測試函式庫** - **文件:** [React 測試庫](https://testing-library.com/docs/react-testing-library/intro/) React 測試庫是 React 應用程式的熱門測試庫。它專注於編寫模擬使用者互動的測試,幫助您確保元件從使用者的角度按照預期運行。該程式庫鼓勵測試 React 元件的最佳實踐。 ### 3. **劇作家** - **網址:** [劇作家](https://playwright.dev/) Playwright 是一個端對端測試框架,支援多種瀏覽器,包括 Chromium、Firefox 和 WebKit。它為瀏覽器自動化提供了統一的 API,並允許您編寫測試來驗證 Web 應用程式在不同瀏覽器上的功能。 Playwright 是確保跨瀏覽器相容性的強大工具。 這些資源和工具可以幫助您涵蓋測試的各個方面,從單元測試到端到端測試,具體取決於您的專案需求和您正在使用的技術。請務必進一步探索它們,以選擇最適合您要求的一種。 ## 6. 樣式 當談到 Web 開發中的樣式時,有幾種流行的工具和庫可供選擇。以下是三個值得注意的選項: ### 1. **Tailwind CSS** - **網址:** [Tailwind CSS](https://tailwindcss.com/) Tailwind CSS 是一個實用程式優先的 CSS 框架,它提供了一組預先建立的原子 CSS 類別來設計您的 Web 應用程式。它旨在透過在 HTML 中編寫實用程式類別來幫助您快速創建響應式且高度可自訂的設計。 Tailwind CSS 以其靈活性而聞名,對於想要實用程式驅動的樣式設計方法的開發人員來說是一個絕佳的選擇。 ### 2. **樣式元件** - **網址:** [樣式組件](https://styled-components.com/) Styled Components 是一個 CSS-in-JS 函式庫,用於設計 React 元件的樣式。它允許您透過使用標記模板文字定義樣式元件來直接在 JavaScript 檔案中編寫 CSS。這種方法使您能夠將樣式封裝在元件中,從而更輕鬆地管理和維護 CSS。樣式化組件在 React 生態系統中特別受歡迎。 ### 3. **情感** - **文檔:** [情緒](https://emotion.sh/docs/introduction) Emotion 是另一個 CSS-in-JS 函式庫,重點是效能和靈活性。它提供了多種方法來定義樣式並將其應用到 React 元件,包括字串和物件樣式。 Emotion 以其可預測性和適合使用 JavaScript 編寫不同 CSS 樣式而聞名。它提供了一種與框架無關的方法,使其適用於各種 JavaScript 框架。 這些工具中的每一個都有自己的優勢,並且適合不同的用例。 Tailwind CSS 擅長使用實用程式類別進行快速 UI 開發。 Styled Components 和 Emotion 是 React 應用程式中元件級樣式的理想選擇。您的選擇將取決於您的專案要求和個人喜好。 ## 7.UI元件庫 用於在 2023 年建立使用者介面的 UI 元件庫,並將在 2024 年繼續使用。 ### 1. **材質-UI** - **網址:** [Material-UI](https://mui.com/) Material-UI 是一個受歡迎且維護良好的 React UI 框架。它基於 Google 的 Material Design 指南,並提供廣泛的元件來創建現代且具有視覺吸引力的使用者介面。 ### 2. **曼汀** - **網址:** [Mantine](https://mantine.dev/) Mantine 是一個現代 React 元件庫,專注於提供高品質的元件和鉤子。它提供了各種 UI 元素和工具來簡化您的開發流程。 ### 3. **螞蟻設計** - **網址:** [Ant Design](https://ant.design/) Ant Design 是一個用於建立企業級 React 應用程式的綜合設計系統和元件庫。它以其豐富的組件和強調自然清晰的設計理念而聞名。 ### 4. **脈輪使用者介面** - **網址:** [Chakra UI](https://chakra-ui.com/) Chakra UI 是在 React 中建立可存取且高度可自訂的使用者介面的熱門選擇。它提供了一組可組合組件和一個樣式道具系統,用於靈活的樣式設定。 ### 5. **無頭 UI(Tailwind CSS 框架)** - **網址:** [無頭 UI](https://headlessui.com/) Headless UI 是一組完全可存取、無樣式的 UI 元件,旨在與 Tailwind CSS 無縫協作。它允許您建立可存取的介面,同時保留對樣式的完全控制。 ### 6. **DaisyUI(Tailwind CSS 框架)** - **網址:** [DaisyUI](https://daisyui.com/) DaisyUI 是 Tailwind CSS 的擴展,它帶來了額外的元件和實用程式來增強您的開發體驗。如果您已經在使用 Tailwind CSS,它會特別有用。 ### 7.**Shadcn UI(Tailwind CSS 框架)** - **網址:** [Shadcn UI](https://ui.shadcn.com/) Shadcn UI 是另一個基於 Tailwind CSS 的 UI 元件庫,它提供了一系列元件和實用程序,用於快速有效地建立 Web 應用程式。 這些程式庫提供了各種元件和工具,可協助您在 React 應用程式中建立響應靈敏且具有視覺吸引力的使用者介面。庫的選擇取決於您的項目的要求和您的個人喜好。 ## 8. 動畫 如果您對 React 動畫庫感興趣,兩個流行的選擇是: 1. **React Spring** - 您可以在 React Spring 的官方網站 [react-spring.dev](https://www.react-spring.dev/) 上找到有關 React Spring 的更多資訊和文件。 React Spring 是一個功能豐富的動畫庫,它利用基於實體的動畫在 React 中創建流暢的互動式動畫。 2. **Framer Motion** - 另一個出色的選擇是 Framer Motion,您可以在 [framer.com/motion](https://www.framer.com/motion/) 進一步探索它。 Framer Motion 因是專為 React 設計的功能豐富的動畫庫而聞名。它提供了靈活性,非常適合在 React 應用程式中創建流暢的動畫。 這兩個庫都有其優點,它們之間的選擇可能取決於您的特定項目要求和個人喜好。 React Spring 提供基於實體的動畫和豐富的功能集,而 Framer Motion 以其易用性和靈活性而聞名。最好對兩者進行探索,看看哪一個更符合您的動畫需求。 請隨意參考各自的網站以獲取詳細的文件和範例,以便做出明智的選擇。 ## 9. 資料視覺化 當涉及 React 中的資料視覺化時,有幾個函式庫可以幫助您建立互動式且資訊豐富的圖表和圖形。以下是三個流行的選項: 1. **Victory** - 您可以在 [formidable.com/open-source/victory/docs](https://formidable.com/open-source/victory/docs) 中瀏覽 Victory 的文檔 Victory 是一個強大的 React 資料視覺化函式庫,提供廣泛的圖表類型和自訂選項。它旨在輕鬆創建具有視覺吸引力的互動式資料視覺化。 2. **React Chartjs 2** - 造訪 [react-chartjs-2.js.org](https://react-chartjs-2.js.org/) 以了解更多資訊。 React Chartjs 2 是 Chart.js(一個流行的 JavaScript 圖表庫)的 React 包裝器。它提供了一種將 Chart.js 整合到 React 應用程式中的簡單方法,可讓您使用 Chart.js 的底層功能建立各種圖表和圖形。 3. **Recharts** - 有關Recharts的詳細信息,您可以參考[recharts.org/en-US/](https://recharts.org/en-US/)。 Recharts 是一個使用 React 建立的可組合圖表庫。它提供了一個簡單而靈活的 API 來創建各種類型的圖表,非常適合將資料視覺化添加到您的 React 專案中。 每個庫都有自己的一組功能和優點,因此選擇將取決於您的特定項目要求和個人喜好。您可以存取他們各自的文件以了解更多資訊並開始使用 React 中的資料視覺化。 ## 10. 表 如果您正在尋找有關 React 中表格的信息,可以在 [tanstack.com/table/v8](https://tanstack.com/table/v8) 上瀏覽版本 8 的 TanStack Table 文件。 TanStack Table 是一個無頭 UI 庫,可讓您在 TS/JS、React、Vue、Solid 和 Svelte 等各種框架中建立強大的表格和資料網格,同時保留對標記和樣式的控制。該文件將為您提供有關如何使用 TanStack Table 和配置表的詳細信息,包括選項和 API 屬性。 無論您使用 TypeScript 還是 JavaScript 以及使用受支援的框架之一,TanStack Table v8 都提供了一種靈活的解決方案,用於在 Web 應用程式中建立表格和資料網格。該文件將引導您完成整個過程,並幫助您充分利用該庫來滿足您的特定需求。 ## 11. 國際化(i18n) 當涉及 React 應用程式中的國際化 (i18n) 時,有多個程式庫和工具可協助您管理翻譯和在地化。 React 中 i18n 的兩個突出選項是: 1. **i18next** - 您可以在 [react.i18next.com](https://react.i18next.com/) 找到使用 i18next 的文件和資源。 i18next 是一個流行的 JavaScript 國際化框架,包括 React。它提供了處理翻譯、格式化等的全面解決方案。 2. **React-Intl (Format.js)** - React-Intl 的文檔是 Format.js 專案的一部分,可以在 [formatjs.io/docs/react-intl](https: //formatjs.io/ docs/react-intl)。 React-Intl 是一個函式庫,提供用於在 React 應用程式中格式化和處理國際化文字的工具。 這兩個函式庫都有活躍的社群、豐富的文檔,並且在 React 生態系統中廣泛使用。您可以探索這些資源,以確定哪一個最適合您的 React 應用程式國際化需求。 ## 12. 開發工具 DevTools 對於偵錯和改進 Web 應用程式的開發工作流程至關重要。以下是一些流行的 React 開發工具和相關函式庫: 1. **React 開發者工具** - 該工具可作為 Chrome 擴充功能使用。它允許您檢查 React 元件層次結構、查看元件的狀態和 props,甚至更改元件的狀態以進行測試。您可以從 [Chrome Web Store](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi) 安裝它。 2. **Redux DevTools** - Redux DevTools 是另一個 Chrome 擴展,可以增強 Redux 開發工作流程。它提供了對 Redux 儲存的深入了解,讓您可以檢查操作和狀態變更、倒回和重播操作等。您可以從 [Chrome Web Store](https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd) 安裝它。 3. **Testing Playground** - Test Playground 是一個 Chrome 擴展,可以簡化 React 元件的測試。它提供了一個用於試驗組件及其道具的視覺環境。您可以在 [Chrome 線上應用程式商店](https://chrome.google.com/webstore/detail/testing-playground/hejbmebodbijjdhflfknehhcgaklhano) 上找到它。 4. **React Hook Form DevTools** - 對於使用 React Hook Form 的用戶,可以使用 DevTools 來協助偵錯表單行為。您可以在 [React Hook Form 網站](https://www.react-hook-form.com/dev-tools/) 上存取它們。 5. **TanStack Query DevTools** - TanStack Query 是 React 的資料擷取庫,它提供用於偵錯和檢查查詢和突變的 DevTools。您可以參考[官方文件](https://tanstack.com/query/v4/docs/react/devtools)以了解更多資訊。 這些開發工具可協助開發人員簡化開發和偵錯流程,從而更輕鬆地建置和維護 Web 應用程式。 ## 13. 文檔 文件對於任何軟體專案都至關重要。以下是用於建立文件的兩種流行工具: 1. **Docusaurus** - Docusaurus 是一種廣泛採用的用於建立文件網站的工具。它是一個開源框架,為創建和維護文件提供了乾淨且用戶友好的介面。 Docusaurus 具有高度可自訂性,許多專案和組織都使用它來建立文件網站。您可以在 Docusaurus 的[官方網站](https://docusaurus.io/)上了解更多並開始使用 Docusaurus。 2. **Nextra** - Nextra 是建立文件網站的另一種選擇。雖然 Nextra 可能不像 Docusaurus 那樣出名,但它提供了一種現代且簡約的方法來建立文件。它的設計是輕量級且用戶友好的,對於那些喜歡簡單乾淨的文檔風格的人來說是一個不錯的選擇。您可以在 Nextra 的[官方網站](https://nextra.site/) 上探索有關 Nextra 的更多資訊。 Docusaurus 和 Nextra 都有各自的優勢,它們之間的選擇取決於您的特定需求和偏好。您可以訪問他們各自的網站以了解更多資訊、訪問文件並確定哪一個最適合您的專案。 ## 14. 元件開發環境 元件開發環境 (Dev Env) 對於有效建置和測試 UI 元件至關重要。用於為 UI 元件創建開發環境的廣泛使用的工具之一是 [Storybook](https://storybook.js.org/)。 Storybook 是業界標準的元件瀏覽器,可讓開發人員獨立開發 UI 元件。當處理設計系統或元件庫時,它特別有價值。以下是 Storybook 如何協助創建 UI 元件的開發環境: 1. **目錄 UI 元件**:Storybook 提供了用於編目和顯示 UI 元件的專用環境。開發人員可以單獨查看每個組件的外觀和行為。 2. **將元件變體儲存為故事**:在 Storybook 中,開發人員可以為每個元件建立「故事」。這些故事代表組件的不同變體或用例。這是記錄和展示組件行為的絕佳方式。 3. **開發人員體驗工具**:Storybook 提供了一系列開發人員體驗工具,包括熱模組重新加載,以簡化組件開發流程。 透過使用 Storybook,您可以有效率地開發、測試和記錄 UI 元件。它在設計系統時特別有用,因為它允許您專注於單個組件及其互動。您可以在 Storybook 的[官方網站](https://storybook.js.org/) 上了解更多並開始使用。 它是一種多功能工具,可以根據專案的特定需求進行定制,使其成為組件開發環境的寶貴資產。 ## 15. 類型檢查 TypeScript 是 Microsoft 開發的一種程式語言,透過新增靜態類型來擴充 JavaScript。它提供全面的類型檢查和強大的類型系統,以捕獲開發過程中的錯誤並提高程式碼品質。以下是 TypeScript 中類型檢查的一些關鍵方面: 1. **靜態型別系統**:TypeScript 引進了靜態型別系統,這表示在編譯時檢查類型。這有助於在執行程式碼之前識別與類型相關的錯誤。 2. **型別註解**:開發者可以使用型別註解來指定變數、函數參數和傳回值的型別。這提供了清晰度並確保變數的使用一致。 3. **推斷**:TypeScript 可以根據指派給變數的值推斷類型。這減少了對顯式類型註解的需求並提高了程式碼簡潔性。 4. **類型聲明**:TypeScript支援自訂類型的聲明,例如介面和枚舉,以定義資料結構的形狀並增強程式碼的可維護性。 5. **類型相容性**:TypeScript 有一個檢查類型相容性的系統,這確保你不能將不相容的類型指派給變數。這有助於防止常見的運行時錯誤。 6. **對 JavaScript 文件進行類型檢查**:TypeScript 還可以檢查 JavaScript 文件,讓您可以逐步將 TypeScript 引入現有的 JavaScript 專案中。 透過將 TypeScript 合併到您的開發工作流程中,您可以從這些類型檢查功能中受益,從而儘早發現錯誤、增強程式碼可維護性並提高程式碼的整體品質。您可以在[官方 TypeScript 網站](https://www.typescriptlang.org/) 上了解有關 TypeScript 及其類型檢查功能的更多資訊。 ## 16. 行動應用程式 如果您想要開發行動應用程序,特別是 Android 和 iOS 的行動應用程序,React Native 是一個值得考慮的有價值的框架。 React Native 是一個開源框架,可讓您使用 JavaScript 和 React 建立行動應用程式。這就是 React Native 成為行動應用程式開發的熱門選擇的原因: 1. **跨平台開發**:React Native 使您能夠使用單一程式碼庫開發適用於 Android 和 iOS 的應用程式。這種方法可以顯著減少開發時間和工作量。 2. **可重複使用元件**:您可以建立跨平台工作的可重複使用 UI 元件,幫助您在應用程式中保持一致的外觀和感覺。 3. **熱重載**:React Native 支援熱重載,這意味著您可以立即看到程式碼變更的結果,而無需重新編譯整個應用程式。這加快了開發速度。 4. **大型社區**:React Native 擁有龐大且活躍的社區,這意味著您可以找到豐富的資源、庫以及常見問題的解決方案。 5. **本機效能**:React Native 應用程式具有接近本機的效能,因為它們使用本機元件進行渲染。這確保了流暢的用戶體驗。 6. **成本效益**:透過在 Android 和 iOS 之間共用程式碼庫,您可以降低開發成本。 要開始使用 React Native,您可以造訪官方網站 [React Native](https://reactnative.dev/) 以取得全面的文件、教學和資源。無論您是初學者還是經驗豐富的開發人員,React Native 都是行動應用程式開發的強大選擇。 ## 17. 為 React 開發人員提供的很棒的函式庫 很高興看到您對 React 開發人員的優秀庫感興趣。以下是一些非常有用的程式庫,可用於 React 開發中的各種功能: ### 1. **用於拖放功能的 DND 套件** - 網址:[免打擾套件](https://dndkit.com/) DND Kit 是一個強大的庫,用於為 React 應用程式添加拖放功能。它提供了一種簡單且可自訂的方法來實現拖放功能,以便在使用者介面中重新排序、重新排列或組織元素。 ### 2. **React Dropzone 用於檔案上傳** - 網址:[React Dropzone](https://react-dropzone.js.org/) React Dropzone 是一個流行的程式庫,用於在 React 應用程式中處理檔案上傳。它提供了一個用戶友好且高度可自訂的 dropzone 元件,簡化了上傳文件的過程,使其成為任何需要文件上傳的項目的有價值的補充。 ### 3. **Firebase 用於身份驗證** - 網址:[Firebase](https://firebase.google.com/) Firebase 由 Google 開發,是一個用於建立 Web 和行動應用程式的綜合平台。它提供廣泛的服務,包括用戶身份驗證。透過 Firebase 驗證,您可以輕鬆地將安全的使用者註冊和登入功能新增到您的 React 應用程式中。 ### 4. **Supabase 用於身份驗證** - 網址:[Supabase](https://supabase.com/) Supabase 是 Firebase 的開源替代品,提供一套用於建立應用程式的服務,包括身份驗證。它提供了可以無縫整合到您的 React 專案中的用戶身份驗證功能。 這些程式庫涵蓋了 React 開發的基本面,包括拖放功能、檔案上傳和使用者身份驗證。根據您的專案要求,您可以利用這些程式庫來增強您的 React 應用程式。 **免責聲明:**“本文是在人工智慧的幫助下創建的” --- 喜歡這個部落格嗎? **[在 X 上關注我](https://twitter.com/avinashvagh)** 我非常活躍,在 Dev.to 上關注我,不錯過更新。 **聯絡人** — [[email protected]](mailto:[email protected]) 與我一起工作。 --- 訂閱**[遠端檔案通訊](https://remoteprofile.beehiiv.com/)**,隨時了解遠距工作趨勢和工作機會。 {% 嵌入 https://x.com/remoteprofile/status/1698215946463359023?s=20 %} 加入 1K+ 遠端求職者,他們正在世界任何地方在美國尋找遠端工作,所有工作機會面向全球受眾(在任何地方工作),**[立即訂閱](https://remoteprofile.beehiiv.com/訂閱)* * 每日在您的收件匣中獲取機會!

React 生態系 2024 年推薦總整理

2024 年,React 將慶祝其成立 11 週年,值得期待 React 生態系統中令人興奮的發展。在本部落格中,我們將基於 2023 年發生的情況以及來年的預期,探討生態系統的各個面向。 原文出處:https://dev.to/avinashvagh/react-ecosystem-in-2024-418k ## 1. 路由 路由一直是Web開發的關鍵部分,在2023年,我們看到了各種各樣的路由解決方案。讓我們看看2024年會發生什麼: - **React Router:** React Router 仍然是 React 應用程式中處理路由的基本選擇。憑藉其廣泛的文件和活躍的社區,它仍然是應用程式中聲明式路由的可靠選擇。 - **React Query:** Tanstack 的 React Query 在 2023 年流行的基礎上,旨在增強資料擷取和狀態管理。它簡化了 React 應用程式中管理、快取和同步資料的過程。 - **Next.js:** Next.js 是一個建立在 React 之上的框架,預計將保持其作為具有靈活路由選項的伺服器渲染 React 應用程式首選的地位。它的官方文件是 Next.js 應用程式中路由的寶貴資源。 2024 年,React 充滿活力的生態系統將繼續蓬勃發展,為開發人員提供豐富的工具和函式庫。請繼續關注 React 世界的更多更新和進步。 ## 2. 客戶端狀態管理 客戶端狀態管理是現代 Web 開發的一個重要方面,可以在前端應用程式中實現高效的資料處理。 Redux Toolkit 和 Zustand 是兩種流行的用戶端狀態管理解決方案。以下是兩者的簡要概述: ### 1. **Redux Toolkit** - **網址:** [Redux Toolkit](https://redux-toolkit.js.org/) Redux Toolkit 是一個建立在 Redux 之上的綜合狀態管理函式庫,Redux 是 React 應用程式中成熟的狀態管理函式庫。它提供了一組工具和最佳實踐,以可預測且高效的方式簡化狀態管理流程。 Redux Toolkit 的結構化方法(包括 actions、reducer 和 store)非常適合複雜的大型專案。它提倡採用集中式和聲明式的狀態管理方法。 ### 2. ** Zustand** - **示範:** [Zustand Demo](https://state-demo.pmnd.rs/) Zustand 是一個輕量級且靈活的狀態管理庫,專為小型專案或喜歡更簡單解決方案的開發人員而設計。它簡化了狀態管理,無需複雜的設定和概念。 Zustand 以其簡單性和易用性而聞名,這使其成為小型應用程式和重視更輕量級方法的人的絕佳選擇。 在 Redux Toolkit 和 Zustand 之間進行選擇時,請考慮專案的複雜性以及您對 Redux 的熟悉程度。 Redux Toolkit 是大型、結構化應用程式的絕佳選擇,而 Zustand 則非常適合需要快速、簡單的狀態管理解決方案的小型專案。 ## 3.伺服器狀態管理 伺服器狀態管理是 Web 開發的一個重要方面,特別是對於跨客戶端和伺服器的應用程式。以下是兩個可以幫助您有效管理伺服器狀態的關鍵庫: ### 1. **TanStack Query** - **文件:** [TanStack Query](https://tanstack.com/query/latest) TanStack Query 是一個強大且靈活的狀態管理庫,用於處理應用程式中的伺服器狀態。它允許您輕鬆地從伺服器獲取、快取和更新資料。該程式庫提供自動快取、高效資料擷取以及自訂 API 端點的功能等功能。對於需要即時資料更新和高效資料同步的應用程式來說,它是管理伺服器狀態的絕佳選擇。 ### 2. **Redux 工具包 - RTK Query** - **文件:** [Redux 工具包 - RTK 查詢](https://redux-toolkit.js.org/rtk-query/overview) RTK Query 是 Redux Toolkit 生態系統的一部分,提供管理伺服器狀態的全面解決方案。它以可預測且高效的方式簡化了發出 API 請求、快取資料和更新狀態的過程。 RTK Query 與 Redux 無縫集成,對於使用 Redux 進行狀態管理的應用程式來說是一個絕佳的選擇。它提倡最佳實踐並提供結構化方法來處理伺服器狀態。 選擇伺服器狀態管理庫時,請考慮您的專案需求、資料擷取需求的複雜性以及您對 Redux 的熟悉程度(如果您選擇 RTK 查詢)。這兩個庫都提供了用於管理應用程式中的伺服器狀態的強大解決方案。 ## 4. 表單處理 表單處理是建立 Web 應用程式的關鍵部分,尤其是在 React 中。用於表單處理的兩個流行的程式庫是 Formik 和 React Hook Form。概述如下: ### 1. ** Formik** - **網址:** [Formik](https://formik.org/) Formik 是在 React 中建立表單最常用的函式庫。它提供了一組實用程式和元件,可以輕鬆管理表單狀態、驗證和提交。雖然它是一個流行的選擇,但截至最新訊息,Formik 並未得到積極維護,這可能會影響其與未來 React 更新和不斷發展的最佳實踐的兼容性。使用 Formik 的唯一缺點是它不被維護。 Formik 文件/網站甚至不鼓勵在新專案中使用 Formik。 ### 2. **React Hook Form** - **網址:** [React Hook 表單](https://www.react-hook-form.com/) React Hook Form 是一個現代表單函式庫,它利用 React hooks 來有效地處理表單狀態和驗證。它得到積極維護,並提供輕量級且直觀的 API。 React Hook Form 以其效能和靈活性而聞名,使其成為在 React 應用程式中處理表單的絕佳選擇。 在 Formik 和 React Hook Form 之間進行選擇時,請考慮維護和專案的特定要求等因素。根據最新訊息,React Hook Form 因其積極的開發和現代的表單處理方法而成為推薦選擇。 ## 5. 測試 測試是軟體開發過程的關鍵部分,有各種工具和程式庫可協助開發人員編寫有效的測試。以下是一些用於測試的資源和工具: ### 1. **ViTest** - **網址:** [ViTest](https://vitest.dev/) ViTest 是一個由 vite 支援的單元測試框架。它提供了一種為 React、Vue、Svelte 等應用程式編寫單元測試、元件測試和端到端測試的簡單方法。如果您使用 React,ViTest 可以透過全面的測試來幫助您確保程式碼的可靠性和品質。 ### 2. **React 測試函式庫** - **文件:** [React 測試庫](https://testing-library.com/docs/react-testing-library/intro/) React 測試庫是 React 應用程式的熱門測試庫。它專注於編寫模擬使用者互動的測試,幫助您確保元件從使用者的角度按照預期執行。該程式庫鼓勵測試 React 元件的最佳實踐。 ### 3. ** Playwright** - **網址:** [Playwright](https://playwright.dev/) Playwright 是一個端對端測試框架,支援多種瀏覽器,包括 Chromium、Firefox 和 WebKit。它為瀏覽器自動化提供了統一的 API,並允許您編寫測試來驗證 Web 應用程式在不同瀏覽器上的功能。 Playwright 是確保跨瀏覽器相容性的強大工具。 這些資源和工具可以幫助您涵蓋測試的各個方面,從單元測試到端到端測試,具體取決於您的專案需求和您正在使用的技術。請務必進一步探索它們,以選擇最適合您要求的一種。 ## 6. 樣式 當談到 Web 開發中的樣式時,有幾種流行的工具和庫可供選擇。以下是三個值得注意的選項: ### 1. **Tailwind CSS** - **網址:** [Tailwind CSS](https://tailwindcss.com/) Tailwind CSS 是一個實用程式優先的 CSS 框架,它提供了一組預先建立的原子 CSS 類別來設計您的 Web 應用程式。它旨在透過在 HTML 中編寫實用程式類別來幫助您快速建立響應式且高度可自訂的設計。 Tailwind CSS 以其靈活性而聞名,對於想要實用程式驅動的樣式設計方法的開發人員來說是一個絕佳的選擇。 ### 2. **樣式元件** - **網址:** [樣式元件](https://styled-components.com/) Styled Components 是一個 CSS-in-JS 函式庫,用於設計 React 元件的樣式。它允許您透過使用標記模板文字定義樣式元件來直接在 JavaScript 檔案中編寫 CSS。這種方法使您能夠將樣式封裝在元件中,從而更輕鬆地管理和維護 CSS。樣式化元件在 React 生態系統中特別受歡迎。 ### 3. ** Emotion** - **文件:** [Emotion](https://emotion.sh/docs/introduction) Emotion 是另一個 CSS-in-JS 函式庫,重點是效能和靈活性。它提供了多種方法來定義樣式並將其應用到 React 元件,包括字串和物件樣式。 Emotion 以其可預測性和適合使用 JavaScript 編寫不同 CSS 樣式而聞名。它提供了一種與框架無關的方法,使其適用於各種 JavaScript 框架。 這些工具中的每一個都有自己的優勢,並且適合不同的用例。 Tailwind CSS 擅長使用實用程式類別進行快速 UI 開發。 Styled Components 和 Emotion 是 React 應用程式中元件級樣式的理想選擇。您的選擇將取決於您的專案要求和個人喜好。 ## 7.UI元件庫 用於在 2023 年建立使用者介面的 UI 元件庫,並將在 2024 年繼續使用。 ### 1. ** Material-UI** - **網址:** [Material-UI](https://mui.com/) Material-UI 是一個受歡迎且維護良好的 React UI 框架。它基於 Google 的 Material Design 指南,並提供廣泛的元件來建立現代且具有視覺吸引力的使用者介面。 ### 2. ** Mantine** - **網址:** [Mantine](https://mantine.dev/) Mantine 是一個現代 React 元件庫,專注於提供高品質的元件和鉤子。它提供了各種 UI 元素和工具來簡化您的開發流程。 ### 3. ** Ant Design** - **網址:** [Ant Design](https://ant.design/) Ant Design 是一個用於建立企業級 React 應用程式的綜合設計系統和元件庫。它以其豐富的元件和強調自然清晰的設計理念而聞名。 ### 4. ** Chakra UI** - **網址:** [Chakra UI](https://chakra-ui.com/) Chakra UI 是在 React 中建立可存取且高度可自訂的使用者介面的熱門選擇。它提供了一組可組合元件和一個樣式道具系統,用於靈活的樣式設定。 ### 5. ** Headless UI(Tailwind CSS 框架)** - **網址:** [Headless UI](https://headlessui.com/) Headless UI 是一組完全可存取、無樣式的 UI 元件,旨在與 Tailwind CSS 無縫協作。它允許您建立可存取的介面,同時保留對樣式的完全控制。 ### 6. **DaisyUI(Tailwind CSS 框架)** - **網址:** [DaisyUI](https://daisyui.com/) DaisyUI 是 Tailwind CSS 的擴展,它帶來了額外的元件和實用程式來增強您的開發體驗。如果您已經在使用 Tailwind CSS,它會特別有用。 ### 7.**Shadcn UI(Tailwind CSS 框架)** - **網址:** [Shadcn UI](https://ui.shadcn.com/) Shadcn UI 是另一個基於 Tailwind CSS 的 UI 元件庫,它提供了一系列元件和實用程序,用於快速有效地建立 Web 應用程式。 這些程式庫提供了各種元件和工具,可協助您在 React 應用程式中建立響應靈敏且具有視覺吸引力的使用者介面。庫的選擇取決於您的專案的要求和您的個人喜好。 ## 8. 動畫 如果您對 React 動畫庫感興趣,兩個流行的選擇是: 1. **React Spring** - 您可以在 React Spring 的官方網站 [react-spring.dev](https://www.react-spring.dev/) 上找到有關 React Spring 的更多資訊和文件。 React Spring 是一個功能豐富的動畫庫,它利用基於實體的動畫在 React 中建立流暢的互動式動畫。 2. **Framer Motion** - 另一個出色的選擇是 Framer Motion,您可以在 [framer.com/motion](https://www.framer.com/motion/) 進一步探索它。 Framer Motion 因是專為 React 設計的功能豐富的動畫庫而聞名。它提供了靈活性,非常適合在 React 應用程式中建立流暢的動畫。 這兩個庫都有其優點,它們之間的選擇可能取決於您的特定專案要求和個人喜好。 React Spring 提供基於實體的動畫和豐富的功能集,而 Framer Motion 以其易用性和靈活性而聞名。最好對兩者進行探索,看看哪一個更符合您的動畫需求。 請隨意參考各自的網站以獲取詳細的文件和範例,以便做出明智的選擇。 ## 9. 資料視覺化 當涉及 React 中的資料視覺化時,有幾個函式庫可以幫助您建立互動式且資訊豐富的圖表和圖形。以下是三個流行的選項: 1. **Victory** - 您可以在 [formidable.com/open-source/victory/docs](https://formidable.com/open-source/victory/docs) 中瀏覽 Victory 的文件 Victory 是一個強大的 React 資料視覺化函式庫,提供廣泛的圖表類型和自訂選項。它旨在輕鬆建立具有視覺吸引力的互動式資料視覺化。 2. **React Chartjs 2** - 造訪 [react-chartjs-2.js.org](https://react-chartjs-2.js.org/) 以了解更多資訊。 React Chartjs 2 是 Chart.js(一個流行的 JavaScript 圖表庫)的 React 包裝器。它提供了一種將 Chart.js 整合到 React 應用程式中的簡單方法,可讓您使用 Chart.js 的底層功能建立各種圖表和圖形。 3. **Recharts** - 有關Recharts的詳細訊息,您可以參考[recharts.org/en-US/](https://recharts.org/en-US/)。 Recharts 是一個使用 React 建立的可組合圖表庫。它提供了一個簡單而靈活的 API 來建立各種類型的圖表,非常適合將資料視覺化加入到您的 React 專案中。 每個庫都有自己的一組功能和優點,因此選擇將取決於您的特定專案要求和個人喜好。您可以存取他們各自的文件以了解更多資訊並開始使用 React 中的資料視覺化。 ## 10. 表 如果您正在尋找有關 React 中表格的訊息,可以在 [tanstack.com/table/v8](https://tanstack.com/table/v8) 上瀏覽版本 8 的 TanStack Table 文件。 TanStack Table 是一個無頭 UI 庫,可讓您在 TS/JS、React、Vue、Solid 和 Svelte 等各種框架中建立強大的表格和資料網格,同時保留對標記和樣式的控制。該文件將為您提供有關如何使用 TanStack Table 和配置表的詳細訊息,包括選項和 API 屬性。 無論您使用 TypeScript 還是 JavaScript 以及使用受支援的框架之一,TanStack Table v8 都提供了一種靈活的解決方案,用於在 Web 應用程式中建立表格和資料網格。該文件將引導您完成整個過程,並幫助您充分利用該庫來滿足您的特定需求。 ## 11. 國際化(i18n) 當涉及 React 應用程式中的國際化 (i18n) 時,有多個程式庫和工具可協助您管理翻譯和在地化。 React 中 i18n 的兩個突出選項是: 1. **i18next** - 您可以在 [react.i18next.com](https://react.i18next.com/) 找到使用 i18next 的文件和資源。 i18next 是一個流行的 JavaScript 國際化框架,包括 React。它提供了處理翻譯、格式化等的全面解決方案。 2. **React-Intl (Format.js)** - React-Intl 的文件是 Format.js 專案的一部分,可以在 [formatjs.io/docs/react-intl](https://formatjs.io/docs/react-intl)。 React-Intl 是一個函式庫,提供用於在 React 應用程式中格式化和處理國際化文字的工具。 這兩個函式庫都有活躍的社群、豐富的文件,並且在 React 生態系統中廣泛使用。您可以探索這些資源,以確定哪一個最適合您的 React 應用程式國際化需求。 ## 12. 開發工具 DevTools 對於偵錯和改進 Web 應用程式的開發工作流程至關重要。以下是一些流行的 React 開發工具和相關函式庫: 1. **React 開發者工具** - 該工具可作為 Chrome 擴充功能使用。它允許您檢查 React 元件層次結構、查看元件的狀態和 props,甚至更改元件的狀態以進行測試。您可以從 [Chrome Web Store](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi) 安裝它。 2. **Redux DevTools** - Redux DevTools 是另一個 Chrome 擴展,可以增強 Redux 開發工作流程。它提供了對 Redux 儲存的深入了解,讓您可以檢查操作和狀態變更、倒回和重播操作等。您可以從 [Chrome Web Store](https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd) 安裝它。 3. **Testing Playground** - Test Playground 是一個 Chrome 擴展,可以簡化 React 元件的測試。它提供了一個用於試驗元件及其道具的視覺環境。您可以在 [Chrome 線上應用程式商店](https://chrome.google.com/webstore/detail/testing-playground/hejbmebodbijjdhflfknehhcgaklhano) 上找到它。 4. **React Hook Form DevTools** - 對於使用 React Hook Form 的用戶,可以使用 DevTools 來協助偵錯表單行為。您可以在 [React Hook Form 網站](https://www.react-hook-form.com/dev-tools/) 上存取它們。 5. **TanStack Query DevTools** - TanStack Query 是 React 的資料擷取庫,它提供用於偵錯和檢查查詢和突變的 DevTools。您可以參考[官方文件](https://tanstack.com/query/v4/docs/react/devtools)以了解更多資訊。 這些開發工具可協助開發人員簡化開發和偵錯流程,從而更輕鬆地建置和維護 Web 應用程式。 ## 13. 文件 文件對於任何軟體專案都至關重要。以下是用於建立文件的兩種流行工具: 1. **Docusaurus** - Docusaurus 是一種廣泛採用的用於建立文件網站的工具。它是一個開源框架,為建立和維護文件提供了乾淨且用戶友好的介面。 Docusaurus 具有高度可自訂性,許多專案和組織都使用它來建立文件網站。您可以在 Docusaurus 的[官方網站](https://docusaurus.io/)上了解更多並開始使用 Docusaurus。 2. **Nextra** - Nextra 是建立文件網站的另一種選擇。雖然 Nextra 可能不像 Docusaurus 那樣出名,但它提供了一種現代且簡約的方法來建立文件。它的設計是輕量級且用戶友好的,對於那些喜歡簡單乾淨的文件風格的人來說是一個不錯的選擇。您可以在 Nextra 的[官方網站](https://nextra.site/) 上探索有關 Nextra 的更多資訊。 Docusaurus 和 Nextra 都有各自的優勢,它們之間的選擇取決於您的特定需求和偏好。您可以存取他們各自的網站以了解更多資訊、存取文件並確定哪一個最適合您的專案。 ## 14. 元件開發環境 元件開發環境 (Dev Env) 對於有效建置和測試 UI 元件至關重要。用於為 UI 元件建立開發環境的廣泛使用的工具之一是 [Storybook](https://storybook.js.org/)。 Storybook 是業界標準的元件瀏覽器,可讓開發人員獨立開發 UI 元件。當處理設計系統或元件庫時,它特別有價值。以下是 Storybook 如何協助建立 UI 元件的開發環境: 1. **目錄 UI 元件**:Storybook 提供了用於編目和顯示 UI 元件的專用環境。開發人員可以單獨查看每個元件的外觀和行為。 2. **將元件變體儲存為故事**:在 Storybook 中,開發人員可以為每個元件建立「故事」。這些故事代表元件的不同變體或用例。這是記錄和展示元件行為的絕佳方式。 3. **開發人員體驗工具**:Storybook 提供了一系列開發人員體驗工具,包括熱模組重新加載,以簡化元件開發流程。 透過使用 Storybook,您可以有效率地開發、測試和記錄 UI 元件。它在設計系統時特別有用,因為它允許您專注於單個元件及其互動。您可以在 Storybook 的[官方網站](https://storybook.js.org/) 上了解更多並開始使用。 它是一種多功能工具,可以根據專案的特定需求進行定制,使其成為元件開發環境的寶貴資產。 ## 15. 類型檢查 TypeScript 是 Microsoft 開發的一種程式語言,透過新增靜態類型來擴充 JavaScript。它提供全面的類型檢查和強大的類型系統,以捕獲開發過程中的錯誤並提高程式碼品質。以下是 TypeScript 中類型檢查的一些關鍵方面: 1. **靜態型別系統**:TypeScript 引進了靜態型別系統,這表示在編譯時檢查類型。這有助於在執行程式碼之前辨識與類型相關的錯誤。 2. **型別註解**:開發者可以使用型別註解來指定變數、函數參數和傳回值的型別。這提供了清晰度並確保變數的使用一致。 3. **推斷**:TypeScript 可以根據指派給變數的值推斷類型。這減少了對顯式類型註解的需求並提高了程式碼簡潔性。 4. **類型聲明**:TypeScript支援自訂類型的聲明,例如介面和枚舉,以定義資料結構的形狀並增強程式碼的可維護性。 5. **類型相容性**:TypeScript 有一個檢查類型相容性的系統,這確保你不能將不相容的類型指派給變數。這有助於防止常見的執行時錯誤。 6. **對 JavaScript 文件進行類型檢查**:TypeScript 還可以檢查 JavaScript 文件,讓您可以逐步將 TypeScript 引入現有的 JavaScript 專案中。 透過將 TypeScript 合併到您的開發工作流程中,您可以從這些類型檢查功能中受益,從而儘早發現錯誤、增強程式碼可維護性並提高程式碼的整體品質。您可以在[官方 TypeScript 網站](https://www.typescriptlang.org/) 上了解有關 TypeScript 及其類型檢查功能的更多資訊。 ## 16. 行動應用程式 如果您想要開發行動應用程式,特別是 Android 和 iOS 的行動應用程式,React Native 是一個值得考慮的有價值的框架。 React Native 是一個開源框架,可讓您使用 JavaScript 和 React 建立行動應用程式。這就是 React Native 成為行動應用程式開發的熱門選擇的原因: 1. **跨平台開發**:React Native 使您能夠使用單一程式碼庫開發適用於 Android 和 iOS 的應用程式。這種方法可以顯著減少開發時間和工作量。 2. **可重複使用元件**:您可以建立跨平台工作的可重複使用 UI 元件,幫助您在應用程式中保持一致的外觀和感覺。 3. **熱重載**:React Native 支援熱重載,這意味著您可以立即看到程式碼變更的結果,而無需重新編譯整個應用程式。這加快了開發速度。 4. **大型社區**:React Native 擁有龐大且活躍的社區,這意味著您可以找到豐富的資源、庫以及常見問題的解決方案。 5. **本機效能**:React Native 應用程式具有接近本機的效能,因為它們使用本機元件進行渲染。這確保了流暢的用戶體驗。 6. **成本效益**:透過在 Android 和 iOS 之間共用程式碼庫,您可以降低開發成本。 要開始使用 React Native,您可以造訪官方網站 [React Native](https://reactnative.dev/) 以取得全面的文件、教學和資源。無論您是初學者還是經驗豐富的開發人員,React Native 都是行動應用程式開發的強大選擇。 ## 17. 為 React 開發人員提供的很棒的函式庫 很高興看到您對 React 開發人員的優秀庫感興趣。以下是一些非常有用的程式庫,可用於 React 開發中的各種功能: ### 1. **用於拖放功能的 DND 套件** - 網址:[DND Kit](https://dndkit.com/) DND Kit 是一個強大的庫,用於為 React 應用程式加入拖放功能。它提供了一種簡單且可自訂的方法來實現拖放功能,以便在使用者介面中重新排序、重新排列或組織元素。 ### 2. **React Dropzone 用於檔案上傳** - 網址:[React Dropzone](https://react-dropzone.js.org/) React Dropzone 是一個流行的程式庫,用於在 React 應用程式中處理檔案上傳。它提供了一個用戶友好且高度可自訂的 dropzone 元件,簡化了上傳文件的過程,使其成為任何需要文件上傳的專案的有價值的補充。 ### 3. **Firebase 用於身份驗證** - 網址:[Firebase](https://firebase.google.com/) Firebase 由 Google 開發,是一個用於建立 Web 和行動應用程式的綜合平台。它提供廣泛的服務,包括用戶身份驗證。透過 Firebase 驗證,您可以輕鬆地將安全的使用者註冊和登入功能新增到您的 React 應用程式中。 ### 4. **Supabase 用於身份驗證** - 網址:[Supabase](https://supabase.com/) Supabase 是 Firebase 的開源替代品,提供一套用於建立應用程式的服務,包括身份驗證。它提供了可以無縫整合到您的 React 專案中的用戶身份驗證功能。 這些程式庫涵蓋了 React 開發的基本面,包括拖放功能、檔案上傳和使用者身份驗證。根據您的專案要求,您可以利用這些程式庫來增強您的 React 應用程式。 **免責聲明:**“本文是在人工智慧的幫助下建立的”

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

測試程式碼是軟體開發最重要的方面之一,因為它可以確保產品的品質、可擴展性和可靠性。 但是,如果沒有任何指導,編寫有效的測試可能會很困難。測試程式碼可能比實際功能的程式碼更複雜、更難維護! 原文出處: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 ``` ##額外提示! 如果您在測試元件中的任何邏輯時遇到困難,這可能反映出您也許應該將元件邏輯分解為更小、更容易且可測試的程式碼片段! 總而言之,遵循此最佳實踐可能會帶來一種新的、可讀且可維護的方法來測試您喜愛的生產程式碼。 > 經過測試的應用程式才是可靠的應用程式!

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

一名資深的德國軟體架構師 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 在命名和寫註解方面有提供一些很好的經驗法則。 --- 以上,希望對大家有幫助!

軟體工程師:面試的時候,你應該問公司的 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 開源專案做貢獻嗎?可以去研討會演講嗎?是否需要任何批准?** 如果你有這些興趣,就要問問。這些都是職業發展的寶貴機會。 --- # 結論 公司會展現好的一面,吸引面試者。你需要看穿表面宣傳、弄清楚真實狀況。找到有興趣的問題,不斷提問,直到放心為止。 不要問你本來就該知道的事情。職位描述看清楚,公司網站跟之前的對話看清楚,問重複問題會很鳥。 祝你好運,感謝閱讀!

資深軟體工程師: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. **完美的代碼不存在**——最好接受這事實,而不是浪費時間、追逐不可能的事情。