## 介紹 編寫乾淨的程式碼是每個軟體開發人員的基本技能。乾淨的程式碼不僅使您的程式碼庫更易於維護和理解，而且還能促進團隊成員之間的協作。在這篇綜合文章中，我們將探討什麼是乾淨的程式碼、為什麼它很重要，並為您提供一組最佳實踐和原則來幫助您編寫乾淨且可維護的程式碼。 - 原文出處：https://dev.to/favourmark05/writing-clean-code-best-practices-and-principles-3amh --- ## 什麼是乾淨程式碼？ 乾淨的程式碼是易於閱讀、易於理解且易於修改的程式碼。它是沒有不必要的複雜性、冗餘和混亂的程式碼。乾淨的程式碼遵循一組約定和最佳實踐，使其更加一致，使多個開發人員更容易無縫地處理同一個專案。 ## 為什麼乾淨的程式碼很重要？ 1. **可讀性**：乾淨的程式碼易於閱讀，這意味著任何人 - 包括未來的你 - 都可以快速理解它。這減少了掌握程式碼功能所需的時間，從而加快了開發和除錯速度。 2. **可維護性**：程式碼的讀取次數多於編寫次數。當您編寫乾淨的程式碼時，隨著時間的推移，維護和擴展應用程式將變得更加容易。這在軟體開發生命週期中至關重要，因為專案經常發展和成長。 3. **協作**：簡潔的程式碼鼓勵協作。當您的程式碼乾淨且組織良好時，其他團隊成員就可以有效地處理它。這使得劃分任務和同時處理程式碼庫的不同部分變得更容易。 4. **減少錯誤**：乾淨的程式碼可以減少引入錯誤的可能性。難以理解的程式碼在修改或增強過程中更容易出錯。 5. **效率**：乾淨的程式碼就是高效率的程式碼。它通常執行速度更快並且使用更少的資源，因為它避免了不必要的操作和複雜性。 現在我們了解了為什麼乾淨的程式碼很重要，讓我們深入研究一些最佳實踐和原則來幫助您編寫乾淨的程式碼。 ## 編寫簡潔程式碼的最佳實踐和原則 1. **有意義的變數和函數名稱** 對變數、函數、類別和其他辨識碼使用描述性名稱。精心選擇的名稱可以傳達實體的目的，使程式碼更容易理解。避免使用單字母變數名或神秘的縮寫。 ``` # Bad variable name x = 5 # Good variable name total_score = 5 ``` 2. **保持函數和方法簡短** 函數和方法應該簡潔並專注於單一任務。單一職責原則（SRP）指出，一個函數應該要做一件事，並且把它做好。較短的函數更容易理解、測試和維護。如果函數變得太長或太複雜，請考慮將其分解為更小、更易於管理的函數。 ``` // Long and complex function function processUserData(user) { // Many lines of code... } // Refactored into smaller functions function validateUserInput(userInput) { // Validation logic... } function saveUserToDatabase(user) { // Database operation... } ``` 3. **評論和文件** 謹慎使用評論，當你使用評論時，要讓它們變得有意義。程式碼應該盡可能不言自明。文件（例如內嵌註解和自述文件）可協助其他開發人員了解程式碼的目的和用法。記錄複雜的演算法、重要的決策和公共 API。 ``` # Bad comment x = x + 1 # Increment x # Good comment # Calculate the total score by incrementing x total_score = x + 1 ``` 4. **一致的格式和縮排** 堅持一致的編碼風格和縮排。這使得程式碼庫看起來乾淨且有組織。大多數程式語言都有社群接受的編碼標準（例如，Python 的 PEP 8、JavaScript 的 eslint），您應該遵循。一致性也適用於命名約定、間距和程式碼結構。 ``` // Inconsistent formatting if(condition){ doSomething(); } else { doSomethingElse(); } // Consistent formatting if (condition) { doSomething(); } else { doSomethingElse(); } ``` 5. **DRY（不要重複）原則** 避免重複程式碼。重複的程式碼更難維護並增加不一致的風險。將通用功能提取到函數、方法或類別中以提高程式碼的可重複使用性。當您需要進行更改時，只需在一個地方進行即可。 假設您正在開發一個 JavaScript 應用程式來計算購物車中商品的總價。最初，您有兩個單獨的函數來計算每種商品類型的價格：一個用於計算一本書的價格，另一個用於計算筆記型電腦的價格。這是初始程式碼： ``` function calculateBookPrice(quantity, price) { return quantity * price; } function calculateLaptopPrice(quantity, price) { return quantity * price; } ``` 雖然這些函數有效，但它們違反了 DRY 原則，因為計算總價的邏輯對於不同的商品類型是重複的。如果您有更多的專案類型需要計算，您最終將重複此邏輯。為了遵循DRY原則，提高程式碼的可維護性，可以對程式碼進行如下重構： ``` function calculateItemPrice(quantity, price) { return quantity * price; } const bookQuantity = 3; const bookPrice = 25; const laptopQuantity = 2; const laptopPrice = 800; const bookTotalPrice = calculateItemPrice(bookQuantity, bookPrice); const laptopTotalPrice = calculateItemPrice(laptopQuantity, laptopPrice); ``` 在此重構的程式碼中，我們有一個calculateItemPrice函數，它根據作為參數提供的數量和價格計算任何商品類型的總價。這遵循了 DRY 原則，因為計算邏輯不再重複。 現在，您可以通過使用適當的數量和價格值呼叫calculateItemPrice來輕鬆計算書籍、筆記本電腦或任何其他商品類型的總價。這種方法提高了程式碼的可重用性、可讀性和可維護性，同時降低了重複程式碼引起的錯誤風險。 6. **使用有意義的空白** 使用空格和換行符正確設置程式碼格式。這增強了可讀性。使用空格來分隔程式碼的邏輯部分。格式良好的程式碼更容易瀏覽，減少讀者的認知負擔。 ``` // Poor use of whitespace const sum=function(a,b){return a+b;} // Improved use of whitespace const sum = function (a, b) { return a + b; } ``` 7. **錯誤處理** 優雅地處理錯誤。在程式碼中使用適當的 try-catch 塊或錯誤處理機制。這可以防止意外崩潰並為除錯提供有價值的訊息。不要抑制錯誤或在沒有正確響應的情況下簡單地記錄錯誤。 ``` // Inadequate error handling try { result = divide(x, y); } catch (error) { console.error("An error occurred"); } // Proper error handling try { result = divide(x, y); } catch (error) { if (error instanceof ZeroDivisionError) { console.error("Division by zero error:", error.message); } else if (error instanceof ValueError) { console.error("Invalid input:", error.message); } else { console.error("An unexpected error occurred:", error.message); } } ``` 8. **測試** 編寫單元測試來驗證程式碼的正確性。測試驅動開發 (TDD) 可以迫使您預先考慮邊緣情況和預期行為，從而幫助您編寫更清晰的程式碼。經過良好測試的程式碼更加可靠並且更容易重構。 ``` // Example using JavaScript and the Jest testing framework test('addition works correctly', () => { expect(add(2, 3)).toBe(5); expect(add(-1, 1)).toBe(0); expect(add(0, 0)).toBe(0); }); ``` 9. **重構** 定期重構你的程式碼。隨著需求的變化以及您對問題域的理解的加深，請相應地調整您的程式碼。隨著專案的發展，重構有助於保持乾淨的程式碼。必要時不要害怕重新存取和改進現有程式碼。 假設您有一個函數，可以計算購物車中具有固定折扣百分比的商品的總價： ``` function calculateTotalPrice(cartItems) { let totalPrice = 0; for (const item of cartItems) { totalPrice += item.price; } return totalPrice - (totalPrice * 0.1); // Apply a 10% discount } ``` 最初，此函數計算總價並應用 10% 的固定折扣。然而，隨著專案的發展，您意識到您需要支持可變折扣。為了重構程式碼使其更加靈活，可以引入折扣參數： ``` function calculateTotalPrice(cartItems, discountPercentage) { if (discountPercentage < 0 || discountPercentage > 100) { throw new Error("Discount percentage must be between 0 and 100."); } let totalPrice = 0; for (const item of cartItems) { totalPrice += item.price; } const discountAmount = (totalPrice * discountPercentage) / 100; return totalPrice - discountAmount; } ``` 在這段重構的程式碼中： * 我們在calculateTotalPrice函數中新增了discountPercentage參數，讓您在呼叫函數時指定折扣百分比。 * 我們對discountPercentage 參數進行驗證，以確保其落在有效範圍內（0 到100%）。如果不在範圍內，我們會拋出錯誤。 * 折扣計算現在基於提供的discountPercentage，使功能更加靈活，能夠適應不斷變化的需求。 通過這種方式重構程式碼，你提高了它的靈活性和可維護性。您可以輕鬆地調整該函數來處理不同的折扣場景，而無需重寫整個邏輯。這證明了隨著專案的發展和需求的變化定期進行程式碼重構的重要性。 10. **版本控制** 使用 Git 等版本控制系統來跟踪程式碼更改。這使您可以與團隊成員有效協作，在必要時恢復到以前的版本，並維護專案開發的清晰歷史記錄。 Git 提供了程式碼審查、分支和合併工具，促進協作和程式碼整潔。 ##結論 編寫乾淨的程式碼不僅僅是一套規則，更是一種心態和紀律。它是關於建立易於閱讀、維護和擴展的軟體。通過遵循這些最佳實踐和原則，您可以成為一名更熟練的開發人員，生成高質量的程式碼。投入時間仔細檢查其他工程師的程式碼庫，特別是在開源專案中，可能是一種啟發性的體驗。通過這種探索，您將獲得對不同編碼風格和策略的寶貴見解。這種接觸使您能夠提煉出編寫原始、可持續程式碼庫的精髓。請記住，乾淨的程式碼是一個持續的旅程，通過練習，它會成為第二天性，從而實現更高效、更愉快的軟體開發。
一篇國外的熱門文章，關於一些開源選擇方案，翻譯出來給大家參考。 - Medusa vs. Shopify - Postman vs. Hopscotch - Slack vs. Rocket Chat - Google Chrome vs. Brave - n8n vs. Zapier - Webflow/Framer vs. Webiny - Bit.ly vs. Dub.co - Calendly vs. Cal.com - Airtable vs. NocoDB 原文出處：https://dev.to/rigdev/10-open-source-alternatives-to-proprietary-software-34lb --- ##Medusa：Shopify 的替代方案  您可能聽說過 Shopify，它是遊戲中的大玩家。但現在有一個新的競爭者：美杜莎。讓我們來分析一下這兩者的優點、缺點以及本質。 ###Medusa 與 Shopify 相比的優點： **按你的方式做**：Medusa 是開源的，這意味著您可以根據自己的喜好對其進行調整。想要一個霓虹粉紅結帳按鈕嗎？大膽試試吧！ **保留您的現金**：與 Shopify 不同的是，除非您使用他們的支付系統，否則 Shopify 會奪走您的部分銷售額，而 Medusa 不會動用您的口袋。 **選擇你的家**：透過 Medusa，你可以決定在哪裡開設你的商店。這就像在租公寓還是建造自己的房子之間做出選擇。 **權力歸於人民**：美杜莎受到社區的愛戴。這意味著定期更新、酷炫的新功能以及一群隨時準備提供幫助的人。 **沒有秘密**：開源意味著您可以看到幕後發生的一切。 ###Medusa 與 Shopify 相比的缺點： **開箱即用**：Shopify 擁有大量內建功能和龐大的應用程式商店。美杜莎在這方面仍在迎頭趕上。 **減少 DIY**：使用 Shopify，許多技術問題都會為您處理。美杜莎？您坐在駕駛座上，但這意味著您也必須應對道路上的顛簸。 **名言**：每個人都知道 Shopify。美杜莎仍然是學校裡的新生。 ###結論： 在 Medusa 和 Shopify 之間進行選擇可以歸結為您的特定需求和技術專長。如果您重視靈活性、客製化和成本控制，Medusa 是令人信服的選擇。然而，如果您正在尋找一個擁有良好記錄、廣泛內建功能和強大支援的平台，Shopify 仍然是一個強大的競爭者。 ##Hopscotch：郵差的替代方案  您可能聽過 Postman，它是 API 測試領域的大人物。但有一個開源挑戰者踏入了這個圈子：Hopscotch。 ###Hopscotch 與 Postman 相比的優點： **像鳥一樣自由**：作為開源軟體，Hopscotch 不會花費您一毛錢。對於關注預算的小型團隊或個人開發人員來說，這可能是一個巨大的勝利。 **社群氛圍**：像 Hopscotch 這樣的開源工具依靠社群的投入而蓬勃發展。這意味著您有一群充滿熱情的人不斷改進它並加入很酷的新功能。 **透明度**：對於 Hopscotch，不存在任何幕後謎團。您可以看到每一行程式碼，確保您確切知道發生了什麼。 **輕量級**：Hopscotch 往往比 Postman 更輕量級，如果您正在尋找資源密集程度較低的東西，這可能是一個優勢。 **豐富的客製化**：由於是開源的，如果缺少您需要的功能，您可以自行加入或召集社群來提供協助。 ###Hopscotch 與 Postman 相比的缺點： **功能豐富**：Postman 已經廣泛存在並擁有大量內建功能。它就像是 API 測試的瑞士軍刀。 **流暢的使用者介面**：Postman 的使用者介面精美且直觀，讓新手可以輕鬆上手。 **協作功能**：透過其團隊協作工具，Postman 讓團隊可以輕鬆地協同工作、共享集合並保持所有內容同步。 **廣泛的文件**：Postman 參與遊戲已經有一段時間了，因此他們建立了一個龐大的教程、指南和社區帖子庫來幫助您。 **整合生態系統**：Postman 提供與各種其他工具的集成，使其更容易融入現有工作流程。 如果您熱衷於開源，喜歡修補，並且正在尋找一個輕量級工具，那麼 Hopscotch 可能是您最好的新朋友。但如果您想要一個功能豐富且擁有良好記錄的環境，並且不介意花一些錢購買高級功能，那麼 Postman 仍然是一個不錯的選擇。像往常一樣，關鍵是找到適合您需求的工具。 ##Rocket Chat：Slack 替代方案  當談到團隊溝通工具時，Slack 一直是許多人的首選。但等一下，擂台上有個開源挑戰者：Rocket.Chat。讓我們透過簡單地了解 Rocket.Chat 與 Slack 相比的三個優缺點來分解這兩者的比較。 ###為什麼 Rocket.Chat 可能會震撼您的世界： **調整和調整**：Rocket.Chat 是開源的，這意味著如果有您不喜歡的東西或您認為可以更好的東西，您（或您的技術團隊）可以參與並自訂它。您的 Rocket.Chat 可以像您團隊最喜歡的內部笑話一樣獨特。 **錢包友好**：使用 Rocket.Chat，您可以避免 Slack 等高級版本專有軟體帶來的一些討厭的費用。此外，由於是自託管，您可以更好地控制未來潛在的價格上漲。 **您的資料，您的規則**：在您自己的伺服器上託管 Rocket.Chat 意味著您可以完全控制您的資料。無需擔心第三方存取或資料儲存位置。 ###Slack 仍可能佔上風的地方： **即插即用**：Slack 以其用戶友好的介面和易於設定而聞名。對於那些不懂科技的人來說，Slack 的簡單方法可能是一件幸事。 **整合**：Slack 一直處於領先地位，擁有龐大的應用程式整合庫。無論是 Trello、Google Drive，還是您的團隊離不開的小眾工具，Slack 都可能提供了整合。 **酷兒童俱樂部**：Slack 的受歡迎意味著許多人已經熟悉它。如果新團隊成員之前已經使用過 Slack，那麼新團隊成員的入職或與合作夥伴的協作可能會更順利。 ###結論： Rocket.Chat 提供了一個無與倫比的客製化、成本節約和資料控制的世界。但如果您正在尋找無憂無慮的設置、大量的整合以及廣泛的熟悉度，Slack 仍然可以滿足您的需求。一如既往，最好的選擇取決於您的團隊最重視的是什麼！ ##Brave：Google Chrome 的替代品  就網頁瀏覽器而言，Google瀏覽器在相當長一段時間內一直是衛冕冠軍。但有一個新的競爭者正在引起轟動：Brave。 Brave 建構於與 Chrome 相同的 Chromium 引擎之上，承諾提供不同類型的瀏覽體驗。 ###Brave 與 Google Chrome 相比的優點： **隱私第一**：Brave 非常重視隱私。它可以立即阻止第三方廣告和追蹤器，這意味著您不必擺弄設定或加入擴充功能來阻止公司在網路上追蹤您。 **速度惡魔**：由於其廣告攔截功能，Brave 通常加載頁面的速度比 Chrome 更快。更少的廣告和追蹤器意味著更少的下載資料，讓您的瀏覽體驗更快捷。 **衝浪獲得報酬**：Brave 有一個獨特的功能，稱為 Brave 獎勵。選擇尊重隱私的廣告，您可以獲得 BAT（基本注意力代幣），您可以將其保留或作為小費提供給您最喜歡的網站。 Chrome 不提供類似的功能。 ###Brave 與 Google Chrome 相比的缺點： **豐富的擴充功能**：Chrome 的網路應用程式商店是擴充功能和應用程式的寶庫。雖然 Brave 是基於 Chromium 引擎建置的，因此能夠安裝所有 Chrome 擴充程序，但由於某些擴充功能非常注重隱私和廣告攔截，因此可能會出現相容性問題。 **Google 生態系統**：如果您已經投資於 Google 領域（例如 Google 雲端硬碟、Google 照片、Google Meet），那麼 Chrome 可以與這些服務無縫整合。 Brave 可以存取它們，但不太順利。 **穩定可靠**：Chrome 已經存在多年，並且在穩定性和性能方面擁有良好的記錄。 Brave 比較新，雖然很強大，但還沒有足夠的時間來解決所有的問題。 ###結論： 如果您重視隱私，並且喜歡更快、更有價值的瀏覽體驗，那麼 Brave 可能會改變您的遊戲規則。但如果您是 Chrome 擴充功能的重度用戶或深入 Google 生態系統，那麼 Chrome 可能仍然是您的最佳選擇。 ##n8n 與 Zapier：自動化競技場  在工作流程自動化領域，Zapier 長期以來一直是家喻戶曉的名字，它幫助企業和個人連接他們最喜歡的應用程式並自動化任務。進入 n8n，這是一個開源替代方案，以其獨特的方法而引人注目。讓我們深入了解 n8n 如何與 Zapier 進行比較。 ###n8n 與 Zapier 相比的優點： **客製化之王**：n8n 是開源的，提供無與倫比的客製化功能。如果您需要特定的功能或集成，您可以自行建立或利用社群來取得協助。這種程度的彈性是 Zapier 等專有平台無法比擬的。 **成本效益**：n8n 可以自架，這意味著您可以節省大量成本，尤其是在執行大量工作流程時。使用 Zapier，隨著您的需求成長，訂閱成本也會隨之增加。 **資料隱私**：透過 n8n 的自架選項，您可以完全控制您的資料。它保留在您的伺服器上，確保您確切知道它在哪裡以及誰有權存取。這與 Zapier 等基於雲端的解決方案形成鮮明對比，後者的資料是在外部伺服器上處理的。 ###n8n 與 Zapier 相比的缺點： **使用者友好**：Zapier 以其直覺的介面而聞名，即使是非技術人員也可以輕鬆設定和管理工作流程。 n8n 以其更面向開發人員的方法，對某些人來說可能有更陡峭的學習曲線。 **海量整合庫**：Zapier 擁有超過 3,000 個應用程式整合。雖然 n8n 的清單正在快速增長，但它尚未達到與 Zapier 一樣廣泛的開箱即用整合數量。 **可靠性和支援**：憑藉其成熟的影響力，Zapier 提供強大的可靠性和專門的支援團隊。雖然 n8n 擁有一個充滿熱情的社區，但它可能無法提供與 Zapier 這樣的成熟平台相同程度的即時、專業支援。 ###結論： n8n 提供了一個客製化、節省成本和資料控制的世界，對於那些習慣更實際操作方法的人來說，這是很難擊敗的。然而，如果您正在尋找一個具有大量即用型整合、用戶友好介面和專門支援的平台，Zapier 仍然是一個強大的選擇。您的理想選擇將取決於您的特定需求和技術舒適度。 ##Webiny：Webflow 和 Framer 的替代方案  在網頁設計和開發領域，Webflow 和 Framer 等工具因提供直覺的介面和強大的設計功能而聞名。但鎮上出現了一個新的開源玩家：Webiny。 ###Webiny 與 Webflow 和 Framer 相比的優點： **開源彈性**：Webiny 的開源性質意味著您可以根據自己的喜好進行自訂。如果您需要某種功能或集成，您將不會受到專有約束的限制。這種程度的適應性是像 Webflow 和 Framer 這樣的專有平台無法完全匹敵的。 **成本考量**：從長遠來看，Webiny 更具成本效益，特別是對於較大的專案或企業。雖然 Webflow 和 Framer 需要付費，但 Webiny 的開源模型可以節省大量成本，特別是在考慮自架網站時。 **完全控制資料**：透過 Webiny，您可以選擇自行託管，從而完全控制資料及其安全性。這與 Webflow 和 Framer 等基於雲端的解決方案形成鮮明對比，在這些解決方案中，您的資料駐留在外部伺服器上。 ###Webiny 與 Webflow 和 Framer 相比的缺點： **直覺的設計介面**：Webflow 和 Framer 都以其用戶友好的設計介面而聞名。它們提供拖放功能和視覺設計工具，使設計人員即使沒有深厚的編碼知識，也可以輕鬆地將他們的願景變為現實。 Webiny 雖然功能強大，但對於純粹的設計師來說可能有更陡峭的學習曲線。 **豐富的範本和元件庫**：Webflow 和 Framer 附帶豐富的範本、元件和動畫庫。這可以顯著加快設計過程。 Webiny 較新，可能無法提供同樣廣泛的即用型設計元素。 **社群與支援**：Webflow 和 Framer 擁有大型、成熟的社群和專門的支援團隊。這意味著有大量的教程、論壇和資源可供使用。 Webiny 是新出現的，仍在發展其社區和支援基礎設施。 ###結論 Webiny 提供了一個引人注目的開源替代方案，具有客製化功能、潛在的成本節約和資料控制。然而，對於優先考慮直覺設計介面、大量設計元素和成熟社群支援的人來說，Webflow 和 Framer 的綜合優勢仍然難以超越。 ##Penpot：Figma 的替代品  在設計界，Figma 因其協作功能和時尚的介面而受到青睞。但有一個開源競爭者走進了聚光燈下：Penpot。 ###Penpot 與 Figma 相比的優點： **開源優勢**：Penpot 的開源性質意味著它在社群的貢獻下不斷發展。這允許一定程度的適應性和客製化，而 Figma 等專有平台可能無法提供。 **無成本障礙**：Penpot 是開源的，可以免費使用。雖然 Figma 提供免費套餐，但高級功能和更大規模的團隊協作需要付費訂閱。使用 Penpot，您可以存取所有功能，而無需擔心訂閱費用。 **用於資料控制的自託管**：Penpot 使您可以選擇在自己的伺服器上託管。這意味著您可以完全控制資料、資料的安全性以及資料的儲存位置，這是 Figma 的純雲端模型所不具備的功能。 ###Penpot 與 Figma 相比的缺點： **成熟的生態系統**：Figma 存在的時間更長，並且擁有更成熟的生態系統。這包括一個龐大的插件庫、整合庫和社群貢獻的資源，可以增強設計過程。 **即時協作**：Figma 的突出功能之一是無縫即時協作。多個設計師可以同時處理一個專案並進行即時更新。雖然 Penpot 提供協作功能，但它可能不如 Figma 的那麼精緻。 **性能和可靠性**：Figma 的性能，尤其是複雜的設計和原型，是強大且可靠的。作為一種較新的工具，Penpot 仍在完善其性能並消除任何問題。 ###結論 Penpot 為設計工具領域提供了全新的開源視角，其成本效益和資料控制對許多人來說都很有吸引力。然而，對於那些看重龐大生態系統、即時協作和經過驗證的性能的人來說，Figma 仍然是一個強大的選擇。 ##Dub.co：Bit.ly 的替代方案  Bit.ly 已成為許多用戶的主要內容。然而，開源社群提出了另一種選擇：Dub.co。 ###Dub.co 與 Bit.ly 相比的優點： **開源彈性**：Dub.co 的開源性質意味著它在社群的貢獻下不斷發展。這允許一定程度的適應性和客製化，而 Bit.ly 等專有平台可能無法提供。 **成本考慮**：Dub.co 是開源的，可以免費使用。雖然 Bit.ly 提供免費套餐，但其高級功能和分析功能價格昂貴。透過 Dub.co，您可以存取所有功能，而無需擔心訂閱費用。 **資料隱私和自架**：Dub.co 為您提供在自己的伺服器上託管的選項。這意味著您可以完全控制您的資料、資料的安全性以及資料的儲存位置，這是 Bit.ly 的純雲端模型所不具備的功能。 ###Dub.co 與 Bit.ly 相比的缺點： **已建立的聲譽**：Bit.ly 已經存在很長時間了，並在可靠性和性能方面建立了聲譽。這種長期存在意味著許多用戶信任並熟悉其服務。 **廣泛的集成選項**：Bit.ly 提供與其他平台和行銷工具的廣泛集成，使企業可以更輕鬆地將連結管理納入其現有工作流程。 **用戶友好的介面**：Bit.ly 以其直覺的介面而聞名，使用戶可以輕鬆建立、管理和分析其縮短的連結。雖然 Dub.co 提供了一個強大的平台，但新手可能會發現 Bit.ly 的介面更加簡單。 ###結論： Dub.co 為連結管理提供了全新的開源視角，提供客製化、成本效益和增強的資料控制。然而，對於那些重視具有大量整合和易於使用介面的久經考驗的平台的人來說，Bit.ly 仍然是一個不錯的選擇。您理想的工具將取決於您的特定需求以及您如何優先考慮功能。 ##Cal.com：日曆的替代方案  在安排會議和約會時，Calendly 一直是許多人的首選平台。但有一個新的開源替代方案引起了人們的注意：Cal.com。 ###Cal.com 與 Calendly 相比的優點： **開源彈性**：Cal.com 是開源的，這意味著您可以對其進行自訂以滿足您的特定需求。無論是加入獨特的功能還是與其他工具集成，您都可以自由地打造自己的功能。這是 Calendly 作為專有平台無法提供的。 **成本效益**：Cal.com 對個人免費，並且是開源的，您可以自行託管它以避免訂閱費用。另一方面，Calendly 有免費套餐，但僅限於一種活動類型，並且缺乏一些高級功能，除非您升級到付費計劃。 **資料隱私**：透過自行託管選項，Cal.com 讓您可以完全控制自己的資料。您確切地知道它的儲存位置以及誰可以存取它，而 Calendly 的基於雲端的模型則不然。 ###Cal.com 與 Calendly 相比的缺點： **使用者體驗**：Calendly 已經存在了一段時間，並且擁有精美、用戶友好的介面。即使對於那些不懂技術的人來說，設定和管理約會也很容易。 Cal.com 較新，可能有更陡峭的學習曲線。 **整合選項**：Calendly 提供與 Google 日曆、Office 365 和 Zoom 等流行平台的廣泛整合。雖然 Cal.com 正在努力擴展其整合選項，但尚未達到與 Calendly 相同的水平。 **社群與支援**：Calendly 擁有龐大的用戶群，並提供強大的客戶支持，包括豐富的教學和資源。 Cal.com 作為一個較新的開源平台，更依賴社群支持，但社群支持可能不那麼直接或廣泛。 ###結論： 如果您熱衷於嘗試新事物、喜歡優質的免費贈品並重視保持資料的私密性，請嘗試 Cal.com。但如果您想要一個久經考驗、易於使用且擁有可靠支援的工具，Calendly 仍然是一個不錯的選擇。 ##NocoDB：Airtable 替代方案  您可能已經看過 Airtable，它具有豐富多彩的網格和簡單的拖放氛圍。但有一個新來者正在引起一些轟動：NocoDB。讓我們來分解一下這兩者是如何疊加的。 ###NocoDB 與 Airtable 相比的優點： **開源優點**：NocoDB 是開源的，這意味著您可以根據自己的喜好調整、扭曲和自訂它。另外，您還可以從不斷改進它的社區中受益。空中桌？這很酷，但它並沒有給你那種程度的自由。 **錢包友善**：使用 NocoDB，您可以透過自己託管來避免這些月費。 Airtable 有免費套餐，但如果您想要更多記錄、檢視或精美功能，則需要花費一些現金。 **您的資料，您的規則**：由於您可以自行託管 NocoDB，因此在資料方面您處於主導地位。您可以決定它的儲存位置以及誰可以查看它。使用 Airtable，您的資料將掛在他們的伺服器上。 ###NocoDB 與 Airtable 相比的缺點： **使用者友善的氛圍**：Airtable 超級直覺。它的介面很乾淨，設定基地感覺輕而易舉。 NocoDB 比較新，可能需要更多時間來適應。 **模板寶庫**：Airtable 有大量模板。無論您是計劃活動、追蹤庫存還是管理專案，都可能有一個模板。 NocoDB 仍在建立其集合。 **內建整合**：Airtable 與其他應用程式配合得很好，提供了一系列與流行應用程式的內建整合。雖然 NocoDB 正在擴展其整合遊戲，但尚未達到 Airtable 的水平。 如果您是開源愛好者，喜歡控制資料，並且希望節省一些錢，那麼 NocoDB 可能正合您的胃口。但是，如果您正在尋找超級用戶友好、具有豐富模板庫並且可以輕鬆與其他應用程式連接的工具，那麼 Airtable 仍然很強大。 ##大結論 在不斷發展的數位工具世界中，老牌巨頭和創新的新來者之間始終需要保持平衡。無論是設計平台、調度工具或資料庫系統，每個平台都有其獨特的優點和潛在的缺點。 Penpot、Cal.com、NocoDB 等開源替代方案帶來了無與倫比的客製化、成本節約和資料控制。另一方面，Figma、Calendly 和 Airtable 等老牌廠商提供用戶友好的介面、廣泛的整合選項以及隨著時間的推移和改進而帶來的可靠性。 ##誰說你必須選邊站隊？ 當今技術生態系統的美妙之處在於您可以混合搭配。使用開源工具完成一項任務，使用專有工具完成另一項任務。這就像擁有一把瑞士軍刀和一個專門的工具包。您將獲得兩全其美的效果。 例如，您可能喜歡根據資料庫需求自訂 NocoDB，但更喜歡使用 Calendly 進行排程的無縫整合。或者也許 Penpot 的開源靈活性吸引了您的設計方，而 Slack 的可靠性則讓您的團隊溝通順暢。 關鍵是，你並沒有被歸類。這一切都是為了找到適合工作的工具，有時，這意味著將開源精神與專有軟體的精美體驗相結合。 因此，當您冒險進入科技領域時，請記住：這不是選擇立場的問題。它是為了找到讓您的數位生活更輕鬆、高效和愉快的完美工具。潛入、實驗並製作你獨特的科技馬賽克！
發現一篇文章，國外的技術研討會舉辦者，分享了舉辦這類活動的辛苦＆心得 很有意思，翻譯與大家分享一下。 原文出處：https://dev.to/k8adev/tech-events-are-not-as-cool-as-you-think-from-an-organizer-perspective-2b70 --- 大家好！ 我的名字是**Keit**，又名[@k8dev](https://twitter.com/k8adev)，我是巴西人，除了作為一名程式設計師之外，我已經組織技術活動8 年了。 我目前負責**幾項技術**活動，其中之一是著名的**FRONTIN Sampa**，這是**巴西**最大和最**傳統的**技術活動之一，對**開發社區**有很大影響。該活動每年**每年七月**在**聖保羅**市舉行，在那裡我們涵蓋了與前端開發和相關領域相關的各種主題。 然而，我們面臨著重大的**挑戰**，因為許多人**不認識**此類事件的**價值**，而且這不僅限於**開發人員**社區**。如果我必須**列出**作為**組織者**我的**主要挫敗感**，它們將如下： * **獲得贊助方面有困難**。 * **在活動前後保持參與度**。 * **管理合作夥伴關係**和社區。 **FRONTIN Sampa** 活動一直是**標誌性活動**，甚至在我於**2016** 接管該組織之前也是如此。但要注意的是，如果沒有足夠的**財力**，就**不可能提供高品質的環境**、**優秀的演講者**和**有能力的團隊**來舉辦這樣的活動尺寸。在地球的這一邊，**公司甚至表現出參與活動的興趣**，但他們希望作為贊助提供的**提供的贊助**價值往往**幾乎無法覆蓋他們的成本**活動當天他們自己的基礎設施**。 例如，上屆 FRONTIN Sampa 產生了大約 **100,000.00 雷亞爾（20,368.26 美元）的銷售額**，而**贊助額僅約為 12,000.00 雷亞爾（2,444.04 美元）**，不考慮以物易物。單獨的交流**往往與我們在活動期間和社交媒體上提供的內容不同**。即使銷量非常好，如果我們進行**快速計算**，很明顯**方程式不成立**。組織像 **FRONTIN Sampa** 這樣的活動不僅需要活動當天的資源，還需要活動前後所需的 **努力和資源**，而這些努力和資源通常未被考慮在內。在我為管理活動而成立的 FRONTIN 公司，我們有許多需求，例如： * 社群媒體管理 * 平面設計 * 銷售量 * 內容製作 * 行銷 * 訂閱 Mailchimp、Google Workspace、Figma、Canvas 等服務 * 事件管理 * 合作夥伴和贊助管理 * 公共關係 * 會計管理 等等等等。 **近一年的規劃和執行**，**每月的費用**是**不可能**在沒有贊助**或個人投資的情況下實現的。是的！有時，組織者**必須從自己的口袋裡掏錢**，因為，**這個等式再一次不成立**。我們談論的是大約 10,000.00 BRL 或更多，用於維持舉辦活動、監控社交媒體、管理社區、溝通和其他活動所需的結構和團隊。 我們正在討論今年生產 FRONTIN Sampa 的成本約為 **170,000.00 雷亞爾或 34,000 美元**！ 另一方面，我們有一群**觀眾**，他們經常**抱怨票價**。我們**總是**嘗試提供極其**實惠的門票**——這些門票通常**不兼容**如此**高標準**的**活動**，特別是在經濟衰退期間。我們實施了**策略**，例如**提前售票**和**提供半價**門票，以使活動盡可能方便地進行。然而，經常會遇到一些人不認識組織活動背後的辛苦工作並公開提出非建設性的批評。 當談到**合作夥伴**、**社區**和科技**影響者**時，他們中的許多人更**對他們收到的優惠券和免費門票**感興趣，而不是實際幫助宣傳* * 活動並建立一個**環境**，讓人們可以**學習**、**分享**和**享受樂趣**。此外，管理這些合作夥伴關係通常很複雜，因為它涉及交換關係。再次，**缺乏財政**資源影響了我們對這些夥伴關係給予適當關注並追蹤雙方義務履行情況的能力。 今年**特別具有挑戰性**，**財政資源**少**，但要舉辦**許多**活動來滿足**社區的期望**。這太**困難**，以至於我**被迫**將幾乎**所有的錢**投入FRONTIN，以**確保**所有**事件發生**，即使我沒有籌集**足夠的資金**。這**讓我多次重新思考**是否**值得繼續製作這些活動**。 我**期待聽到其他**積極或自願參與**科技活動**的人的觀點**。我很樂意與您交談，也許會找到一些繼續前進的**動力**，甚至是公司加入我們的下一次活動。我相信我們的工作對於**創造一個人們可以相互聯繫的環境**至關重要，我真的不想放棄。 謝謝你！
您是否想過當您**執行 Rust 程式**時**RAM**會發生什麼情況**？您編寫程式碼的**方式會如何干擾系統中的許多其他事物？ 這篇文章將幫助您了解更多關於 *管理記憶體* 和 **RUST 如何運作** 的資訊。 原文出處：https://dev.to/canhassi/how-rust-memory-management-work-to-beginners-622 ## 1. Stack and Heap 在了解 rust 的作用之前，您必須先了解一些概念。一般來說，我們有兩種類型的內存，稱為：**堆疊和堆**。現在我們來介紹一下他們。 ### 1.1 記憶體：Stack 堆疊，顧名思義，**工作原理就像堆疊**，遵循**“後進先出”（LIFO）的原則。**也許分步驟解釋會更容易： *想像一下**一堆盤子**； *您放入的**第一道菜**是**最後取出的**； * 當**函數被呼叫**時，一塊記憶體被**「堆疊」在棧頂； * 當**函數結束**時，該區塊**“unstacked”**，釋放該記憶體。 通常，**編譯器**（在編譯時）知道將儲存在堆疊上的**值**，因為它知道需要儲存多少記憶體。此過程**自動**發生，所有值都會從記憶體中刪除。 下面是一個例子： ``` fn main() { let number = 12; // at this moment the variable has created println!("{}", number); // 12 } // When the owner (main function) goes out of scope, the value will be dropped ``` 在 Rust 中，我們只需使用「{}」即可建立一些作用域，這會在堆疊中加入具有有限生命週期的層。當您離開該特定*範圍*後，記憶體將被清除，您將遺失相關資訊。一個很好且簡單的例子是： ``` fn main() { { let number = 12; println!("{}", number); // 12 } println!("{}", number); // Cannot find value `number` in this scope } ``` ### 1.2 記憶體：Heap 簡而言之：**堆**記憶體是一個空閒記憶體空間，用於分配可能更改的資料。 想像一下，您需要在啟動程式後**儲存一些變數**，該變數在編譯時沒有已知的固定大小，因為它可能有大小變化或是記憶體中的直接分配。 如果上述可能性之一匹配，我們就知道我們有 **堆** 內存，而不是 **堆疊**。堆擁有更**靈活的記憶體**和更大的空間。看一看： ``` let number = Box::new(12); // alocate a integer in heap let name = String::from("Canhassi"); // alocate a String in heap ``` 在 Rust 中，我們有兩種字串「類型」：「&str」和「String」。 * **&str**：根據所寫的文字有固定的大小； * **字串**：具有可以增加、減少和刪除的大小。 ……這就是為什麼 `String` 儲存在堆上，而 `&str` 儲存在堆疊上。 釋放堆記憶體的一種方法是：當儲存堆上某些內容的**變數離開函數的作用域（到達函數末端）時，它將以相同的方式釋放作為堆疊。 好了，現在我們對這兩種記憶體類型有了一個清晰的認識，但是堆疊和堆在管理記憶體方面有什麼區別呢？讓我們看看這些差異吧！ ## 2. 借用檢查器 借用檢查器是 Rust 編譯器的**部分**，它**檢查並確保**所有權、借用和生命週期**規則得到尊重**。 老實說：一開始我在理解它是如何運作的方面遇到了一些問題，我發現這在新的 Rustaceans 中很常見。但別擔心，我的朋友。我會用最好的方式教你。但首先，讓我們先來看看下面的程式碼： ``` fn main() { let name = String::from("Canhassi"); // Creating a string variable print_name(name); // calling the print_name function passing the variable println!("{}", name); // Error: name borrowed to print_name() } fn print_name(name: String) { println!("{}", name); // print "Canhassi" } ``` 如果您使用該程式碼執行編譯器，您將看到以下錯誤： ``` borrow of moved value: name ``` 當我們呼叫“print_name”函數時，“name”變數將被**移動到另一個作用域**，並且該作用域將成為它的**新所有者**。並且所有者的規則超出範圍將再次應用。借用檢查器確保**一旦所有權轉移**，原始變數**不能再用於**來存取該值。這發生在上面的程式碼中。 使用原始變數的另一種方法是使用類似的引用。 ``` fn main() { let name = String::from("Canhassi"); // Creating a string variable print_name(&name); // calling the print_name function passing the variable println!("{}", name); // print "Canhassi" } fn print_name(name: &String) { println!("{}", name); // print "Canhassi" } ``` PS：這些**借用檢查器的規則僅適用於**堆中指派的物件**。 ## 3. 錯誤預防 借用檢查器對於確保 Rust 記憶體安全而無需[垃圾收集器](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) 至關重要。 在 C 和 C++ 等其他語言中，我們（作為開發人員）必須使用某些函數手動釋放記憶體。 C++ 以允許記憶體管理錯誤而聞名，包括[記憶體洩漏](https://en.wikipedia.org/wiki/Memory_leak)。 C++本身不會導致記憶體洩漏。相反，**C++ 為程式設計師提供了大量的靈活性**和控制力，如果使用不當，這種**自由可能會導致錯誤**。 一個著名的錯誤是**未定義的行為**，例如，想像一個函數傳回這樣的變數的引用 ``` fn main() { let number = foo(); // calling foo function } fn foo() -> &i32 { let number = 12; // creating a var number &number // try return a reference of var number } ``` 程式碼不起作用，因為 Rust 編譯器對記憶體管理有限制規則。我們不能回傳 var `number` 的引用，因為這個函數的作用域將會消失，而 var `number` 將會消失，所以 Rust 不會讓這種情況發生。在 C++ 中我們可以做到這一點，並且它允許臭名昭著的記憶體洩漏。 我認為知道 Rust 編譯器避免了這種類型的錯誤真是太酷了...如果這個主題對您來說是新的，我可以說內存洩漏可能會花費很多錢並且確實很難修復它，因為絕不只有一次內存洩漏。 其他範例是，**雙重釋放**，當您嘗試釋放相同物件兩次（例如在 C 程式碼中）時，就會發生這種情況。 ``` char* ptr = malloc(sizeof(char)); *ptr = 'a'; free(ptr); free(ptr); ``` 這個主題非常廣泛，當您使用其他語言時，很可能會產生類似的錯誤。但是，我會讓您自己進行研究，並確保在這篇文章的評論中告訴我更多！ ## 4。結論 我寫這篇文章的目的是以更一般的方式展示記憶體管理如何與 Rust 配合使用。但我建議您閱讀《Rust 程式語言》一書的第 4 章（ https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html ）來獲得更完整的知識。在那裡您將獲得更多示例和更多關於此內容的解釋。 希望這篇文章有幫助！ 🦀🦀
測試程式碼是軟體開發最重要的方面之一，因為它可以確保產品的品質、可擴展性和可靠性。 但是，如果沒有任何指導，編寫有效的測試可能會很困難。測試程式碼可能比實際功能的程式碼更複雜、更難維護！ 原文出處：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 ``` ##額外提示！ 如果您在測試元件中的任何邏輯時遇到困難，這可能反映出您也許應該將元件邏輯分解為更小、更容易且可測試的程式碼片段！ 總而言之，遵循此最佳實踐可能會帶來一種新的、可讀且可維護的方法來測試您喜愛的生產程式碼。 > 經過測試的應用程式才是可靠的應用程式！
阿川收到網友提問如下： ``` 站長阿川您好 我是一名App工程師 從2013年第一份工作到現在近10年 這十年我從工程師到資深工程師到管理職位都有相關經驗 一共經歷四份工作 離開公司原因大多是與人理念不合 今年邁入40歲 目前在一間外商工作 年薪約200左右 最近又再找尋新機會 但是相關職位看到我的經歷常常被拒絕 因為該職位不想要這麼資深的 不然就是年薪必須砍半 最近有一個機會可以加入幾個創業家所組成的公司 缺點是薪資可能只剩下現有的1/3 優點是可以接觸相關人士學到創業可能所需的技能 也可以藉由這樣機會建立屬於自己的產品一步步養活自己 在網路上看到您的文章彷彿醍醐灌頂 也對於長年職涯生命握在別人手上感到非常不適應 但是我明白產品可能不是自身想像那麼容易打造 不過我仍想試試看 不知道您這邊是否有什麼想法可以對我未來要走的路提供一些建議 非常感謝您撥空看完 ``` 這主題很好，我決定單獨寫一篇文章討論這件事情，跟大家分享一下 --- 首先，這位朋友目前的工作狀況，外商、200萬年薪，如果工作壓力不大、下班時間正常，辦公室氣氛融洽 這麼好的條件，如果放棄這份工作，實在相當可惜！ 有沒有考慮利用下班＆週末的時間，寫一些自己的作品、app，試試看？ 一人獨立開發，或者找朋友一起經營，都可以，做完之後，到相關的 FB 社團、批踢踢看板，宣傳一下 會學到很多商業、經營、行銷的技能，會很好玩 也或許，你會發現要做的事情太多、太雜、太難，你會滿不適應的，那樣的話，你會重新看見現職公司的美好 --- 再來，如果目前的公司實在很煩，除了高薪之外，工時、工作內容、環境壓力，你根本通通都不喜歡、鐵了心想要離職 那麼眼前的選項就是 - 找類似工作，薪水變二分之一 - 前往新創嘗試，薪水變三分之一 這樣的話，我有一個小原則跟你分享 # 職涯判斷技巧：Ctrl+Z 不心痛原則 這是我發明給自己，在面臨重大決定會用的一個原則 Ctrl+Z 是工程師每天會用到的快捷鍵：「恢復上一動」 在面臨選項的時候，可以去想想：「恢復上一動」的成本會很高嗎？ ### 「我該先做哪一個決定，到時反悔的話，可以 Ctrl+Z 不心痛呢？」 舉例來說，社會新鮮人有點想考公務員 vs 想去業界上班看看 如果先考公務員，工作之後迷惘，想辭職去業界，這時「Ctrl+Z」的成本就非常高，因為當初花了數個月準備國考 如果先去業界上班，工作之後迷惘，想去考公務員，這時「Ctrl+Z」的成本就低很多，因為當初就是花一些時間面試而已 所以迷惘的社會新鮮人，我都是建議先去業界面試看看，再去考公務員 --- 再舉一個例子，年輕工程師想去大公司面試 vs 想去新創面試 大公司面試流程很多、面試成本很高，去新創通常聊一個下午就錄取了 所以迷惘的年輕工程師，我都是建議先去新創工作看看，如果之後再去大公司上班，心態就會很穩，因為你知道新創時髦的外表底下，其實愚蠢的地方也不少，你會比別人更看見大公司的美好 如果到了大公司才嚮往新創，到時再次反悔、重新面試大公司的成本就高很多、這樣很浪費時間 --- 我認為現代人，不管做什麼選擇，一定都會覺得迷惘、好奇當初沒做的那個選擇、常常會有遺憾 所以重點不是「如何第一次就做出正確決定」，因為做不到 重點是「**我該先做哪一個決定，到時反悔的話，可以 Ctrl+Z 不心痛呢？**」 這種路徑，比較不留遺憾，因為各種路都走過了，並且算是一種逐漸認識自己的過程 這樣做決定，會容易許多吧！我自己都是這樣做的～ --- 以這位網友面臨的狀況： - 降薪50%去類似環境的大公司上班，然後繼續迷惘新創公司是什麼樣子 - 降薪66%去新創公司看看，然後可能很喜歡、也可能發現是在浪費時間 如果選後者，去工作半年一年，真的不喜歡，頂多就是回去找大公司面試，這樣「Ctrl+Z」的成本也不高吧？ 我會覺得就去新創看看也沒關係，因為之後反悔的成本也沒多高，而且這種事就是體驗過才知道 # 結論 其實創新、創業，極度困難、要做的事情也很雜亂 在我跟各種新創公司合作的經驗來說，很多時候其實也是浪費時間、有點像在幫老闆圓個人夢想，產品本身很爛。當然我也跟很多優秀新創合作過、學到很多寶貴技能 總之去新創不一定好玩，也不一定學得到東西 但我認為有策略性地、管理好各種職涯選擇的成本、在過程中認識自己、增廣見聞、降低迷惘，是很重要的 這位網友如果本身有房貸、車貸、家庭孩子要養，那麼這個抉擇確實非常困難 另一方面，職業生涯不是只有充實金錢＆地位，能夠充實人生經驗＆體驗，也是很有意義的，不是嗎？ 建議靜下心，好好的幫自己分析一下、聽聽看內心的聲音，新選項真的讓你有「義無反顧」的感覺嗎？ --- 我另外還有一些幫助工程師觀察「眼前這位迷人的創業者，有沒有可能是個地雷」的技巧，有機會再跟大家分享吧～！ 以上，簡單幾點分享，希望對大家有幫助，祝各位都有滿意、幸福的職業生涯！
## 課程目標 - 認識 callback hell 與收尾處理 ## 課程內容 研究完 callback hell、promise chain、async/await 的錯誤處理 接著來用三課的時間，分別研究收尾處理吧！ 讓我們先從 callback hell 的寫法開始！ --- 什麼是收尾處理？ 其實就是，有些事情，不論任務執行成功 or 失敗，都固定要執行 這種事情，可以在 success callback 跟 error callback 最後都寫，但這樣就重複寫了，很煩！ 所以就有所謂的收尾處理，讓你寫一次就好了 如果繼續拿 jquery 做範例，看起來會像這樣： ``` $.ajax({ url: url, data: params, success: (res) => {}, error: (res) => {}, complete: () => {}, }); ``` 其實，就是再多一個 callback function 而已！很單純吧！ 在連續多個 ajax call 的時候，錯誤處理機制，再加上收尾處理機制，想想看 callback hell 會有多嚴重！ --- 看到這邊，你可能會想，到底什麼事情需要在收尾機制處理呀？ 其實，以我個人經驗來說，需要放進收尾處理的東西，其實很少 最常見的就是處理畫面上的「載入中，請稍等...」的文字，或者是畫面上「用來代表忙碌中的一個旋轉的圖示」 不論任務執行結果，都需要把這些文字、圖示隱藏 老實說，很多人根本連「忙碌中」這個狀態也沒做，導致 UX 不太好 所以實務上，如果你發現專案中不太會寫收尾處理，那也算正常，你就知道有這功能可以用即可 ## 課後作業 在第一課的作業，你已經體驗到了 callback hell 與錯誤處理的悲劇 忍耐一下，這一課要再體驗一下當年工程師的痛苦：加上收尾處理吧！ 請拿出第一課的作業，我們來改善這個頁面的 UX（使用者體驗），明確提示「忙碌中」這個狀態 --- - 請用 html 元素，在頁面中加入一段 `讀取中，請稍等...` 的訊息，這個元素預設不顯示 - 在開始呼叫 API 的地方，用 js 操作來讓那個 html 元素顯示 - 在結束呼叫 API 的地方，使用 `$.ajax()` 的 `complete` 參數，用 js 操作來讓那個 html 元素隱藏 寫完之後，你應該會發現，有點難寫，而且顯示/隱藏的時機，有點奇怪！ 如果想要讓顯示/隱藏的時機，完全正確，那就會重複很多一樣的 code！ 別懷疑，就是這麼難寫、這麼奇怪！這就是當年前端開發的為難之處！ 做出以上功能，你就完成這次的課程目標了！
今天早上，在我們新手寫程式 LINE 群組，有幾個工程師＆新手在討論，工程師與創業的話題 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 其中一段 cue 到我： > 這裡的版大不就是創業嗎 lol > 對欸！站長是創業的 > 創業重點是人脈 業務很重要 > 工程師很缺業務朋友 有業務朋友要創業會簡單很多 > 不過我覺得站長這種創業模式是餓不死 應該沒有到達財富自由賺大錢 這個主題非常好，我來跟大家分享一些想法！ --- # 站長阿川會餓死嗎？ 先直接談最「害羞」的事情，阿川的網站每個月賺多少錢？ 我在之前幾篇文章有談過我的工作方式，其實並不是傳統定義上那種 100% 創業 https://codelove.tw/@howtomakeaturn/post/2anz0a 我現在手上的六、七個網站，通通加總起來，扣掉租用主機的成本 每個月的利潤大概是 . . . . . . 跟基本工資一樣，月薪26,400元～ 所以 LINE 群大家的猜測非常準確，像我這樣做一些小網站經營，完全無法「財富自由賺大錢」 但我這種經營方式有幾個好處： 1. 我的幾個小網站，開發很花時間，但經營不太花時間，所以我還有時間接案、有 freelancer 的身份 2. 沒有跟政府 or 銀行借錢，身上沒有負債壓力，經營小網站就是這樣 3. 連跟政府申請任何創業補助、補貼，都沒有，也沒有外部投資人，愛做不做新功能，都是隨便我 # 創業做網站，每個月利潤只有基本工資，那不是搞笑嗎？ 首先，台灣的工程師如果希望快速累積財富，我認為最穩健的方式，還是去科技業、半導體產業 有些事情我 20 多歲的時候不相信、看不懂，現在 30 多歲，稍微有點看懂了 我們政府，基本上是圍繞這些產業做資源分配、政策設計（比如水費、電費、匯率、土地），進這些產業「分果實」當然最快 你應該聽過很多科技業的工程師，年薪動輒超過數百萬，但是台灣純軟產業的工程師，你很少聽到年薪 200 萬的 相反的，如果選擇創業，除了五年內 99% 的陣亡率（經濟部中小企業處的官方數據！） 少數能持續經營的公司，有很多的小小公司老闆，收入可能跟我差不了多少，基本上是做得開心、但沒賺到錢 再來，如果外語能力允許的話，出國到其他有軟體產業的國家，也是更好賺錢的軟體工程師生涯 # 傳統的軟體創業 vs 獨立的軟體創業 我看到 LINE 群大家聊到，「工程師很缺業務朋友 有業務朋友要創業會簡單很多」 就我個人觀察，我認為這是真的！「工程師 + 業務」算是創業的黃金雙人組合 一個負責把產品研發好、一個負責把產品賣出去，這完全是兩種人、兩種互補技能 傳統的軟體創業基本上就是：黃金組合 + 申請創業貸款 + 尋找投資人 + 尋找政府創業補助 順利的話，幾年後可以賺到大錢，大家所謂的財富自由 但是，你用想也知道這樣做壓力很大，有夥伴的壓力、投資人的壓力、負債的壓力、應付政府的壓力 所以我選擇的是另一種，一個人兼職做各種小小 side project 的創業方式 # 結論 工程師想要快速存錢，不要想太多，就去半導體，不然就出國 如果不願意，又有點想創業，但又跟我一樣膽小的話，就可以參考我 side project 的創業方式 目前我是覺得還算好玩，收入的話再慢慢想辦法增加這樣，其實利潤 2 萬元我是覺得也不錯呀～我還有多餘時間可以接案欸 以上，簡單心得，跟大家分享一下，未來有更多數據＆心得再跟大家分享！
歡迎最近新註冊的用戶 @a41522001 @hill654 @ru042l41j4 @Road @stanly123 @r567tw @cssf998811 @thes80140 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
上一篇文章談了「同時上班＆接案＆創業」的簡單策略 我發現滿多人對於接案這塊比較感興趣，提了很多問題 我簡單分享一些心得＆建議 --- > 請問原po，在準備接案有想過：我的能力已經足夠接案，這種類似的想法嗎？ 這幾年因為 freelancer 的身份，在一些活動、場合會遇到各種領域的 freelancer 每次遇到這些新朋友，我都會問：你是如何開始的呢？ 我發現有 90% 的機率，得到的故事都是以下這樣： 「我工作幾年之後，在 XX 年的時候離職，想說休息一下，看看之後要幹嘛。這時候有前同事來問：他那邊有人在問誰能接案，能否幫忙？」 「我就先接下來，想說那做完這筆，之後再看要不要找工作。結果做完之後再休息一下，這時又有朋友來問，能不能接某個案子。」 「我就又接一個，然後再休息一下，反正不急著找新工作。就這樣加減接案，做一陣、度假一陣。過了幾個月、幾年之後，有一天發現：我好像可以一直這樣下去。」 所以根據我個人經驗＆觀察：根本沒有人會下決心說，我要從此離職，轉身變成一個全職 freelancer 都是工作轉換的空檔，自然發生的。如果案子沒了，那就開始找工作上班，幾年之後離職休息，上面的故事會再重複一次。 所以重點是：為什麼這些人在轉換的空檔，會有人來問？ 其實就是 1. 在工作上的表現不錯，同事、主管、合作廠商、親朋好友都覺得你值得信賴 2. 有稍微經營個人品牌，身邊的人稍微知道你是做什麼的，然後根據互動經驗覺得你「溝通能力」不錯，會讓人想合作 3. 你稍微有一點勇氣，能夠接受這種「休息一下，想想看之後要幹嘛」的狀態長達數個月之久，很多人在這狀態會很緊張，急著找新工作 然後一些有趣的事情，可能就會自然發生。當然你需要有一點點積極、願意擁抱未知，大概是這樣 --- > 我其實不清楚到底要做到什麼程度？業界常用的必備工具有沒有掌握？發生問題解決辦法能不能處理？ 不論是工作、接案，基本上就是養成「挑戰能力範圍之外一點點」的習慣 不要超出能力太多，會被壓力擊倒、會開天窗、你誠信會出問題 不要完全做已經熟悉的事情，這樣沒有進步，久了會有點無聊 就做超出能力一點點的事情，常常這樣的話，久了自然會有把握＆經驗 這需要時間累積，沒有捷徑、沒有秘訣 --- > 哥有推薦接案的案源嗎 根據我的經驗，你在台灣註冊任何接案平台，或者去 FB 社團搶案子之類的，案件內容＆報酬都會「有點悲劇」 這沒辦法，平台化的東西，大家就是殺價競爭、紅海市場廝殺，比誰更樂意壓榨自己 你就算用英文搜尋，找國外接案平台，狀況也差不多，沒有好到哪去 所以我不推薦任何案源，我推薦你經營個人品牌。雖然有點丟臉，好像讓親朋好友看到你在老王賣瓜 但是行銷就是這樣，你多少要推銷自己一點，不然看起來一點自信都沒有，誰又能放心付個高價錢給你做案子呢？ 那怎麼經營個人品牌？參考我後面的回答 --- > 希望能分享關於案源品質管控的部分（怎麼避開爛專案）🙏 如果你很外向、具有那種油條的業務性格，那你就多多跟各種客戶談生意，多多談判，累積經驗就行 如果你很內向、不具有那種談判性格，實在很怕踩雷，那我建議你：只跟你喜歡的人合作 在 LINE 上打字、Email 往來的時候，感覺對方連話都講不清楚嗎？那你們實在溝通方式有差，建議婉轉拒絕吧 用 LINE 語音，或者視訊軟體開會，感覺對方有點城府，你有一點怕他嗎？那你們做人處事原則大概很不一樣，建議婉轉拒絕吧 實在很想避開爛專案，那就只跟你覺得「跟這個人當朋友好像也沒問題」的案主合作吧！ 當然工作機會，會減少很多，但是，你跟案主互相折磨、互相為難、互告上法院的機率也會減少很多 --- > 想問有建議其他職業的做法嗎？ 抱歉我比較熟悉寫程式領域 但其他職業的話，我覺得經營個人品牌總是不會錯 我滿建議大家 1. 部落格 2. Podcast 3. YouTube 4. 短影片 選擇一種格式來創作，分享一些東西，目標不用高，就花幾年時間，試著經營出 1,000 粉絲就好 分享什麼？結合你的興趣 or 專業，弄點「好笑的有趣的」或「有知識技術含量的」或「能幫讀者省錢或避免踩雷或有利益可圖的」內容，就這些即可，總是會有讀者，因為看到根本賺到 這過程會學到行銷、推銷、品牌、定位，很多很多商業基本知識，零收入沒關係，就是一種商業練習 千萬不要眼高手低、整天空想、整天焦慮沒完沒了，想要搞很大，過了好幾年還是 100 粉絲都沒有 慢慢來吧，但務必要有點進度、養成進步的習慣 以上，簡單幾點分享，希望對你有幫助
歡迎最近新註冊的用戶 @529MS @annie8278 @yukai @evanke183 @cvbn111222333g @yuamando @sophiaJ @qw820301 @jdps40734 @mutemute1127 @chihuahua48763 @Jonas @boson159456 @dj680628 @r4forth @yoitshenry 歡迎在留言處簡單自介一下～ 可以說一下從哪邊發現這論壇的～最近在學什麼東西～或者是關於你的一件小趣事～ 也請大家多多回覆別人的留言，問別人小問題，或者回個「嗨嗨 👋」都很好～ **歡迎各位加入這個技術成長社群！**
- 原文出處：https://dev.to/surajondev/top-7-things-that-kill-developer-productivity-ef9 ## 1. 會議  無效的會議是最不必要的因素之一，它會導致開發人員的生產力下降。寫程式需要專注。進入專注模式平均需要大約 30 分鐘。但由於多次會議，這種專注被打破，開發人員必須重新開始。 還有時間消耗，因為有時 10 分鐘的會議會延長到一個小時。此外，某些會議也需要不必要的出席。如果會議不直接涉及開發人員的專業知識，通常根本不需要他們出席。 --- ## 2. 技術債（晚點再修）  技術債務可以簡單地定義為“晚點再修”的心態。 最初，我們嘗試使該功能正常工作，並將優化留到以後進行。這可能在短期內有效，因為它可以加快專案速度，並且您可能會按時完成任務。但一次又一次地這樣做將會留下大量的工作要做。從而使得維護、擴展和改進軟體變得更加困難 技術債務會在很多方面阻礙開發人員的生產力。其中一些是： - 程式碼審查的瓶頸：當技術債務增加時，會導致程式碼審查時間的增加。 - 更多錯誤：由於最初的動機是速度而不是優化，這將導致引入隱藏的和未被注意到的錯誤。 - 程式碼質量下降：只希望「能跑就好」，會導致程式碼質量差、程式碼審查隨意、甚至沒有程式碼註釋、程式碼複雜等等。 上述所有要點都需要額外的時間來解決。從而拉長了專案時間。 --- ## 3. 程式碼審查  程式碼審查需要時間，如果審查過程太慢或過於官僚，可能會延遲新程式碼的整合並減慢整個開發過程。有時開發人員提出 PR，但程式碼審查人員沒有時間審查。從而增加了開發人員處理下一個任務的時間。 對於程式碼審查，開發人員可能必須參加多次會議，從而導致開發人員的工作效率下降。通常，對程式碼的不明確或複雜的反饋可能需要更長的時間才能解決問題，因為需要進一步的對話才能理解。程式碼審查很重要，但以錯誤的方式進行只會導致生產力的降低。 --- ## 4.微管理（缺乏自主權）  微管理是一種主管密切觀察和管理下屬工作的管理方式。當經理試圖控制開發人員的編碼方式時，就會發生這種情況。這可能會導致開發人員對其程式碼、流程、決策和創造力的控制力減弱。 它可能會以多種方式導致開發人員生產力缺乏。其中一些可以是： - 缺乏動力：微管理可以表明組織對開發人員能力的信任度較低。這樣，開發人員很容易感到失去動力。 - 創造力較少：開發軟體是一項創造性的任務，您需要集中精力探索創造性的解決方案。但微管理會導致對程式碼的控制減少，甚至阻礙開發人員的創造力。 - 決策緩慢：開發人員必須從經理那裡得到簡單決策的確認，在此過程中浪費了大量時間。 在所有這些情況下，開發人員的生產力都會下降。 --- ## 5.倦怠  倦怠是開發人員最關心的問題之一。在緊迫的期限內處理複雜且具有挑戰性的專案，以及交付高質量程式碼的持續壓力可能會導致倦怠。它最終會導致開發人員的生產力下降，因為它會降低開發人員的注意力和專注於編碼和建置的能力。 它還會導致開發人員的創造力和解決問題的能力下降。它最終將導致開發週期變慢。 --- ## 6. 糟糕的文件  文件對於開發人員來說至關重要，因為它傳達了有關程式碼、專案和流程的關鍵訊息。糟糕的文件可能會導致開發週期的嚴重延遲，因為開發人員將花費更多時間來嘗試理解程式碼庫、專案和流程。從而導致開發人員的生產力降低。 在開發人員入職時，提供糟糕的文件將導致開發人員花費更多的時間在任務上，例如設置專案、管理環境、理解程式碼和其他相關的事情。如果沒有明確的文件，維護和修改現有程式碼就會變得困難。由於擔心破壞功能，開發人員可能會猶豫重構或進行更改。因此，開發人員的生產力將被浪費在非核心任務上。 --- ## 7. 不切實際的最後期限  截止日期是讓開發人員失去動力的因素之一。當你被要求在短時間進行大量工作時，你會很容易感到沮喪。它會導致倦怠、程式碼質量差、程式碼審查疏忽等，這會導致技術債務的積累。從而導致開發人員的生產率下降。 截止日期很重要，但設定不切實際的截止日期給開發人員施加壓力，會給他們帶來壓力。在壓力下，整體生產力和程式碼質量都會下降。 ## 結論 有些小工具，可以克服這些挑戰，以在開發人員的健康和生產力之間建立平衡。 以下是一些可以幫助您提高生產力的工具： - [FocusGuard](https://chrome.google.com/webstore/detail/focusguard-block-site-foc/ifdepgnnjpnbkcgempionjablajancjc)：它是一個 Chrome 擴展程序，可以通過阻止網站來幫助您建立焦點。 - [Code Time](https://marketplace.visualstudio.com/items?itemName=softwaredotcom.swdc-vscode)：它是一個 VS Code 擴展，用於跟踪您的編碼時間和活動編碼時間。 - [JavaScript Booster](https://marketplace.visualstudio.com/items?itemName=sburg.vscode-javascript-booster)：此 VS Code 擴展可以提供程式碼重建置議。您也可以找到其他編程語言的此類擴展。 - [Hatica](https://www.hatica.io/?utm_source=dev.to&utm_medium=referral&utm_campaign=surajondev)：雖然上述工具僅限於一項任務並且專注於編碼，但 Hatica 負責大部分工作。它通過改進工作流程、辨識瓶頸和跟踪進度來幫助工程團隊提高開發人員的工作效率。通過這樣做，它可以釋放開發人員大量的時間。了解有關此工程管理平台的更多訊息[此處](https://www.hatica.io/blog/engineering-analytics-for-well-being/?utm_source=dev.to&utm_medium=referral&utm_campaign=surajondev)。 我希望這篇文章能夠幫助您了解開發人員生產力下降的原因。感謝您閱讀這篇文章。
想玩一下 stable diffusion 在 macbook 嘗試了一下 不太好安裝 拿出家中的老舊筆電 2018 年買的 asus zenbook 上面有雙系統 ubuntu 18.04 不過顯卡一直沒有順利啟用 不管了先用 cpu 硬跑 https://github.com/AUTOMATIC1111/stable-diffusion-webui 按照 repo 指令照做 然後我有參考這篇文章 亂跑一些 pip 安裝指令之類的 反正亂裝一通 https://zhuanlan.zhihu.com/p/628058158 在執行這個時 會遇到很多錯誤訊息 ``` ./webui.sh ``` 在 terminal 先設定一些環境變數 好像是關閉搜尋顯卡吧 ``` export COMMANDLINE_ARGS="--skip-torch-cuda-test --precision full --no-half" ``` 就可以了 實際跑起來，產生一張圖，大概要 5 分鐘左右
阿川收到網友提問如下： > 阿川您好 我是一位工業設計師，最近想轉職前端工程師，但年齡已38，有爬過一些文章大部分是說年齡確實會是就業一個限制但我想這在所有的行業大概都一樣，但同樣的能力和薪水要求如果企業可以用一個20幾歲的又何必用一個快40歲的人也是一個不爭的事實，想請問前輩的看法~ 非常感謝 > 我說明一下想轉職的原因， 1.評估一 下自己的人格特質 喜歡研究、解題(像是在工業設計需要3d建模，遇到建不出來的造型會不眠不休的找答案解出來並且從中得到成就感) 2.有設計美學基礎應該可以替成為前端工程師加分 3.軟體工程師遠端工作的機會較多，這樣找公司比較沒有地域限制 我在這邊寫一篇公開回答跟大家分享，給類似狀況的人參考。 --- 首先，我自己指導過年紀最大的，是31歲私立科大夜間部，原職餐飲服務業，之後順利轉前端。應該很少人比這背景更「非本科」 但我確實沒有指導過38歲的，所以我請這位網友先進我們 LINE 群組跟大家聊聊，裡面一堆工程師＆正在轉職的新手 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 我看了一下對話，大家鼓勵、勸退的意見，大概各一半，下面分享我的看法 --- 首先，我認為設計師出身，來寫前端的話，做出來的介面一定「非常漂亮」 站在雇主角度，能雇用這種前端工程師，一定是很難得，何況還是付 junior 的薪水！根本賺到吧！ 而且看這位網友的自我描述，感覺是喜歡研究、對細節在乎的人，這是滿適合工程師的特質 所以光論背景＆態度，我覺得滿適合轉職前端的，可能上班會被公司凹同時做設計師＆工程師 但一開始如果真的找不到工作，就給人家凹個半年一年，可能忍耐一下吧，畢竟有工作經驗＆作品集，之後工作會更好找 --- 接著，關於年齡的問題 這不是一個非黑即白的二元問題，沒有說超過30或35就一定不行、來不及之類的 本來就是程度問題，年齡越大就越有挑戰性，我是覺得38還好呀，還是有公司缺人 何況接案公司之類的，甚至本來就流動率高一點，又不是終生雇傭制，只是雇用你工作幾年而已，不會不合適呀 我期許這位兄弟，在新手練習階段，就做一些「超漂亮」並且「設計完成度遠超過一般轉職者」的網頁 這樣絕對會讓面試官印象深刻，這也是你的優勢所在 --- 再來，談一下花費的問題 很多人半路出家，是未滿30歲，拿政府補助去全職補習班 那些補習班自費的話，大概要十萬元 既然你沒有政府補助可以用，請先大量找免費或便宜的教材，先吸收，多試幾份，真的卡關了，再開始挑補習班 我本人就有設計一套「練功作業包」，我鼓勵所有正在轉職者，拿去搭配、練習 https://codelove.tw/courses 我有一些讀者根本沒去補習，光是寫這份作業包，就直接去面試＆開始上班了 --- 最後，這位網友在最開始有提到兩件事，我順便說明一下 ### 有設計美學基礎應該可以替成為前端工程師加分 -> Yes，加分，加爆了，這是很棒的技能組合 ### 軟體工程師遠端工作的機會較多，這樣找公司比較沒有地域限制 -> Yes，的確比一般職缺，WFH 的機會多很多，但是，就我觀察，在台灣，遠端彈性大到可以允許你「跨縣市」的公司，沒那麼多喔 通常是混合辦公居多，也就是一星期幾天在家、幾天進公司。所以，這方面不能太天真，請多多打開人力銀行 or 相關 FB 社團，多觀察為主 以上，簡單幾點分享，希望對你有幫助，祝各位轉職順利！
租用了新的雲端主機，有一天發現全部線上網站都掛了 經檢查發現是硬碟被吃光了，但是我應該沒有存那麼多資料＆圖片才對 使用指令慢慢檢查根目錄，在查到 var 時 ``` du -sh /var ``` 發現是 var 資料夾佔用了 125 GB，顯然問題就在這裡 接著使用 ``` du -h /var ``` 發現疑似是 mysql 資料夾，佔用大量硬碟空間 繼續使用指令確認 ``` du -sh /var/lib/mysql ``` 以及查看細節 ``` du -h /var/lib/mysql ``` 發現就是這個資料夾沒錯，cd 進去 ls 看一下，看到大量的 binlog 檔案，命名類似這樣 ``` ... binlog.000738 binlog.000739 binlog.000740 ... ``` 經研究，是 mysql 某種備份機制，暫時不深入研究，我目前不想使用這個備份功能 --- 輸入以下 SQL 緊急移除這些備份 ``` PURGE BINARY LOGS BEFORE NOW(); ``` 硬碟緊急狀況排除！ --- 接著要避免之後再出現這個問題 參考這篇做法 https://askubuntu.com/questions/1322041/how-to-solve-increasing-size-of-mysql-binlog-files-problem 建立獨立檔案，方便日後維護 ``` touch /etc/mysql/mysql.conf.d/howtomakeaturn.cnf ``` 放入以下內容 ``` # Added by howtomakeaturn at 2023-08-15 because of 100% disk usage issue. [mysqld] log_bin = # turn off binlog_expire_logs_seconds = 86400 # 1 day max_binlog_size = 104857600 # 100M ``` 完成之後重啟資料庫 ``` service mysql restart ``` 大功告成！應該大致關閉 binlog 功能了，持續觀察幾天看看！
https://youtu.be/I7dwJxGuGYQ ## TL;DR - 在使用 useContext 時，一定要將其包裝成 custom hook - [好讀版本](https://hackmd.io/@jason60810/rklVqNUh2) - [React 官方文件新增了 TypeScript 使用專文](https://react.dev/learn/typescript?fbclid=IwAR3Pgkr8xpS48Vwa0ADo3oagaAPKX1q05jHhtbXH8ltV8MKwa8FAvePoXPU) - [英文版本](https://jason60810.hashnode.dev/always-use-a-custom-hook-for-context-api-not-usecontext-react-context-api-typescript) ## 資料夾結構 ( 使用 next app route )  ### theme-context.tsx 一定要加上 `use client`，因為 useState 只能在 client component 運作 ， **特別注意，就算這裡加了`use client`，所有的子層還是 server component (預設)**  ### layout.tsx 加上 provider 之後，下面所有的子層都可以拿到值，不用用 prop 一個一個傳下去  ### page.tsx  ### logo.tsx 1. 因為 useContext 要在 client component 運作，所以要加上 `use client`。 2. 當使用 useContext 時，一定要引入 ThemeContext，用起來很麻煩 3. 因為 ThemeContext 預設是 null，所以當不是在 provider 裡使用 `useContext` 時 ( Logo component )，會發生錯誤，因此需要先確認有 context  舉例:不是在 provider 裡使用 `useContext`  ### 創建 custom hook  ### 使用 custom hook 現在引入 ThemeContext 和處理錯誤的問題，已經抽離到 custom hook 中  ### 加上型別 1. React.ReactNode，可以接受 JavaScript primitives ，如果只想要是 jsx 可以使用 React.ReactElement ( [react 官方文件](https://react.dev/learn/typescript#typing-children) ) 2. `type Theme` 可以讓 `useState` 在 get 和 set 時，可以使用正確的型別，例如:當想要 `setTheme('blue')` 時，會報錯，因為 `type Theme` 只有 'dark' 和 'light' 3. 在給予 createContext 型別時，可以利用 ts 的 union 讓 createContext 知道可能有 null 這個型別 ( [react 官方文件](https://react.dev/learn/typescript#typing-usecontext) ) 
大家好，我是站長阿川 我留意到 LINE 群組的討論非常踴躍 很多迷惘、想轉職的新手，各種發問，都有業界工程師幫忙回答，非常熱心！ 各位很多的回答「非常詳細」，完整到我覺得：只有群組內的新手看到，也太可惜！ 應該讓網路上更多人都能看到，這樣更造福眾生、未來有人 google 搜尋也能夠找到！ 繁體中文社群，需要知識不斷累積。如果一直在 FB 等等聊天室討論，然後被洗掉，有點可惜！ 這也是我建立 CodeLove 網站的初衷！所以我設計了一個新計畫，跟大家分享一下！ # CodeLove 前輩分享寫作計畫：VIP 審核限定 我鼓勵大家，在回答新手之餘，如果覺得 LINE 訊息文字篇幅不夠，或是 LINE 程式碼排版不易 請直接在 CodeLove 寫一篇完整文章，然後再貼到 LINE 群組內！ 舉例來說，我自己就有這樣回答 LINE 群組新手的習慣： [轉職軟體工程師的方法很多，到底該如何選擇：實體補習班、線上補習班、不花錢自學？](https://codelove.tw/@howtomakeaturn/post/NxN2Kx) [回答網友提問：如果前端要銜接後端的話，是不是學 node.js 比較快？](https://codelove.tw/@howtomakeaturn/post/2anP0x) [回應網友提問：我是新手前端，公司叫我學一點 php + laravel 串 API，該從哪邊學起呢？](https://codelove.tw/@howtomakeaturn/post/Zq4Ona) # 如何成為這個計畫的 VIP？ 原則上只接受「業界工程師」加入，也就是有工作經驗者加入！ 就算只有一年工作經驗，也是正在轉職的新手的前輩，所以也歡迎！ 越資深的話越好，因為您有大量的知識＆經驗可以分享！真的是大前輩！ **請在 CodeLove 網站上，任意發表一篇技術文章 or 工作心得，完成之後，點擊下方 LINE 群組加入：** https://line.me/ti/g2/9V19e5igoaUts-hrn1Vr3nNHMcGLLa1hJiaFRg 經過我審核之後，您就加入這個 VIP 群組了！ （例外情況：您是學生，但明顯有極大分享熱情＆知識，也會允許加入） # 身為這個群組的 VIP，可以幹嘛？ 首先，我希望您寶貴的文章，能被儘量多的讀者看到！ 您只要負責寫作就好，我會幫您「製造精美封面圖片」以及「行銷宣傳您的文章」！ 凡是 VIP 前輩發文，我都會在有超過三百人的群組「愛寫扣論壇：發問&交流&討論群」轉貼，並且「設定為公告置頂至少24小時」！ 再來，VIP 群組內都是「樂於分享、經驗豐富、寫作能力出色」的業界人士，大家可以在小群組內交流，我認為互相交換情報，也很有價值！ 最後，如果我覺得您的文章實在應該被「成千上萬的更多讀者看到」，我會直接到各大論壇，到處轉貼宣傳您的文章，類似下面這樣： - https://www.dcard.tw/f/softwareengineer/p/252600314 - https://www.dcard.tw/f/f2e/p/252598230 - https://forum.gamer.com.tw/C.php?bsn=60076&snA=7835159 - https://forum.gamer.com.tw/C.php?bsn=60292&snA=8421 我會確保您的文章被數千、數萬人閱讀！身為寫作者，通常文章四處發表，會到處被不同工程師嘴砲、開嗆，沒關係，這很正常，我會擋在砲火最前面！您不用被這些負面訊息轟炸，我只會回報有意義的正面留言給您！ 如果有很棒的留言或 feedback，我會貼回 VIP 群組內通知您！ # 我想加入，但我沒什麼寫作靈感，怎麼辦？ 首先，如果您有想發表的技術文章，當然可以直接當成寫技術部落格，寫一篇發表！ 再來，您可以在 LINE 群組，看看新手們都在問些什麼，然後就當作在回答他們，直接公開寫一篇完整回答！ 最後，也可以是您近期的一些技術筆記、工作隨筆，稍微整理之後發表，這種筆記也常常對後人很有價值！ # 結論 我真的覺得繁體中文世界，需要有一個優質的討論區、寫作園區，知識才能有效累積，這個國家的軟體產業才能進步、發達 另外，這個 CodeLove 論壇是有 [文章 API](https://codelove.tw/@howtomakeaturn/post/jqeDka) 功能的 您可以在這邊大量寫作，之後呼叫 API 串接到自己的部落格，markdown 格式與 html 格式的轉換我都已經幫您做好了 以上，各位熱心的工程師，誠摯歡迎您加入「CodeLove 前輩分享寫作計畫」！一起造福眾生吧！ https://line.me/ti/g2/9V19e5igoaUts-hrn1Vr3nNHMcGLLa1hJiaFRg 有問題歡迎直接留言與我討論！
## 課程目標 - 學會重置指令 ## 課程內容 來學一個強大的指令：重置 上一課的取消功能，是針對修改到一半的檔案 這時很自然會浮現一個問題：如果是之前已經提交過的內容，有辦法取消嗎？ 點開 `History` 分頁，假如我們今天對「上上次的提交內容」不滿，也就是 `add another work` 那筆 commit 不滿意，怎麼辦？ 其實很簡單！ 請把滑鼠游標移到 commit 上面，點擊右鍵，選擇 `Revert Changes in Commit` 你會發現 `History` 多了一筆 commit！ 這筆 commit 內容跟原本的 commit 內容完全相反，也就是會抵銷掉那筆 commit！ 打開資料夾看一下，會發現 `my-document-3.txt` 檔案整個不見了！ 這就是 git 強大的地方：不只是正在修改的檔案內容，連之前修改的內容，都可以追蹤、回溯、管理！ --- 看到這邊你可能會心想：為什麼要多一筆 commit？ 怎麼不把那筆 commit 直接刪除掉就好？ 其實，這是因為 git 通常是「團隊在使用」的工具 已經送出去的 commit，通常已經同步到很多人的電腦上了 如果這時工程師 A 刪了這筆 commit，工程師 B 刪了那筆 commit，那最後同步起來，大家電腦上的 commit 歷史記錄，到底長怎樣？很亂吧？ 所以，git 就一律設計成：想要回溯，就也是加一筆 commit！只是會自動進行相反的變化！ 這樣大家電腦上的 commit 歷史記錄，同步起來，就單純很多了！commit 數量永遠都是加法，不斷加上去而已！ 很聰明的設計吧！ ## 課後作業 這次來模擬實際工作的時候，你突然對之前的 commit 內容不滿意，想要把檔案內容還原的過程 繼續修改我們的履歷表專案吧！ 目前裡面有 `me.txt` `about.txt` `background.txt` `goals.txt` 四個檔案 你突然又有點反悔，覺得 `about.txt` 跟 `background.txt` 很多餘，想要把內容移回 `me.txt` 裡面 開發專案時，像這樣反反覆覆其實很正常，git 就是為了處理這種情境而生的 請切換到 `History` 分頁，找到之前把 `me.txt` 檔案改寫的那個 commit 然後使用 `Revert Changes in Commit` 功能來還原 commit 內容 還原之後，你可以看一下資料夾內容，應該會發現變回之前的樣子了！ 然後在 `History` 分頁應該會看到，多了一筆 commit，是用來記錄那筆還原的 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 請直接截圖 Github Desktop 視窗的內容，上傳到留言區
## 課程目標 - 學會基本指令 ## 課程內容 繼續上一課的內容，這次在同個資料夾內，再新增一個檔案 `my-document-2.txt`，裡面放入以下內容 ``` 我的第二個筆記檔案 ``` 接著打開 Github Desktop 看看狀況 會看到 `Changes` 分頁下面，現在有兩個檔案 分別點選檔案，可以在右側主視窗看到內容 --- 在 git 的觀念裡面，git 預期我們每次工作，都會修改到很多檔案 每次工作到一段落時，要提交進度給團隊時，都會一口氣將這些檔案變化送出去 這個所謂的「提交」，在 git 中稱之為 `Commit` 所以，你會很常聽到工程師說「這個 commit」、「那個 commit」、「上次的 commit」、「你昨天的 commit」 來試試看提交我們的第一次版本紀錄吧！ 每次提交，都需要打一段提示訊息，方便日後翻閱，大致知道每個提交的內容 請在左下角的 `Summary` 輸入 ``` this is my first commit, i am so happy! ``` `Description` 可以省略，不用輸入 接著點擊 `Commit to main` 你會發現 `Changes` 分頁列表清空了！本來的兩個檔案不見了 這是因為 `Changes` 代表「這次正在修改的檔案」，送出 commit 代表「本次修改完成並提交」了，所以就不再有「這次正在修改的檔案」了 請點選旁邊的 `History` 分頁，會看到剛剛的 commit，點選 commit 可以看到相關的檔案內容變化，很酷吧！ --- 讓我們多提交幾次檔案，試試看多次提交的感覺！ 先建立新檔案，請建立 `my-document-3.txt` 並放入以下內容 ``` 我的第三個筆記檔案 ``` 然後在 `Summary` 輸入 ``` add another work ``` 之後就 `Commit to main` 直接點下去！又送出一筆 commit 囉！ --- 來，我們再建立新檔案一次，請建立 `my-document-4.txt` 並放入以下內容 ``` 我的第四個筆記檔案 ``` 然後在 `Summary` 輸入 ``` add one more work ``` 之後就 `Commit to main` 直接點下去！又送出一筆 commit 囉！ --- 點開 `History` 分頁看看吧！ 會看到剛剛的三筆 commit 記錄都在裡面 點擊不同的 commit 可以看到對應的 commit 內容 Git 會追蹤整個資料夾內的所有變化！包括：建立新檔案、檔案內容的增加、檔案內容的減少、檔案被刪除 這些變化也會在每次提交 commit 時被記錄下來，所以都可以在 `History` 分頁看到記錄，很強大吧！ ## 課後作業 接續前一課的作業，你的專案目前有一個 txt 檔案 這次要來模擬實際工作的時候，反覆修改檔案、增減檔案的過程 請按照以下順序送出 commit **第一個 commit：** 請把目前的 `me.txt` 檔案放進 commit 裡面。 **第二個 commit：** 你改變心意，覺得拆成多個檔案比較清楚，之後分別寫內容比較好 請把 `me.txt` 檔案的內容清空，改放以下內容 ``` 我是XXX，請參考其它檔案，瞭解更多我的介紹與背景。 ``` 新增 `about.txt` 以及 `background.txt` 兩個檔案 並且把 `我是誰` 的內容放進 `about.txt`，把 `我的學歷` 的內容放進 `background.txt` **第三個 commit：** 你靈機一動，覺得在履歷寫一些個人的大目標，會讓人感覺氣勢很強 新增一個 `goals.txt` 檔案，裡面放入以下內容 ``` 我的目標，是成為貴公司的 CTO（技術長）。 ``` --- 最後，點開左側的 `History` 分頁，應該會看到以上三個 commit 的訊息！ 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 請直接截圖 Github Desktop 視窗的內容，上傳到留言區
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆剛轉職的新手在討論： 公司有實施 WFH 在家工作制度，但沒人可以詢問、經常怕自己漏看訊息、整天感覺更焦慮了，怎麼辦？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情，跟大家分享 --- 首先，我認為 WFH 是一種「團隊技能」，也就是説：這不是一個人就能做好的事情，需要整個團隊的合作 再來，因為是技能，這不是每個人一入職就會的東西，需要經過訓練 總體來說，我認為要習慣「新的四種溝通方式」，分別說明如下 # 批次溝通 在辦公室大家可以隨時找同事討論、發問，也可以臨時團隊開會之類的。 遠端工作很難這樣做。因為人與人溝通的頻率被迫降低了，所以每次溝通的內容量要提昇。 建議養成批次溝通的習慣。也就是一次詢問多個問題、一次安排多個工作事項。 舉例來說，大家早上團隊視訊/語音開會的時候，不要只是每個人安排一天的工作量，最好把一整週的工作事項都先預排好。 這樣一來，當你手上的任務卡住，需要詢問別人問題、等待答覆、等待別人工作先做完時，可以先改做其他待辦任務。 這會讓負責安排工作任務的主管，工作難度提高不少。但習慣一下會發現效果很不錯。 發問的時候也是一樣。可以拿筆記本、或是在電腦開個檔案，整個早上陸續遇到、想到的問題，都記錄下來。 下次終於有機會跟同事通話時，一口氣問清楚。 就算只是用聊天室也一樣。 我常常一口氣丟出好幾個不同事項的不同問題。反正同事有空再逐一回答即可。 # 過度溝通 遠端工作絕對要避免這個狀況：因為溝通誤會，導致做了整天的白工。 絕對不可讓這種情況發生。平常在辦公室，隨時都能知道同事在幹嘛、有疑問也可隨時跟主管確認。在家工作可不行。 所以要養成過度溝通的習慣。我自己習慣是剛剛視訊時已經講過的事情，結束前我會再統整一遍、然後每件事描述確認一次。 結束之後，還會把我剛剛確認的事情打成幾個待辦，貼到聊天室讓對方再看一次。等於每件事我都跟對方確認2-3次。 我甚至會把同樣幾件事情，換個方式、換個角度再重新描述幾次，讓相關人都同意，我才放心沒有做錯方向。 有留紀錄的話，事後出問題也比較容易討論責任歸屬。 總之，在家默默工作幾天，然後才發現通通在做白工，是絕對不可以發生的。 如果你發現在家工作之後，自己會一直跟同事確認事情，或是同事會多次重複確認同樣的事情，好像大家變得有點神經質？ 別擔心，這不但是很正常的現象，還是很鼓勵的現象。 # 被動溝通 拍同事的肩膀問問題、叫他過來開會、打電話給他…等等，屬於主動式溝通：以發問的人優先，被問的人配合發問的人的時間。 貼便條紙給同事、張貼事項在公告欄…等等，屬於被動式溝通：以被問的人優先，發問的人配合被問的人的時間。 被動式溝通以被問的人、接收訊息的人為主，有空時才答覆、做出反應。 遠程工作的團隊一定要習慣被動式溝通，否則遠程工作就沒有意義，也沒有效率，會變成很痛苦的事情。 網路時代讓被動式溝通輕鬆許多，只要採取多層次溝通就行了。 # 多層次溝通 多層次溝通指的是依照主動/被動程度的不同，分成至少3-4層溝通工具。舉例來說： 即時溝通：見面、手機/Skype/Hangouts/Zoom 通話 通訊軟體：Skype、Line、Facebook Messenger 工作聊天室：Slack 任務管理軟體：Bitbucket/Github、Trello 即時溝通是最主動的一種，碰面開會、打電話等等都算。在很多情況下，還是需要用這種方式討論、腦力激盪。最好每天約個固定時間線上通話一下。 通訊軟體則是次之的溝通方式，但因為訊息通知會一直跳出來，還是有點干擾。 工作聊天室是最常發生溝通的地方。這類工具的特色在於，忙著工作的人，可以直接把聊天室關掉，就不會被打擾。有空時再打開來看看有什麼需要回答的、討論的。 任務管理軟體是大家一起紀錄工作待辦事項的地方。需要日後方便翻閱的東西都記在這裡。 其它工具軟體像是 Google Docs、Google Sheets、hackmd 也都非常好用。 --- 以上是四種 WFH 個溝通方式，另外有兩點補充 # 被動式溝通優先，非必要不使用主動式溝通 上面提到的多層次溝通模型，越上面是越主動，越下面是越被動的溝通方式。團隊成員要慢慢習慣，非必要別使用主動式溝通。沒那麼急著得到答覆、急著需要處理的事情，就盡量用被動的手段溝通。 話雖如此，每天慣例性地在固定時段通話一次，可以大幅增加團隊的安全感。 # 每次開會都做線上筆記，所有檔案都對所有人公開 因為大家沒待在一起，開會完忘記會議細節的話，會需要一直詢問同事，很浪費時間也很煩。 所以開會時建議使用 Google 文件、hackmd 或是其他可以共同編輯的軟體，開會的時候一邊做線上筆記。 然後這些文件最好公開給整個團隊的人看到，讓全部資訊同步到全部人腦中。 這些技巧熟練之後，團隊成員不但可以專心工作，溝通能力也會全部上升。 像是跟客戶、合作廠商溝通這種本來就需要遠端溝通的任務，remote 工作者也比一般的工作者更知道怎麼溝通、避免溝通誤會。 # 結論 這些工作方式有點違反一般的工作直覺，所以容易被忽略。 但只要習慣一下，一定會發現遠端工作的好處，工作效率甚至比在辦公室更高。
你的轉職路上，還缺少一份練功作業包！寫完這九包，直接拿作品去面試上班！
本學院另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
