### 介紹 每個開發人員都知道編寫測試很重要，但是當涉及 JavaScript 測試時，[有許多框架](https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#JavaScript)可供選擇。那麼，下次啟動專案時，如何知道該選擇哪個框架呢？ 在本文中，我將比較三個流行的框架[——Mocha](https://github.com/mochajs/mocha) 、 [Jest](https://jestjs.io/)和[Jasmine——](https://jasmine.github.io/)以幫助您做出更明智的決定。我將了解這些框架如何處理常見的測試場景，例如模擬函數和非同步呼叫。我將展示如何實施這些測試的範例。我還將討論一些最佳實踐以及為什麼應該使用測試框架。 ### 三個框架 Mocha、Jest 和 Jasmine 都是流行的框架，擁有有用的社群和多年的開發經驗。總體而言，Mocha 和 Jasmine 更適合測試後端，因為它們最初是為 Node 應用程式建立的；因此，他們比 Jest 擁有更多可用的後端工具和文件。對於前端來說，你的測試框架的選擇通常會受到你的前端框架的影響。 Jasmine 更常與 Angular 一起使用，而 Jest 是 Facebook 建立的與 React 一起使用。 無論您選擇哪一個框架，這三個框架都是成熟且有效的選擇。最好的選擇實際上取決於您的專案需求和您的個人喜好。為了幫助您決定哪個框架最適合您，讓我們看看每個框架在一些常見測試場景下的實際應用。 ### 模擬函數 您在應用程式中測試的最常見的事情是函數呼叫。為您的函數編寫可靠的測試非常重要，因為無論測試框架如何，糟糕的測試都可能觸發真實的函數，從而導致記憶體洩漏和瀏覽器中的意外行為。 測試函數呼叫時，您的測試應該： - 專注於函數呼叫的預期結果，而不是函數的實現 - 永遠不要更改應用程式的狀態 - 使用模擬函數，這樣您就不必擔心測試中出現意外的副作用 以下是如何在 Jest、Jasmine 和 Mocha 中模擬前端函數呼叫的範例。 **是** 如果您使用 React，Jest 不需要太多依賴項（如果有的話）。但是，如果您不想深入[研究react-testing-library](https://testing-library.com/docs/react-testing-library/intro) ，Jest也與一些特定於測試的函式庫（例如Enzyme）相容。此範例使用[Enzyme](https://enzymejs.github.io/enzyme/)對元件進行淺層渲染，按一下按鈕，然後查看模式是否已開啟。在這裡，您必須渲染元件並模擬單擊，以查看您的模擬函數呼叫是否按預期開啟模式。  *Jest 中的模擬函數呼叫* **茉莉花** 在所有框架中，Jasmine 更適合 Angular。但是，一旦為 React 設定了所有正確的配置和幫助程式文件，編寫測試就不需要太多程式碼。 在這裡您可以看到使用[ReactTestUtils](https://reactjs.org/docs/test-utils.html)代替 Enzyme 或 React-testing-library（以顯示其他可用工具之一）。 ReactTestUtils 使得在前端使用 Jasmine 變得更加容易，並保持較低的程式碼行數。但是，您需要了解 ReactTestUtils API。  *Jasmine 中的模擬函數呼叫* **摩卡** Mocha 為您提供了更多的靈活性，因為它通常用於前端和後端測試。您必須匯入幾個庫，例如[Chai](https://www.chaijs.com/) ，才能使其與 React 一起使用。雖然 Chai 沒有直接連接到 React，但它是 Mocha 中最常用的斷言函式庫。安裝這些依賴項後，就類似於使用 Jest。此範例結合使用 Enzyme 進行渲染和 Chai 進行斷言。  *Mocha 中的模擬函數呼叫* #### 我的看法 對於模擬函數，這三個函式庫在程式碼行數和複雜性方面都非常相似。我建議只使用最適合您的堆疊的程式庫：Jest for React、Jasmine for Angular 和 Mocha（如果您也在後端使用 Mocha 並且希望保持一致）。 ### 模擬資料 後端測試與前端測試一樣棘手。對於處理資料尤其如此，因為您不希望測試將資料插入真實資料庫中。如果您不小心，這種危險的副作用很容易潛入您的測試套件中。這就是為什麼使用模擬資料設定測試資料庫是最佳實踐的原因。 當您使用模擬資料時，您可以： - 準確地看到錯誤發生的位置，因為您知道期望的值是什麼 - 類型檢查您的後端響應並確保響應不會洩露真實資料 - 更快發現錯誤 您會經常遇到模擬資料以在請求中發送的情況，而這三個框架都支援這種情況。以下是這三個框架如何實現模擬資料的範例。 **是** 在此 Jest 測試中需要注意的最重要的事情是如何檢查資料是否已成功傳遞到 API 或資料庫。最後有幾個 Expect() 匹配器，它們的順序很重要。在發送模擬資料後，您必須準確地告訴 Jest 您希望找到什麼。這裡使用[supertest](https://www.npmjs.com/package/supertest)函式庫來使用假資料發出模擬 post 請求。  *在 Jest 後端測試中處理資料* **茉莉花** 雖然編寫良好的後端 Jasmine 測試需要更多程式碼，但您可以控制建立和重置資料的方式和時間。 Jasmine 還具有內建工具，用於在測試的其他部分引用模擬資料。此範例使用[請求](https://www.npmjs.com/package/request)庫來處理模擬發布資料請求。  *在 Jasmine 後端測試中處理資料* **摩卡** 在所有框架中，Mocha 需要最多的依賴來處理模擬資料和請求。您可能需要使用[chai-http](https://www.app.devspotlight.com/stories/draft/Comparing-the-top-3-Javascript-testing-frameworks)設定一個模擬伺服器來執行請求，而不是像其他伺服器一樣模擬請求和回應。 Mocha 確實有很好的內建工具，但需要更多時間才能上手。使用 Chai 及其相關函式庫是常見的做法，如下例所示：  *在 Mocha 後端測試中處理資料* #### 我的看法 後端測試是 Mocha 和 Jasmine 最強的地方。它們是為測試 Node 應用程式而建構的，這一點在它們的工具中得到了體現。它們使您可以透過框架中包含的選項和功能進行更精細的控制。如果您願意花時間加入一些可用的庫，Jest 仍然是一個不錯的選擇。 ### 模擬異步呼叫 眾所周知，非同步程式碼會引起問題，因此此處的測試尤其重要。您不僅必須注意自己程式碼中的非同步為，而且許多進入生產的錯誤可能來自意外的非同步來源，例如第三方服務。當您編寫具有異步行為的測試時，請盡量避免觸發真正的函數呼叫，因為測試的非同步呼叫與實際程式碼的執行重疊。 所有測試框架都為您提供了編寫非同步程式碼的多種選項。如果您的程式碼使用回調，那麼您的測試就可以使用回呼。如果可以選擇，請考慮使用[async/await 模式](https://javascript.info/async-await)。它使您的程式碼更具可讀性，並幫助您快速找到測試的問題所在。 [Promise](https://javascript.info/promise-basics)也是編寫非同步測試的選擇。如果您正在使用不支援非同步/等待的舊程式碼，請考慮使用這些。但是，請確保它們按照您在生產中期望的順序執行。在整個執行過程中檢查您的值可以幫助捕捉奇怪的行為。 以下是 JavaScript 測試框架中的非同步測試範例。 **是** 儘管使用Jest 編寫後端測試很簡單，但由於它最初是為了與React 一起使用而建立的，因此您最終可能會花一些時間閱讀文件並安裝第三方庫，因為它的大多數工具都是特定於前端的。但 Jest 確實可以處理您需要處理的任何格式的非同步呼叫，例如回呼或 Promises。此 async/await 呼叫的工作方式與其他 JavaScript 程式碼中的工作方式相同。  *使用 async/await 開玩笑非同步呼叫* **茉莉花** Jasmine 最初是為 Node.js 建立的，因此它有很多內建功能。但是，在執行測試之前和之後可能需要一些設定。例如，您可以在此處看到，您應該在 beforeAll 方法中處理非同步呼叫，以防止稍後的測試中產生殘留影響。  *使用 async/await 進行 Jasmine 非同步呼叫* **摩卡** 在這裡您可以看到用於處理返回承諾的完成方法。它使用與前面的 Mocha 範例相同的 chai-http 庫。這是在 Mocha 測試中編寫的非同步呼叫的常見方式。您可以在 Mocha 中使用 Promises 或非同步/等待模式。  *使用 async/await 進行 Mocha 非同步呼叫* #### 我的看法 對於後端測試，Jasmine 可以輕鬆處理非同步方法並且開箱即用，這將是我的首選。 Mocha 和 Jest 也很有用，儘管它們需要更多地搜尋文件才能找到您需要的內容。 ### 模擬渲染元件 另一個重要且常見的測試是確保渲染的元件在預期時可用。和以前一樣，您通常會看到 Jest 與 React 一起使用，Jasmine 與 Angular 一起使用，但您可以在任何前端程式庫上使用這三個框架中的任何一個。 渲染元件可能是一項昂貴的任務，具體取決於渲染的深度。有些開發人員喜歡使用快照測試，它保存代表 UI 當前狀態的檔案。其他人則喜歡模擬渲染的元件。當您尋找 UI 中的變更時，快照更有用，而當您想要查看元件是否按預期工作時，渲染更有用。兩種方法都很有用。 **是** 正如我之前提到的，Jest 是為 React 建置的，因此您無需導入任何特殊的庫來進行渲染測試。這使得這些測試變得簡單並節省了依賴項的空間。 [ReactDOM](https://reactjs.org/docs/react-dom.html)在許多 React 專案中都很常見，並且附帶了檢查基本渲染所需的方法，如下例所示：  *Jest 框架中的 React 渲染測試* **茉莉花** 設定 Jasmine 來進行 React 渲染測試比看起來更困難；它涉及重要的初始設定。 [Angular 團隊](https://angular.io/guide/testing)使用並推薦[Karma](https://www.npmjs.com/package/karma-jasmine)和 Jasmine 來測試元件。下面的範例用於測試 Angular 元件。您必須匯入要測試的元件，並且可以使用 Angular 隨附的 @angular/core/testing 來設定元件的環境，然後再嘗試渲染該元件並檢查它是否可用。  *Jasmine框架中的Angular渲染測試* **摩卡** 您通常會看到[Enzyme](https://enzymejs.github.io/enzyme/)和 Chai 與 Mocha 一起用於前端測試，並且測試 React 渲染沒有任何不同。一旦匯入了所需的特定方法（例如shallow 和expect），您將能夠編寫與其他框架類似的測試。下面的範例利用了 Enzyme 的淺層渲染和 Chai 的斷言。  *Mocha框架中的React渲染測試* #### 我的看法 渲染元件的最佳實踐是僅使用為您的前端庫推薦的測試框架。使用附帶安裝的工具，您無需處理設定錯誤。如果可能，請嘗試使用淺渲染和快照來節省測試時間並專注於渲染元件的核心功能。 ### 結論 希望您現在對這三個流行框架之間的差異有了更好的了解。正如我所提到的，無論您選擇哪種框架，這三個框架都是成熟且有效的選擇，並且可以為您工作，這取決於您的專案的需要和您的偏好。現在您已準備好接受測試！ --- 原文出處：https://dev.to/heroku/comparing-the-top-3-javascript-testing-frameworks-2cco
2021 年，我創辦了一家名為 Linvo 的新創公司，這是一款 LinkedIn 自動化工具。它產生了很多錢，但燒錢率也很高。 我可以告訴你，作為一個年輕的企業家（完全自力更生），我損失了大部分錢😆 我的系統的問題是它不斷故障；我不是世界上最好的程式設計師，但讓我詳細說明一下。  --- 傀儡師會吸走你的記憶 ---------- Linvo 在其生命週期中進行了幾次迭代。我使用了我所知道的技術：React 和 NestJS。 基本上，任何自動化的雲端抓取都會涉及建立任務然後解決它們。 它看起來像這樣：  - Cron 每 10 分鐘執行一次，尋找新的事情要做，並將其發送到佇列。 - 工作人員從佇列中取出任務並處理它們。 - 將所有內容儲存到資料庫。 這是一個非常簡單的解決方案，在多個 EC2 (AWS) 和 Redis 上運作。 理論上，它應該有效 - 是的，您需要水平擴展工作人員，但這不是我的問題。 我開始經歷其他事情——**記憶體洩漏。** 您可能知道， [Puppeteer](https://pptr.dev/) - 一種 chromium 自動瀏覽器，很重（與您電腦上的 Chrome 相同），而且我執行了很多它們 - 它們耗盡了我的記憶體 - 導致伺服器停止工作並佔用網路頻寬。  --- 需要一個解決方案 -------- 重構聽起來就像 - 是的，讓我們這樣做，但我的 Intercom 支援充滿了支援票（我已經有很多用戶），而且我知道我必須建立一些瘋狂的重構。 我有一個解決方案的想法 - 讓我們使用 AWS lambda。 - 拉姆達啟動 - 做任務 - 死亡（大部分時間） 它不會影響你的網路。 它會死掉並且不會導致記憶體洩漏。 它有點貴，因為 Lambda 並不意味著無限期地執行——這會消除整個概念，但我很絕望。 （嗯，好處是你不需要考慮規模。） 這是新的基礎設施：  - 事件橋 cron 每 1 分鐘執行一次（這是最小值） - 為佇列建立六個事件的 Lambda（使其像 cron 每 10 秒執行一次） - SQS隊列（再見，Redis） - Lambda 以自動縮放功能脫穎而出（是嗎？） --- 供應商鎖定 ----- 正如您可能從上下文中了解到的那樣 - 現在我完全使用 AWS，但我不介意 - 只介意如何在我的計算機上測試它。 以前，我使用[Sam](https://github.com/aws/aws-sam-cli) 。和[Serverless](https://www.serverless.com/)幾乎一樣快速地創造整個環境。 是的，他們確實帶來了一些本地測試。他們可以獲得您的 lambda 並將其轉變為端點！耶！ 但我使用的是 Event Bridge、SQS 和 Lambda。那是不可能的。 我遇過[localstack](https://github.com/localstack/localstack) 。它本來應該幫助我在我的電腦上建立整個 AWS 堆疊，但當時很多東西都不受支持，例如 Lambda 層。我在使用它時不知所措。 因此，我開始建立我的「自己的」基礎設施，在 AWS 上部署了一個「測試」SQS，並用它執行本地程式碼（一個呼叫函數的函數），但結果很糟糕。 我在生產方面做得不好；我感覺這個詞當時就壓在我身上。 我只是想擺脫這家新創公司；我甚至免費向人們提供它，吸引了顧客並擺脫了這個問題。 長話短說，我設法以低價出售了該系統，但最近，我發現了一些有趣的事情。 --- Winglang - 類似 Typescript 的雲方言 ----------------------------- 我想我的痛苦是真實的，儘管我會很高興在當天找到它 - 我很高興它今天還活著。 [Winglang](https://github.com/winglang/wing)幫助您建立與我使用的相同的雲端基礎設施，但好處是： - 它不需要您使用任何設定檔。您基本上用程式碼定義了整個基礎設施（您可以檢查他們的整個預檢和飛行中文件） - 你可以在本地執行它 - 謝謝你，上帝，🙏🏻🙏🏻🙏🏻🙏🏻，包括所有基礎設施。 - 您可以將其部署到任何雲端供應商，並且不必使用 AWS。他們實際上可以產生任何 Terraform 或雲端結構，以便於部署。 我和Winglang的創始人Elad（著名的CDK的建置者）進行了交談，他說了一些讓我抽搐的話。 > 當您在飛機上時，您實際上可以處理您的專案並為其編寫測試🤯 我自己無法給他們足夠的星星 - 但請幫我一個忙，給他們的存儲庫加星標，當然，將其用於您的下一個專案。 https://github.com/winglang/wing  --- 最後的話 ---- 我對翼朗很生氣。我希望他們早點這麼做。現在他們出現了。什麼時候一切都與人工智慧有關？ 我建立了一個新的 YouTube 頻道，主要涉及技術、開源和行銷:) 如果您對此感興趣，請隨時在這裡訂閱： https://www.youtube.com/@nevo-david?sub\_confirmation=1 --- 原文出處：https://dev.to/github20k/i-sold-my-startup-because-of-bugs-i-wish-i-had-this-serverless-repository-4l3a
有了正確的函式庫，任何開發人員都可以在他們的應用程式中建立強大的人工智慧功能（如 Ninja 🥷）。 在此列表中，我編譯了 7 個很棒的 AI 庫，您現在可以使用它們（相對）輕鬆地發布功能。 不要忘記為這些圖書館加註星標以表達您的支持。  https://github.com/CopilotKit/CopilotKit --- 1. [CopilotPortal](https://github.com/CopilotKit/CopilotKit) ：建構應用程式原生人工智慧聊天機器人 -------------------------------------------------------------------------------  應用程式內人工智慧聊天機器人助理可以「查看」您目前的應用程式狀態並在前端和後端採取操作。 一組完全可自訂的反應元件和掛鉤以及用於建立 LLM 和您的應用程式之間互動的架構。 定義*useMakeCopilotReadable* 、 *useMakeCopilotActionable*和*CopilotSidebarUIProvider*使其運作。 ``` import "@copilotkit/react-ui/styles.css"; import { CopilotProvider } from "@copilotkit/react-core"; import { CopilotSidebarUIProvider } from "@copilotkit/react-ui"; export default function App(): JSX.Element { return ( <CopilotProvider chatApiEndpoint="/api/copilotkit/chat"> <CopilotSidebarUIProvider> <YourContent /> </CopilotSidebarUIProvider> </CopilotProvider> ); } ``` https://github.com/CopilotKit/CopilotKit --- 2. [RAGxplorer](https://github.com/gabrielchua/RAGxplorer) - 視覺化並探索您的 RAG 文件 ----------------------------------------------------------------------------  RAGxplorer 是一個 Python 工具，用於視覺化機器學習和自然語言處理中的 RAG（檢索增強生成）文件。 以互動方式探索 RAG 流程中使用的文件中的聯繫和內容。 若要設定 RAGxplorer，請在程式碼中定義 RAG 檢查點路徑並安裝指定的依賴項。 ``` import streamlit as st from utils.rag import build_vector_database st.set_page_config(page_title="RAGxplorer", page_icon="🔍") uploaded_file = st.file_uploader("Upload your PDF", type='pdf') query = st.text_input("Enter your query") search = st.button("Search") top_k = st.number_input("Number of Chunks", value=5, min_value=1) st.session_state["chroma"] = build_vector_database(uploaded_file, ...) st.session_state['retrieved_id'] = query_chroma(...) plot_embeddings(...) ``` https://github.com/gabrielchua/RAGxplorer --- 3. [Tavily GPT 研究員](https://github.com/assafelovic/gpt-researcher)- 獲得法學碩士以搜尋網路和資料庫 -----------------------------------------------------------------------------------  Tavilly 可讓您將 GPT 支援的研究和內容產生工具新增至您的 React 應用程式中，從而增強其資料處理和內容建立功能。 ``` # Create an assistant assistant = client.beta.assistants.create( instructions=assistant_prompt_instruction, model="gpt-4-1106-preview", tools=[{ "type": "function", "function": { "name": "tavily_search", "description": "Get information on recent events from the web.", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "The search query to use. For example: 'Latest news on Nvidia stock performance'"}, }, "required": ["query"] } } }] ) ``` https://github.com/assafelovic/gpt-researcher --- 4. [Pezzo.ai](https://github.com/pezzolabs/pezzo) - 開發者優先的 LLMOps 平台 --------------------------------------------------------------------  用於管理 OpenAI 通話的集中平台。 優化您的提示和令牌使用。追蹤您的人工智慧使用情況。 免費且易於整合。 ``` const prompt = await pezzo.getPrompt("AnalyzeSentiment"); const response = await openai.chat.completions.create(prompt); ``` https://github.com/pezzolabs/pezzo --- 5. [DeepEval](https://github.com/confident-ai/deepeval) - 評估 LLM、RAG 和微調性能 --------------------------------------------------------------------------  DeepEval 是一個開源框架，透過將評估視為單元測試來簡化法學碩士的評估。 它提供了評估 LLM 輸出的各種指標，其模組化設計允許開發人員定制他們的評估流程 要使用它，您需要安裝該程式庫、編寫測試案例並執行這些用例來評估您的 LLM 的效能。 ``` Pytest Integration: from deepeval import assert_test from deepeval.metrics import HallucinationMetric from deepeval.test_case import LLMTestCase test_case = LLMTestCase( input="How many evaluation metrics does DeepEval offers?", actual_output="14+ evaluation metrics", context=["DeepEval offers 14+ evaluation metrics"] ) metric = HallucinationMetric(minimum_score=0.7) def test_hallucination(): assert_test(test_case, [metric]) ``` https://github.com/confident-ai/deepeval --- 6. [CopilotTextarea](https://github.com/RecursivelyAI/CopilotKit) - React 應用程式中的 AI 驅動寫作 ----------------------------------------------------------------------------------------  具有 Github CopilotX 功能的任何 React `<textarea>`的直接替代品。 自動完成、插入、編輯。 可以即時或由開發人員提前提供任何上下文。 ``` import { CopilotTextarea } from "@copilotkit/react-textarea"; import { CopilotProvider } from "@copilotkit/react-core"; // Provide context... useMakeCopilotReadable(...) // in your component... <CopilotProvider> <CopilotTextarea/> </CopilotProvider>` ``` https://github.com/RecursivelyAI/CopilotKit --- 7. [SwirlSearch](https://github.com/swirlai/swirl-search) - 人工智慧驅動的搜尋。 ----------------------------------------------------------------------  Swirl Search 是一個開源平台，它使用人工智慧同時搜尋多個資料來源並提供有關這些資料的起草報告。 它可以跨各種來源進行搜尋，包括搜尋引擎、資料庫和雲端服務，並且可以按照儲存庫中提供的安裝說明輕鬆設定。 Swirl Search 建置在 Python/Django 堆疊上，在 Apache 2.0 授權下發布，並作為 Docker 映像提供，使其可供使用者存取和自訂。 https://github.com/swirlai/swirl-search --- 謝謝閱讀！不要忘記為文章加入書籤，給出您的反應，並支持和查看提到的很棒的庫。 乾杯! --- 原文出處：https://dev.to/copilotkit/im-building-an-ai-project-here-are-the-libraries-im-going-to-use-pd0
我自 2019 年以來一直是 Web 開發人員。我使用 React.js 和基於 React 的框架，如 Gatsby、Next、Remix、Astro 和 Hydrogen。我從來沒有對這些工具感到完全滿意，但是，作為一個深入 JS 生態系統的初學者，我從同行那裡聽到的都是這樣的話：「這就是方式，任何其他程式語言要么慢，要么老」。  結果，我習慣了巨大的複雜性：多個獨立的儲存庫、數千個函式庫和框架來實現簡單的事情、GraphQL、微服務、無伺服器、靜態網站產生、增量靜態再生、部分水化、 redux 、redux-thunk、babel、webpack、react 伺服器元件、伺服器操作等。這個清單還可以再持續 10 分鐘。 直到有一天我說**受夠了！** 讓我們來看看我慢慢發瘋的完整時間線。這需要一段時間，在閱讀長篇文章之前，請隨意煮點咖啡！ --- ## 倦怠的時間表 ### [Gatsby.js](https://www.gatsbyjs.com/) 我記得完成我的訓練營並想：“我終於能夠建立我的作品集了！”，所以我做到了。只有一個小問題，我想在 Google 上建立索引，但是使用舊的「create-react-app」使這項任務幾乎不可能完成。很快我了解了 SEO 和 React 的水合循環，這讓我找到了這個問題的「解決方案」：Gatsby.js。靜態網站產生的想法對當時的我來說簡直是革命性的，畢竟沒有什麼比預先渲染 HTML 檔案更快了，對吧？ 我決定透過閱讀文件來學習這個新框架，讓我告訴你，這**不是**一次有趣的體驗。我以前從未聽說過 GraphQL，顯然，您需要它來產生所有靜態檔案（到底是什麼？？？）。我問我的一些網友，很難學習這些過度設計的廢話是否正常，他們回答說「技能問題，再努力一點！」。於是我更加努力，終於學會了之後，我把我的個人網站移植到了Gatsby上。  我的大部分頁面都成功在 Google 上建立了索引，幾個月來，我對結果非常滿意。然後另一個問題出現了：我的**很多**開發者朋友開始說“Gatsby 死了！建立 Next 是為了簡化靜態站點生成並提供伺服器端渲染”。 ### [Next.js](https://nextjs.org/) 我快速瀏覽了 Next 文件並**立即**愛上了它。我能夠在沒有 GraphQL 的情況下用三分之一的程式碼做與 Gatsby 相同的事情！我再次將我的作品集移植到另一個框架：Next。 這次我確實有一次美好的經驗。部署到 Vercel 輕而易舉，「getStaticProps」和「getServerSideProps」功能很簡單，但功能非常強大，我可以選擇每個頁面的渲染樣式，整體來說非常靈活。 不幸的是，我透過慘痛的教訓學到了一些東西：在 JavaScript 生態系統中，所有美好的事情都會結束。 ### [混音](https://remix.run/) 我清楚記得 Remix 發佈時的情景。多名科技影響者開始發布有關它的內容（一如既往）。然而，當時我在主頁上看到它不支援靜態網站生成，只支援伺服器端渲染，所以我想「等一下，這些年來投資於 [JAMstack](https://jamstack.org/) 都被扔在這裡了嗎？不可能，這個框架不會長久」。然而，令我驚訝的是，Remix 不僅生存了下來，而且還被 Shopify 收購 https://shopify.engineering/remix-joins-shopify ，並成為 Next 的重要競爭對手。 幾個月過去了，我決定嘗試看看。我再一次感到驚訝，Remix 的主要座右銘是使用 Web 基礎知識，而不是像 Next 這樣過於複雜的快取系統。因此，在Remix 中編碼時，我腦中需要的思維模型要簡單10 倍：沒有全域狀態管理器，只需使用URL，更少的客戶端狀態，將所有邏輯移至伺服器，並使用cookie，無需使用完整堆疊中間的 REST API 非常簡單，只需將資料庫查詢移至「loader」函數即可。 ### 離開矩陣  然後，突然間，真相呈現在我面前，我服下了紅色藥丸。我的腦海中開始浮現出多個問題：Remix 不就像所有其他「古老而無聊」的框架（如 Rails、Laravel 和 Django）一樣嗎？幾十年來，我們一直在使用伺服器端渲染進行全端 Web 開發，但 JavaScript 黑手黨集體認為這種方法是垃圾，將所有內容移至客戶端才是未來。難道同一個黑手黨認為 Rails 一直都是對的嗎？用 JS 框架做所有那些過度設計的怪物不是正確的舉動嗎？我開始質疑一切。這種「新」的 Web 開發方式更加簡單、快速。 ### 我已經完成了 Next 和 Vercel 我透過 [Next.js 應用程式路由器](https://nextjs.org/docs/app) 達到了臨界點。以下是 Vercel 向 Next 推送的所有錯誤的完整清單： - 曾經簡單的：「getStaticProps」和「getServerSideProps」函數現在變得複雜而麻煩。目前，沒有特定的位置來新增 API 呼叫或資料庫查詢，您可以將它們寫入任何您想要的位置！在多年前使用 PHP 犯了同樣的錯誤之後，我們開始再次將業務邏輯與 UI 混合。難道前端開發者不吸取過去的教訓嗎？如果我刪除按鈕會發生什麼事？這是否會破壞我的使用者身份驗證流程，因為資料庫呼叫位於其中？您的前端應該 100% 可廢棄且可更換。你相對於競爭對手的競爭優勢在於業務邏輯，它應該與 UI 層完全隔離。  - 接下來是伺服器優先。這聽起來沒那麼糟吧？畢竟，這解決了 SEO 問題並立即向用戶展示新鮮內容。問題在於，大多數現有的 Next 程式碼庫都依賴客戶端程式庫，例如樣式元件和一些全域狀態管理器。這是什麼意思？隨著此類重大變化的不斷發生，您的應用程式將在幾週而不是幾年內變成遺留軟體。更多的時間花在保持所有依賴項最新上，而不是做重要的事情：發布功能。 - Vercel 從 Meta 聘請了多名 React 核心團隊成員。這帶來了嚴重的利益衝突，因為這些工程師現在（據稱）正在發布有利於 Next 的功能，而不是優先考慮那些可以幫助所有基於 React 的框架（如 Remix）的功能。  我再也受不了了。我對自己說：你知道嗎？我厭倦了一遍又一遍地重新學習相同的框架，我完全不同意這種新的範式。 毫不奇怪，其他內容創作者也經歷了類似的情況： https://youtu.be/zkCBSz353fc?si=z3-FDVgcB3xfp06h https://youtu.be/Zt8mO_Aqzw8?si=10fy1d-ZoB7t3Uc_ --- ## 啟蒙之路 我非常累。在厭倦了所有的 React 工具後，我開始了尋找更簡單的 Web 框架的旅程。以下是我一直在尋找的先決條件： - 含電池 - 約定優於配置 - 良好的開發體驗 - 現代化且高性能的前端 我的第一個反應是查看 [Stack Overflow Survey 2023](https://survey.stackoverflow.co/2023/#section-most-popular-technologies-web-frameworks-and-technologies) 中的頂級框架。我立即從清單中刪除了所有與 JS、C# 和 Java 相關的內容。我從來沒有興趣學習後兩個，它們看起來醜陋且冗長。所以剩下的選項是：Laravel (PHP)、Django (Python)、Rails (Ruby) 和 Phoenix (Elixir)。 Python 是我在網路工程學位期間使用的語言，我獲得了非常愉快的體驗。 Django 似乎遵循約定優於配置的理念，但最終讓我放棄它的是沒有一個好的內建工具來在前端工作。論壇上的大多數人都說他們使用[HTMX](https://htmx.org/) 和[Alpine](https://alpinejs.dev/)，但是，兩者都是您需要安裝的外部依賴項。 放棄Laravel 是非常困難的，因為它具有驚人的成本效益，有數百個官方軟體包可以處理新創公司可能需要的幾乎所有內容，例如託管、身份驗證、條紋支付等。對於前端，他們創造了[慣性。Node.js](https://inertiajs.com/)，這是一種非常簡單而優雅的方式，可以在前端使用 React 的同時保持 Laravel 的高生產力和強大功能。百分之百誠實地說，我沒有選擇 Laravel 的唯一原因是 PHP 的語法，它看起來很難看，到處都是一堆 `$` 和 `->`。 ### Ruby on Rails Ruby on Rails 無需介紹。它是 Web 開發框架的元年，其革命性的「15 分鐘建立部落格」至今仍令人印象深刻。在我開始抱怨我發現的所有問題之前，讓我們先從好的方面開始。 與 Python 類似，Ruby 是一種可以向非技術人員展示的語言，他們會理解該軟體想要做什麼。它是**迄今為止**我見過的最容易閱讀和最美麗的語言。我很快就意識到，[編寫視覺上令人愉悅的程式碼](https://world.hey.com/dhh/a-writer-s-ruby-2050b634) 是Rails 團隊的首要任務，這對我來說來說是新的。 更不用說 Rails 幾乎發明了「包含電池」和「約定優於配置」的哲學，所以這不會是一個問題。在一份文件中，我提供了任何類型的 Web 應用程式所需的一切。 在前端，有 [Hotwire](https://hotwired.dev/)，這是一種非常簡單且輕量級的方法，可以實現 SPA 框架提供的所有 UX 改進。我一直很好奇測試這個庫的極限，它看起來非常有前途。 好吧，Rails 在紙面上滿足了我想要的框架的所有先決條件。我們來試試吧！我在本地測試的第一件事是“railsscaffold”命令。我立即感到震驚。一個指令就能產生 CRUD 所需的一切？決不！  在 Node + React 領域，要實現相同的目標，我需要手動編寫所有程式碼（這裡沒有生成器）並安裝一堆程式庫，例如：Vite、prisma、express、react router、redux、redux-thunk 、 vitest、cypress 、react 測試庫、zod、typescript、eslint、prettier、1000 個不同的插件，甚至可能還有GraphQL 或tRPC。基本上就是一個已經有 900 個依賴項的 package.json。 在“railsscaffold”最初的震驚之後，當我從控制器打開程式碼時，我再次震驚了： ``` class ArticlesController < ApplicationController def index @articles = Article.all end def show @article = Article.find(params[:id]) end def new @article = Article.new end def create @article = Article.new(article_params) if @article.save redirect_to @article else render :new, status: :unprocessable_entity end end def edit @article = Article.find(params[:id]) end def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to @article else render :edit, status: :unprocessable_entity end end def destroy @article = Article.find(params[:id]) @article.destroy redirect_to root_path, status: :see_other end private def article_params params.require(:article).permit(:title, :body) end end ``` 這是所有後端程式碼嗎？只需幾行？這不可能！這非常簡單，看起來就像一個「低程式碼」工具。它簡單、優雅、可讀性極強，這是我們在 JS 領域很少見的。 好吧，好吧，你現在一定在想：「這個來自網路的瘋狂 React 開發者說他最終使用了 Elixir，所以 ruby 一定有問題！」。你是對的，我的匿名朋友，有些事情讓我很惱火，讓我們談談。 首先，我們需要解決房間裡的大象：從 React + Typescript 轉向動態類型語言並不容易。從我開始編寫程式碼的那一刻起，我的 VScode 上就沒有出現智慧感知或充滿程式碼建議的下拉式選單，我感到盲目和迷失。這是一種可怕的感覺，我可能會在函數名稱上輸入錯誤，直到網站投入使用時才意識到！我知道我們可以編寫測試，但這是我希望在 IDE 上立即辨識的錯誤類型，而不是在測試或部署期間辨識。 另一件我以為我會喜歡但最終討厭它的事情是：太多的魔法。在 Typescript 程式碼庫中，我可以點擊任何類別或函數的頂部，前往原始程式碼並查看其實作方式。在 Rails 上，我到底在哪裡進行驗證（例如）？我是否在控制器內建立私有函數？有專門的資料夾嗎？不，正確的位置是在模型內部。為什麼？因為這就是它的工作原理，所以您要么採用該約定，要么很難編寫 Ruby 程式碼。我根本無法對一切在幕後如何運作產生“直覺”，我必須盲目地相信維護者在組織一切方面做得很好。 為了解決我的挫折感，我開始寫前端程式碼。如何建立元件？ [部分](https://guides.rubyonrails.org/layouts_and_rendering.html#using-partials)。如何定義該元件的 prop 類型？沒有辦法做到這一點，您需要打開它並直觀地查找其中的所有變數。做一些互動怎麼樣？建立國家？嗯，有帶有 [Stimulus](https://stimulus.hotwired.dev/) 的 Hotwire，但是正如您所看到的，您需要手動建立“重新渲染”功能，它沒有找到一種方法像React 這樣改變狀態後自動重新渲染頁面。 ``` // src/controllers/slideshow_controller.js import { Controller } from "@hotwired/stimulus" export default class extends Controller { static targets = [ "slide" ] initialize() { this.index = 0 this.showCurrentSlide() } next() { this.index++ this.showCurrentSlide() } previous() { this.index-- this.showCurrentSlide() } showCurrentSlide() { this.slideTargets.forEach((element, index) => { element.hidden = index !== this.index }) } } ``` 我再一次感到沮喪。我非常接近找到完美的框架！如果 Rails 失敗，我想嘗試的下一個框架是什麼？靈丹妙藥。 ### 長生不老藥和鳳凰 我必須說實話，我已經沒有耐心了。我嘗試了多種不同的生態系統，我幾乎確信要堅持使用 Ruby on Rails，並放棄對完美的追求。直到我的 YouTube 推薦部分出現了一個影片： https://www.youtube.com/live/bfrzGXM-Z88?si=Xsa7yCKeVSY5R3sT 堅持，稍等！在這裡我們可以看到一位 React 開發人員說了很多關於函數式程式設計、Elixir 和 Phoenix Live View 的好話。也許我應該嘗試一下！ 我做的第一件事就是打開Elixir 和Phoenix 的文件，我真的很喜歡這樣一個事實：所有包都使用[Hex Docs](https://hexdocs.pm/) 以相同的方式進行記錄，您只需要取得習慣於單一介面以學習新事物。 另一個好處是，您只需閱讀文件即可真正學習 Elixir，無需昂貴的課程！在其他所有生態系統中，我必須透過付費課程學習語言，然後透過閱讀文件來學習框架。 然後是時候開始編寫程式碼了。很快我就明白函數式程式設計與 OOP 有很大不同。我們來做一個小小的比較： ``` // JS const obj = {name: "daniel"} obj.age = 25 // result: obj = {name: "daniel", age: 25} ``` ``` # Elixir obj = %{name: "daniel"} obj = Map.put(obj, :age, 25) # result: obj = %{name: "daniel", age: 25} ``` 或者您可以使用管道運算子透過更簡單的語法實現相同的效果： ``` # Elixir with pipe operator obj = %{name: "daniel"} |> Map.put(:age, 25) # result: obj = %{name: "daniel", age: 25} ``` 最初，您可能會發現它的可讀性較差且更複雜，但我保證隨著時間的推移它會變得有意義！嗯，至少對我來說是這樣。身為 React 開發人員，我已經習慣了到處都可以看到多個函數，甚至前端元件也是函數！更不用說建立類別有時被 JavaScript 黑手黨視為一種程式碼味道。我的大腦已經針對這種新範式進行了“塑造”，這對我來說很自然。自從我在大學獲得網路工程學位以來，我上過幾門關於物件導向程式設計的課程，但它從來沒有「受歡迎」。我無法將複雜的問題建模為類別和物件。隨著時間的推移，使用多個函數來「改變」一個變數是我在腦海中建模的方式。 主要框架怎麼樣？包含鳳凰電池嗎？約定優於配置？ **是的！** 老實說，生態系統與 Rails 不在同一水平，但已經達到了 95%。除非您需要非常具體的功能，Phoenix 都能滿足您的需求。 我幾乎被 Elixir 迷住了，我的清單中缺少兩件事：良好的開發人員體驗和現代/高效能的前端程式碼。 José Valim 宣布他正在嘗試為該語言加入類型，但 Elixir 目前還沒有這些類型，所以我很擔心。如何在沒有類型的情況下獲得智能感知和自動完成？很快我發現這些功能不一定相關。在 VScode 上安裝 [ElixirLS 擴充功能](https://marketplace.visualstudio.com/items?itemName=JakeBecker.elixir-ls) 後，我感到很驚訝。可以在隨機資料夾的隨機模組內定義函數，將其導入其他位置，並取得它的智慧感知和文件！我從靜態類型語言中獲得了這些好處，而無需編寫類型的麻煩，簡直太棒了！ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ 我對前端的最後一個擔憂是由 Phoenix [Live View](https://hexdocs.pm/phoenix_live_view/welcome.html) 解決的。在程式碼方面，這正是文件主頁中讓我信服的部分：  您可以為每個元件定義“props”，如果類型不匹配，您的 IDE 中會出現錯誤，就像 React 一樣！感人的！ 使用者體驗怎麼樣？每當使用者點擊連結時是否會載入整個頁面？一定不行！即時視圖與客戶端建立 WebSocket 連接，然後每次頁面轉換只是透過 Websocket 進行內容交換，不會發出新的 HTTP 請求。此外，所有狀態都在伺服器端進行管理，這意味著 Trello 等豐富的用戶體驗過去由於加載過多的 JavaScript 而在客戶端非常卡頓，現在變得非常快！ Elixir 處理所有複雜的狀態邏輯並將頁面的更新部分傳送到前端。看看這裡的完整解釋： https://youtu.be/wrmVk2czqMg?si=ZoWAlPjQC-svmV3Y 由於我們使用 WebSocket 來建立 UI，因此建立像 Twitter 這樣的「即時」應用程式只需要幾行程式碼！ https://youtu.be/MZvmYaFkNJI?si=gAow6oIjgf8_OTkg ## 結論 可以肯定地說，「完美的技術堆疊」並不存在。解決所有問題的靈丹妙藥是我們在腦中創造的幻覺，以不斷尋找和建構最優化的工具。 然而，在個人層面上，完美的堆疊確實存在。因為每個開發人員都有偏好，您可以輕鬆找到適合您標準的工具。如果你有和我類似的旅程，完美的可能就是長生不老藥和鳳凰！所以試試看吧，也許你會像我現在一樣喜歡它。 如果您讀到了這篇文章的結尾，那您就太棒了！非常感謝您抽出寶貴的時間，希望我能為您的職業生涯帶來一些價值。  --- 原文出處：https://dev.to/danielbergholz/from-nextjs-to-rails-then-elixir-my-journey-through-reactjs-burnout-h8d
## 簡介 本文列出了五個不太受歡迎的優秀專案，您應該嘗試一下。 🔥 這些工具旨在改進**資料處理**、**API 開發**、**後端測試**、**身份驗證**和**安全隧道**。 諸如此類的開源專案依賴社群支持🙏，因此請考慮探索並為這些儲存庫加註星標，以促進它們的發展。  *** ## 1. [集算器](http://scudata.com) **- 資料處理** > 💡 集算器是一種用於資料處理的腳本語言，具有豐富的函式庫函數和強大的語法。  集算器是一個針對結構化和半結構化資料的計算和處理引擎。集算器既不是SQL系統，也不是NoSQL技術（如MongoDB），而是採用自創的SPL（結構化處理語言）語法，編碼更簡單，可以利用現有的資料處理技術建立高效的程式。 集算器是**純Java**編寫的，可以輕鬆為您的Java🍵應用程式加入強大的資料處理功能，但非Java應用程式可以透過RESTful API呼叫集算器。 ### 熱門常見問題解答🤔 > **⬇️集算器可以執行在哪些平台上？** 由於它純粹是用 Java 建置，因此可以在任何配備 JVM（Java 虛擬機）、雲端伺服器甚至容器的作業系統中流暢執行。 😎 > **⬇️集算器可以基於現有資料庫運作嗎？** 是的當然！集算器支援數十種資料來源，包括資料庫、文字、excel、json/xml、web服務等。 > **⬇️ 為什麼要放棄 SQL 而選擇集算器？** 簡化的逐步程式碼，易於編寫和除錯。相較於SQL降低N倍的開發、硬體、維運成本。 > 🟢我最近寫了一篇關於這個工具的文章，重點介紹了它的強大功能。看看吧👇。 https://dev.to/shricodev/one-must-have-tool-for-anyone-in-data-field-2jek > 如果你想更深入地了解這個工具的潛力，**[jbx1279](https://dev.to/jbx1279)**分享了一些關於集算器和SPL本身的富有洞察力的文章。請務必也檢查一下它們。 https://github.com/SPLWare/esProc *** ## 2. [Firecamp](https://firecamp.dev/) **- 郵差替代方案** > 💡 API 開發平台，幫助開發人員輕鬆設計、開發、測試和記錄他們的 API。  Firecamp 是開放原始碼 Postman 的替代方案，具有 VScode DX，這是一個優先考慮開發人員體驗的 API 開發平台，並為設計、測試和記錄 API 提供無縫環境。 🎯 借助 Firecamp，跨工作區和團隊就 API 集合進行協作，並更快地建立 API，而無需在工具和應用程式之間切換。文件、CLI、CI/CD 一站式提供。 > **⬇️ 從 Postman 切換到 Firecamp 對我來說有挑戰性嗎？** 您可以將 Postman 腳本和資料（例如 **API Collection** 和 **環境變數**）無縫傳輸到 Firecamp，沒有任何問題。  https://github.com/firecamp-dev/firecamp *** ## 3. [Keploy](https://keploy.io/) **- 後端測試** > 💡 為您的應用程式產生實際有效的測試和存根！  Keploy 是您的開源、以開發人員為中心的後端測試工具。它使工程團隊的後端測試變得簡單且有效率。使用 Keploy，我們不必編寫手動測試用例。 它記錄 API 互動和預期回應，並產生測試案例和資料模擬，使我們的工作變得輕鬆高效，顯著加快發布速度並增強可靠性。 📈 > **⬇️ 它是一個單元測試框架嗎？還是它完全取代了單元測試？** Keploy 與「go-test」、「Pytest」或「Jest」等單元測試框架配合得很好，可簡化測試流程並節省高達 80% 的工作。雖然它涵蓋了大多數情況，但您仍然可以選擇為非 API 可呼叫方法編寫測試。 > **⬇️ 我需要更改程式碼才能將 Keploy 整合到我的應用程式中嗎？** 不需要。Keploy 可以很好地與您現有的程式碼庫配合，無需更改程式碼。  https://github.com/keploy/keploy *** ## 4. [Hanko](https://hanko.io) **- 金鑰驗證** > 💡 支援 FIDO2 和 WebAuthn 標準的無密碼身份驗證伺服器。  Hanko 是一款輕量級開源用戶身份驗證解決方案，可帶您踏上超越密碼的旅程。它支援 FIDO2 和 WebAuthn 標準，提供安全、無縫的使用者身份驗證體驗。 > **⬇️ Hanko 如何運作？** Hanko 的工作原理是使用使用者自己的裝置（例如智慧型手機、筆記型電腦或安全金鑰）註冊和驗證使用者。這些裝置可作為加密令牌，無需密碼或其他憑證即可證明使用者的身分。 Hanko 還支援各種身份驗證方法，例如行動應用程式中的生物辨識或 OAuth 登入。 > **⬇️ 我該如何開始使用 Hanko？** 您可以透過註冊免費帳戶並按照文件和教學課程開始使用 Hanko。對於生產用途，請選擇 Hanko Cloud。 > 🟢 我最近使用 Hanko Passkeys 身份驗證建立了一個專案。查看**[此處](https://github.com/shricodev/pdfwhisper-openai)**。  https://github.com/teamhanko/hanko *** ## 5. [Zrok](https://zrok.io/) **- Ngrok 類固醇** > 💡 Ngrok 的替代品，提供增強的功能和免費的 SaaS 型號。  Zrok 是一個建立在 **OpenZiti** 之上的工具，有助於共享正在執行的服務，例如 Web 伺服器或網路套接字，或安全地將靜態檔案目錄共享到網際網路。它是 Ngrok 的替代品，但具有一些增強功能和**免費 SaaS** 型號。 借助 Zrok，您可以為應用程式建立安全隧道，從而更輕鬆地共享和協作專案。 > **⬇️ 使用 Zrok 相對於 Ngrok 有什麼好處？** Zrok 擁有內建的身份驗證系統、用於管理隧道的 Web 儀表板以及免費的 SaaS 模型。它也是完全**可自我託管**。 > **⬇️ 我該如何開始使用 Zrok？** 若要開始使用 Zrok，請下載適合您平台的 Zrok 用戶端或使用 Web 介面建立隧道。您也可以使用 Zrok CLI 從命令列建立和管理隧道。  https://github.com/openziti/zrok *** > 如果您認為您使用的任何其他方便的專案沒有應有的受歡迎，請在下面的評論部分分享。 👇 非常感謝您的閱讀！ 🎉🫡 --- 原文出處：https://dev.to/shricodev/top-5-underrated-open-source-projects-that-no-one-talks-about-2gki
這是[使用 Express、Sequelize 和 Postgres 建立 API](https://www.oriechinedu.com/posts/performing-crud-with-sequelize/) 的第三部分。在[第二部分](https://www.oriechinedu.com/posts/performing-crud-with-sequelize/)中，我們建立了簡單的API端點來示範Sequelize中的CRUD操作。在本文中，我們將重點放在為第二部分中建立的 API 端點編寫端到端測試。 ### 術語解釋 - **端對端測試** - 一種測試類型，用於測試應用程式從開始到結束的流程是否如預期運作。這也稱為功能測試。此類測試的一個範例是測試端點或路由，其中涉及測試端點工作所需的所有內容，例如資料庫連接、依賴項等。 - **測試執行器** - 在給定目錄或檔案中取得原始程式碼（測試）、執行測試並將結果寫入控制台或任何指定位置的程式庫或工具，例如 Jest、Mocha。 - **Jest** - [Jest](https://jestjs.io/) 是 Facebook 開發的 JavaScript 測試框架。它以最少的配置開箱即用，並具有內建的測試執行器、斷言庫和模擬支援。 - [**Supertest**](https://www.npmjs.com/package/supertest) - 用於測試 Node.js HTTP 伺服器的函式庫。它使我們能夠以程式設計方式向 HTTP 伺服器發送 HTTP 請求（例如 GET、POST、PATCH、PUT、DELETE）並獲取結果。 現在我們已經解釋了基本術語，讓我們深入了解主要業務。 如果您一直按照先前的[文章](https://www.oriechinedu.com/posts/performing-crud-with-sequelize/)進行操作，那麼請在您最喜歡的文字編輯器中開啟它，否則克隆使用的儲存庫[此處](https://github.com/oriechinedu/sequelize-with-postgres-tutorial)。 **第 1 步 - 安裝 Jest 和 supertest** 打開終端機並“cd”到專案根目錄並執行以下命令： ``` npm install --save-dev jest supertest ``` **步驟 2 - 設定 Jest** 打開“package.json”並將以下程式碼新增至其中。 ``` "jest": { "testEnvironment": "node", "coveragePathIgnorePatterns": [ "/node_modules/" ] }, ``` 這是我們測試 API 時需要設定 jest 的基本配置。您希望 `jest` 忽略的任何檔案都放置在 `"coveragePathIgnorePatterns"` 內。 `"coveragePathIgnorePatterns"` 指定一個與要排除的目錄相符的正規表示式，在我們的例子中，我們希望它忽略 `node_modules` 目錄。 接下來我們新增“test”腳本。在 `package.json` 的 `scripts` 部分中，加入以下腳本： ``` "test": "jest" ``` **步驟 3 - 測試配置** 現在，讓我們確認「jest」已準備好執行我們的測試。在終端機中執行“npm test”。您會注意到控制台上列印如下所示的錯誤，這表示「jest」已設定。  讓我們新增一個簡單的測試來驗證配置。建立一個名為「tests」的新目錄並新增一個新檔案「sample.test.js」。在「sample.test.js」中，加入以下程式碼： ``` describe('Sample Test', () => { it('should test that true === true', () => { expect(true).toBe(true) }) }) ``` 現在，執行“npm test”，您將得到如下所示的輸出：  ##### Jest 如何辨識測試檔？ Jest 以三種方式辨識測試文件： - 副檔名為「.test.js」的文件 - 副檔名為「.spec.js」的文件 - `__tests__` 資料夾或目錄中的所有檔案。 ## 測試 API 端點 現在我們已經設定了測試環境，是時候開始測試 API 端點了。由於我們的端點需要向資料庫發出請求，因此我們需要設定一個測試資料庫。設定測試資料庫的原因是每次執行測試時我們都會刪除該資料庫。每次執行測試時刪除資料庫可確保測試的完整性。也就是說，如果一個測試是在資料庫中建立一個「post」記錄，我們要確保在測試執行之前資料庫中沒有「post」記錄，這樣，我們就可以確定得到的結果從測試中。 **第 4 步 - 建立測試資料庫** 在本文的[第一部分](https://www.oriechinedu.com/posts/getting-started-with-sequelize-and-postgres/)中，我們建立了兩個資料庫，一個用於開發，另一個用於測試。如果您尚未建立測試資料庫，請依照[連結](https://www.oriechinedu.com/posts/getting-started-with-sequelize-and-postgres/)建立測試資料庫。 **步驟 5 - 設定測試腳本** 我們需要以下腳本： - `pretest` - `pretest` 是一個 npm 腳本，當呼叫 `npm test` 指令時會自動呼叫。我們將掛接命令來更改環境以進行測試，並在每次測試執行之前刷新資料庫。 - `migrate:reset`：此命令將負責在每次測試執行之前刷新資料庫。 現在編輯“package.json”的“scripts”，如下所示： ``` "scripts": { "start-dev": "nodemon index.js", "migrate": "npx sequelize-cli db:migrate", "migrate:reset": "npx sequelize-cli db:migrate:undo:all && npm run migrate", "test": "cross-env NODE_ENV=test jest --testTimeout=10000", "pretest": "cross-env NODE_ENV=test npm run migrate:reset" } ``` 腳本修改需要注意的地方： - [`cross-env`](https://www.npmjs.com/package/cross-env) - 用於設定環境變數的與作業系統無關的套件。我們用它將`NODE_ENV`設為`test`，以便我們的測試可以使用測試資料庫。執行以下命令來安裝跨環境。 ``` npm i -D cross-env ``` - `--testTimeout` 標誌 - 這會增加 Jest 的預設逾時時間，即 5000 毫秒。這很重要，因為測試執行者需要在執行測試之前刷新資料庫。 **第 6 步 - 測試腳本** ``` npm test ``` 如果一切正常，您應該在終端機上看到以下輸出：  仔細觀察上面的螢幕截圖，您會注意到一行 _`using environment "test"`_ 表示 `cross-env` 已更改了 `NODE_ENV`。 **最後一步 - 測試路由/端點** 現在，讓我們開始為端點編寫測試。在測試目錄中建立一個名為routes.test.js的文件 ``` touch tests/routes.test.js ``` - **測試建立後端點** 將以下程式碼複製到“tests/routes.test.js”中： ``` const request = require('supertest') const app = require('../server') describe('Post Endpoints', () => { it('should create a new post', async () => { const res = await request(app) .post('/api/posts') .send({ userId: 1, title: 'test is cool', }) expect(res.statusCode).toEqual(201) expect(res.body).toHaveProperty('post') }) }) ``` - `describe` 函數用於將相關測試分組在一起 - `it` 是執行實際測試的 `test` 函數的別名。 -“expect”函數使用一組“matcher”函數測試值。 請造訪 [Jest 文件](https://jestjs.io/docs/en/api.html) 以取得 jest 函數的完整清單和詳細資訊。 現在，執行測試 ``` npm test ``` 輸出如下圖所示：  有關所有端點測試的完整程式碼，請檢查[儲存庫](https://github.com/oriechinedu/sequelize-with-postgres-tutorial/blob/master/tests/routes.test.js)。 ### 結論 我們已經能夠完成為與資料庫互動的 API 端點編寫測試的過程。在本文的最後部分，我將撰寫有關將 CI/CD 和程式碼覆蓋工具整合到測試環境的文章。在那之前請繼續關注。 如果您對改進文章有任何疑問或建議，請隨時與我聯繫。您也可以透過下面的評論部分分享您的想法。謝謝！ _本文最初發表在我的[部落格](https://www.oriechinedu.com/posts/testing-nodejs-express-api-with-jest-and-supertest/)_ --- 原文出處：https://dev.to/nedsoft/testing-nodejs-express-api-with-jest-and-supertest-1km6
您是否想過如何使用 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 文件，如下所示：  ## 結論 本文是一篇教程，介紹如何開始使用 python 和 pytest 框架為 API 編寫自動化測試以及如何產生一個報告 html。 您可以在[此處](https://github.com/aliciamarianne1507/tests_python)存取本教學中使用的專案。 我希望這些內容對您有用。 如果您有任何疑問，請隨時與我聯繫！ 親親，下週見💅🏼 --- 原文出處：https://dev.to/m4rri4nne/automating-your-api-tests-using-python-and-pytest-23cc
> _“信任，但驗證”_（“信任，但驗證”） > -- [俄羅斯諺語](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 上的來源電子表格中，請告訴我。如果它符合我上面列出的標準，我很樂意將其加入到列表中。 言歸正傳，列表如下： ---  ## \#20。 [企業應用架構模式](https://amzn.to/2jSqwQ5) ### 作者：Martin Fowler（_3 路並列 #19 和 #18_） #### 推薦 13.0% > 這本書其實是兩本書合而為一。第一部分是有關開發企業應用程式的簡短教程，您可以從頭到尾閱讀該教程以了解本書課程的範圍。下一部分，即本書的大部分內容，是對模式本身的詳細參考。每個模式都提供使用和實現訊息，以及詳細的 Java 或 C# 程式碼範例。整本書還配有豐富的UML圖來進一步解釋概念。 > > 有了這本書，您將擁有做出有關建立企業應用程式的重要架構決策所需的知識，以及建立它們時使用的經過驗證的模式。 > > -- [Amazon.com](https://amzn.to/2jSqwQ5) ---  ## \#19。 [清潔架構：軟體結構與設計工匠指南](https://amzn.to/2jTxLHt) ### 作者：羅伯特·C·「鮑伯叔叔」·馬丁 #### 建議 13.0%（_3 路與 #20 和 #18 平手_） > - 了解軟體架構師需要實現什麼目標，以及實現它的核心規則和實踐 > - 掌握尋址功能、元件分離和資料管理的基本軟體設計原則 > - 了解程式設計範式如何透過限制開發人員可以執行的操作來施加紀律 > - 了解什麼是至關重要的，什麼只是“細節” > - 為 Web、資料庫、胖客戶端、控制台和嵌入式應用程式實施最佳的高級結構 > - 定義適當的邊界和層，並組織元件和服務 > - 了解設計和架構為何出錯，以及如何預防（或修復）這些故障 > > -- [Amazon.com](https://amzn.to/2jTxLHt) ---  ## \#18。 [電腦程式設計的藝術](https://amzn.to/2XKk8Ik) ### 作者：唐納德高德納 #### 建議 13.0%（_3 路與 #20 和 #19 平手_） > 這部宏偉的傑作全面概述了各種演算法及其分析。現在，《電腦程式設計的藝術》已經是第三版了，其中包含作者的大量修訂，並包括許多新練習。 > > 儘管這本書是幾十年前構思的，但它仍然是一部永恆的經典。本書最大的優點之一是每一章都包含大量問題。作者精心挑選問題，並根據難度進行索引。解決大量此類問題將幫助您深入了解圍繞給定主題的問題。此外，練習還包含各種經典問題。 > > -- [Amazon.com](https://amzn.to/2XKk8Ik) ---  ## \#17。 [程式碼：電腦硬體與軟體的隱藏語言](https://amzn.to/2XYXZKA) ### 查爾斯·佩措爾德 #### 15.9% 推薦（_與 #16_ 並列） > 手電筒、英國入侵、黑貓和蹺蹺板與電腦有什麼關係？在《程式碼》中，他們向我們展示了操縱語言和發明新的相互交流方式的巧妙方式。透過 _CODE_，我們看到這種獨創性和我們人類的溝通衝動是如何推動過去兩個世紀的技術創新的。 > > 作者 Charles Petzold 使用日常物品和熟悉的語言系統（例如點字和莫爾斯電碼），為任何想了解電腦和其他智慧機器的秘密內部生活的人編織了一個富有啟發性的敘述。 > > 這是一個插圖巧妙且非常易於理解的故事，在整個過程中，您會發現自己獲得了理解當今 PC、數位媒體和網路世界的真實背景。無論您的技術水平如何，CODE 都會讓您著迷，甚至可能喚醒您內心的技術愛好者。 > > -- [Amazon.com](https://amzn.to/2XYXZKA) ---  ## \#16。 [敏捷軟體開發：原則、模式與實踐](https://amzn.to/2XT4fj3) ### 作者：羅伯特·C·「鮑伯叔叔」·馬丁 #### 15.9% 推薦（_與 #17_ 並列） > 本書由軟體開發人員為軟體開發人員撰寫，是最新軟體開發方法的獨特集合。作者包括 OOD、UML、設計模式、敏捷和 XP 方法，並詳細描述了 C++ 和 Java 中可重複使用程式的完整軟體設計。它使用實用的解決問題的方法，展示瞭如何開發物件導向的應用程式——從分析的早期階段，到底層設計，再到實現。引導讀者了解設計師的想法—展示整個軟體設計過程中出現的錯誤、死胡同和創意見解。本書涵蓋：靜力學和動力學；類設計原則；複雜性管理；包裝設計原理；分析與設計；模式和範式交叉。一一解釋 OOD 的原理，然後透過大量範例、完整的設計和案例研究來示範它們。涵蓋 C++ 和 OOD 應用程式中的陷阱、缺陷和解決方法，然後展示如何使用敏捷方法。詳細討論了大型軟體的設計和開發方法。對建築安全系統進行了三章深入的單一案例研究。適合想要了解如何使用最先進的方法設計物件導向軟體的軟體工程師、程式設計師和分析師。 > > -- [Amazon.com](https://amzn.to/2XT4fj3) ---  ## \#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) ---  ## \#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) ---  ## \#13。 [破解程式設計面試：189題程式設計題及解答](https://amzn.to/2XPSwlg) ### 作者：蓋爾‧拉克曼‧麥克道威爾 #### 建議 17.4%（_3 路與 #15 和 #14 並列_） > - 189 道程式設計面試問題，從基礎知識到最棘手的演算法問題。 > - 如何匯出每個解決方案的演練，以便您可以學習如何自己實現。 > - 有關如何解決 189 個問題的提示，就像您在真實面試中得到的一樣。 > - 五種經過驗證的解決演算法問題的策略，讓你可以解決你沒見過的問題。 > - 廣泛涵蓋基本主題，例如大 O 時間、資料結構和核心演算法。 > - 深入了解 Google 和 Facebook 等頂尖公司如何聘用開發人員。 > - 準備和應對面試軟性方面的技巧：行為問題。 > - 對於面試官和公司：關於什麼是好的面試問題和招募流程的詳細資訊。 > > -- [Amazon.com](https://amzn.to/2XPSwlg) ---  ## \#12. [不要讓我思考：網路可用性的常識性方法](https://amzn.to/2XPjDwF) ### 史蒂夫·克魯格 #### 18.8% 推薦（_與#11_並列） > _Don't Make Me Think_ 是 Steve Krug 寫的一本關於人機互動和網路可用性的書。本書的前提是，一個好的軟體程式或網站應該讓使用者盡可能輕鬆、直接地完成他們的預期任務。克魯格指出，人們善於滿足問題，或採用第一個可用的解決方案來解決問題，因此設計應該利用這一點。他經常引用 Amazon.com 作為精心設計的網站的例子，該網站能夠實現高品質的交互，儘管該網站每天都變得越來越大、越來越複雜。 > > 這本書本身旨在成為簡潔（簡潔）和重點突出的寫作範例。根據該書的介紹，其目標是製作一篇可供高管在兩個小時的飛機飛行中閱讀的文本。 > > -- [維基百科](http://bit.ly/2XSAhLY) ---  ## \#11。 [The Clean Coder：專業程式設計師行為準則](https://amzn.to/2XMluCs) ### 作者：羅伯特·C·「鮑伯叔叔」·馬丁 #### 18.8% 推薦（_與 #12_ 並列） > 在不斷的不確定性和不間斷的壓力中忍受並取得成功的程式設計師有一個共同的屬性：他們非常關心建立軟體的實踐。他們把它當作一門手藝。他們是專業人士。 > > 在《乾淨的編碼器：專業程式設計師的行為準則》中，傳奇軟體專家 Robert C. Martin 介紹了真正的軟體工藝的學科、技術、工具和實踐。本書充滿了實用的建議——從估計和編碼到重構和測試。它涵蓋的不僅僅是技術：它是關於態度。馬丁展示瞭如何以榮譽、自尊和自豪的態度進行軟體開發；工作良好，工作乾淨；忠實地溝通和評估；清晰而誠實地面對困難的決定；並理解深刻的知識伴隨著採取行動的責任。 > > -- [Amazon.com](https://amzn.to/2XMluCs) ---  ## \#10. [軟體技能：軟體開發人員的生活手冊](https://amzn.to/2XR9u2y) ### 約翰‧桑梅茲 #### 23.2% 推薦（_與#11_並列） > _軟技能：軟體開發人員生活手冊_ 是作為技術專業人員全面、令人滿意的生活的指南。在其中，開發人員兼生活教練 John Sonmez 就重要的「軟」主題向開發人員提供建議，例如職業和生產力、個人理財和投資，甚至健身和人際關係。這本有趣的書由 71 個短章組成，邀請您隨心所欲地閱讀。每章末尾的「採取行動」部分向您展示如何快速獲得結果。軟技能將幫助您成為更好的程式設計師、更有價值的員工以及更快樂、更健康的人。 > > -- [Amazon.com](https://amzn.to/2XR9u2y) ---  ## \#9。 [Peopleware：高效率的專案與團隊](https://amzn.to/2XR6keY) ### 湯姆·德馬科和提摩西·利斯特 #### 23.2% 推薦（_與 #12_ 並列） > _Peopleware_ 是一本有關軟體組織管理的熱門書籍。書的第一章聲稱，「我們工作的主要問題本質上與其說是技術問題，不如說是社會學問題」。這本書探討了社會學或「政治」議題，例如團隊化學反應和團隊凝聚力、工作環境中的「流動時間」和安靜以及高流動成本。其他主題包括個人工作觀點與企業意識形態之間的衝突、企業熵、「團隊滅絕」和工作空間理論。 > > 作者將大多數主題呈現為由一些具體故事或其他資訊支持的原則。例如，「義大利麵晚餐」一章介紹了一個虛構的例子，一位經理邀請一個新團隊來吃晚飯，然後讓他們作為一個團隊購買和準備飯菜，以便讓一線團隊取得成功。其他章節使用現實生活中的故事或引用各種研究來說明所提出的原則 > > -- [維基百科](http://bit.ly/2XMFrJf) ---  ## \#8。 [程式珍珠](https://amzn.to/2XNxWlf) ### 喬恩‧本特利 #### 26.1% 推薦 > 電腦程式設計有很多面貌。弗雷德布魯克斯 (Fred Brooks) 在《人月神話》中描繪了一幅宏偉的圖畫。他的文章強調了管理在大型軟體專案中的關鍵作用。 Steve McConnell 在 Code Complete 中更詳細地教授了良好的程式設計風格。這些書中的主題是優秀軟體的關鍵，也是專業程式設計師的標誌。然而不幸的是，這些合理的工程原理的熟練應用並不總是令人興奮——直到軟體按時完成並且不出意外地工作。 > > 本書中的專欄介紹了該行業更迷人的方面：編程珍珠，其起源超出了紮實的工程，而是在洞察力和創造力的領域。正如天然珍珠是從激怒牡蠣的沙粒中生長出來的一樣，這些編程珍珠也是從激怒真正程式設計師的實際問題中生長出來的。這些程式很有趣，並且教授重要的程式技術和基本設計原理。 > > -- [Amazon.com](https://amzn.to/2XNxWlf) ---  ## \#7。 [有效處理遺留程式碼](https://amzn.to/2Y5hNvR) ### 麥可費瑟斯 #### 27.5% 推薦（_與#6_並列） > 你的程式碼容易修改嗎？當你改變它時，你能得到幾乎即時的回饋嗎？你到底懂不懂呢？如果這些問題中任何一個的答案是否定的，那麼您就有遺留程式碼，並且它會消耗您的開發工作的時間和金錢。 > > 在本書中，Michael Feathers 提供了從頭到尾的策略，以便更有效地處理大型、未經測試的遺留程式碼庫。本書借鑒了邁克爾為其著名的物件導師研討會建立的材料：邁克爾在指導中使用的技術，幫助數百名開發人員、技術經理和測試人員控制他們的遺留系統。涵蓋的主題包括： > > - 了解軟體變更的機制：新增功能、修復錯誤、改進設計、優化效能 > - 將遺留程式碼放入測試工具中 > - 編寫測試來防止引入新問題 > - 可用於任何語言或平台的技術 - 包含 Java、C++、C 和 C# 範例 > - 準確地辨識需要更改程式碼的位置 > - 處理非物件導向的遺留系統 > - 處理看起來沒有任何結構的應用程式 > > -- [Amazon.com](https://amzn.to/2Y5hNvR) ---  ## \#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) ---  ## \#5。 [重構：改進現有程式碼的設計](https://amzn.to/2XQ2KlF) ### 馬丁·福勒 #### 33.3% 推薦（_與#4_並列） > 二十多年來，全世界經驗豐富的程式設計師一直依靠 Martin Fowler 的_重構_來改進現有程式碼的設計並增強軟體的可維護性，並使現有程式碼更易於理解。 > > 這個備受期待的新版本已經全面更新，以反映程式設計領域的重大變化。 _Refactoring_，第二版，提供更新的重構目錄，包括 JavaScript 程式碼範例，以及演示無需類別的重構的新功能範例。 > > 與原版一樣，此版本解釋了什麼是重構；為什麼你應該重構；如何辨識需要重構的程式碼；以及如何真正成功地做到這一點，無論您使用什麼語言。 > > - 了解重構的流程和一般原則 > - 快速應用有用的重構，使程式更易於理解和更改 > - 辨識程式碼中預示重構機會的“難聞氣味” > - 探索重構，每個重構都有解釋、動機、機制和簡單的範例 > - 為您的重建置立可靠的測試 > - 認識重構的權衡與障礙 > > -- [Amazon.com](https://amzn.to/2XQ2KlF) ---  ## \#4。 [設計模式：可重複使用物件導向軟體的要素](https://amzn.to/2jY1a37) ### 作者：Erich Gamma、Richard Helm 與 Ralph Johnson #### 33.3% 推薦（_與 #5_ 並列） > 本書不是物件導向技術或設計的介紹。許多書已經在這方面做得很好......這也不是一篇高級論文。這是一本關於設計模式的書，描述了物件導向軟體設計中特定問題的簡單而優雅的解決方案...一旦您理解了設計模式並有一個「啊哈！」的感覺。 （不僅僅是與它們的「嗯？」體驗，您將永遠不會以相同的方式思考物件導向的設計。您將擁有可以使您自己的設計更加靈活、模組化、可重用和易於理解的見解- -這就是您首先對物件導向技術感興趣的原因，對吧？ > > -- [Amazon.com](https://amzn.to/2jY1a37) ---  ## \#3。 [程式碼大全：軟體建置實用手冊](https://amzn.to/2jY2PWp) ### 史蒂夫麥康奈爾 #### 44.9% 推薦 > Steve McConnell 的原始《Code Complete》被廣泛認為是最好的實用程式指南之一，十多年來一直在幫助開發人員編寫更好的軟體。現在，這本經典書籍已通過前沿實踐和數百個新程式碼示例進行了全面更新和修訂，闡釋了軟體建置的藝術和科學。麥康奈爾從研究、學術界和日常商業實踐中獲得了豐富的知識體系，將最有效的技術和必須了解的原則綜合成清晰、務實的指導。無論您的經驗水平、開發環境或專案規模如何，本書都會啟發並激發您的思考，並幫助您建立最高品質的程式碼。 > > - 發現永恆的技術和策略，幫助您： > - 最小複雜度、最大創造力的設計 > - 獲得協作開發的好處 > - 應用防禦性程式設計技術來減少和清除錯誤 > - 利用機會重構或改進程式碼，並安全地進行 > - 使用適合您專案的施工實踐 > - 快速有效地除錯問題 > - 及早正確解決關鍵施工問題 > - 將品質貫穿專案的開始、中期和結束階段 > > -- [Amazon.com](https://amzn.to/2jY2PWp) ---  ## \#2。 [務實的程式設計師：從新手到大師](https://amzn.to/2jY48Vh) ### 安德魯·亨特和戴夫·托馬斯 #### 47.8% 推薦 > 程式設計師是經過訓練的工匠，可以使用一組特定的工具（編輯器、物件管理器、版本追蹤器）來產生將在某些環境（硬體元件上的作業系統）中執行的特定類型的產品(程式).與其他工藝一樣，電腦程式設計催生了一系列智慧，其中大部分不是在大學或認證課程中教授的。隨著時間的推移，大多數程式設計師透過獨立實驗掌握了所謂的技巧。在《務實的程式設計師》中，安德魯·亨特和大衛·托馬斯將他們在各自作為軟體設計師和程式碼編寫者的職業生涯中發現的許多真理編入了法律。 > > 作者的一些實用主義要點是具體的，其實施路徑也很明確。例如，他們建議讀者學習一種文字編輯器，並將其用於所有用途。他們還建議即使是最小的專案也使用版本追蹤軟體，並宣傳學習正規表示式語法和文字操作語言的優點。其他（也許更有價值）的建議則更加輕鬆。在除錯部分，有人指出，“如果您看到蹄印，請想到馬，而不是斑馬。”也就是說，懷疑一切，但開始在最明顯的地方尋找問題。有一些關於估算時間和費用以及將測試整合到開發過程中的建議。你需要一本《務實的程式設計師》有兩個原因：它比你費心去表達的更清晰地展示了你自己累積的智慧，它向你介紹了你可能還沒有考慮過的工作方法。正在工作的程式設計師會喜歡這本書。 > > -- [大衛沃爾來自 Amazon.com](https://amzn.to/2jY48Vh) --- ## 最後，最受軟體開發人員推薦的一本書： ---  ## \#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
原文出處：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 **謝謝** 非常感謝您閱讀我的部落格🙂。
原文出處：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/訂閱）* * 每日在您的收件匣中獲取機會！
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 在命名和寫註解方面有提供一些很好的經驗法則。 --- 以上，希望對大家有幫助！
面試的時候，通常面試官會問：你有什麼問題想問我們嗎？ 就跟公司面試你一樣，其實你也在面試公司。應該把握機會問對問題。 這邊有幾個重要問題，給你參考，下次面試可以問問看。 - 原文出處：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 開源專案做貢獻嗎？可以去研討會演講嗎？是否需要任何批准？** 如果你有這些興趣，就要問問。這些都是職業發展的寶貴機會。 --- # 結論 公司會展現好的一面，吸引面試者。你需要看穿表面宣傳、弄清楚真實狀況。找到有興趣的問題，不斷提問，直到放心為止。 不要問你本來就該知道的事情。職位描述看清楚，公司網站跟之前的對話看清楚，問重複問題會很鳥。 祝你好運，感謝閱讀！
在軟體產業工作超過十年之後，我總結出了二十條原則，跟大家分享如下： - 原文出處：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. **完美的代碼不存在**——最好接受這事實，而不是浪費時間、追逐不可能的事情。
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
