🔍 搜尋結果:專案

🔍 搜尋結果:專案

寫出 Clean Code 的一些技巧&原則

## 介紹 編寫乾淨的程式碼是每個軟體開發人員的基本技能。乾淨的程式碼不僅使您的程式碼庫更易於維護和理解,而且還能促進團隊成員之間的協作。在這篇綜合文章中,我們將探討什麼是乾淨的程式碼、為什麼它很重要,並為您提供一組最佳實踐和原則來幫助您編寫乾淨且可維護的程式碼。 - 原文出處: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 提供了程式碼審查、分支和合併工具,促進協作和程式碼整潔。 ##結論 編寫乾淨的程式碼不僅僅是一套規則,更是一種心態和紀律。它是關於建立易於閱讀、維護和擴展的軟體。通過遵循這些最佳實踐和原則,您可以成為一名更熟練的開發人員,生成高質量的程式碼。投入時間仔細檢查其他工程師的程式碼庫,特別是在開源專案中,可能是一種啟發性的體驗。通過這種探索,您將獲得對不同編碼風格和策略的寶貴見解。這種接觸使您能夠提煉出編寫原始、可持續程式碼庫的精髓。請記住,乾淨的程式碼是一個持續的旅程,通過練習,它會成為第二天性,從而實現更高效、更愉快的軟體開發。

主流商用軟體的 10 個開源選擇方案

一篇國外的熱門文章,關於一些開源選擇方案,翻譯出來給大家參考。 - 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 的替代方案 ![Medusa:Shopify 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n0lsrwimibby8vpfqyjc.png) 您可能聽說過 Shopify,它是遊戲中的大玩家。但現在有一個新的競爭者:美杜莎。讓我們來分析一下這兩者的優點、缺點以及本質。 ###Medusa 與 Shopify 相比的優點: **按你的方式做**:Medusa 是開源的,這意味著您可以根據自己的喜好對其進行調整。想要一個霓虹粉紅結帳按鈕嗎?大膽試試吧! **保留您的現金**:與 Shopify 不同的是,除非您使用他們的支付系統,否則 Shopify 會奪走您的部分銷售額,而 Medusa 不會動用您的口袋。 **選擇你的家**:透過 Medusa,你可以決定在哪裡開設你的商店。這就像在租公寓還是建造自己的房子之間做出選擇。 **權力歸於人民**:美杜莎受到社區的愛戴。這意味著定期更新、酷炫的新功能以及一群隨時準備提供幫助的人。 **沒有秘密**:開源意味著您可以看到幕後發生的一切。 ###Medusa 與 Shopify 相比的缺點: **開箱即用**:Shopify 擁有大量內建功能和龐大的應用程式商店。美杜莎在這方面仍在迎頭趕上。 **減少 DIY**:使用 Shopify,許多技術問題都會為您處理。美杜莎?您坐在駕駛座上,但這意味著您也必須應對道路上的顛簸。 **名言**:每個人都知道 Shopify。美杜莎仍然是學校裡的新生。 ###結論: 在 Medusa 和 Shopify 之間進行選擇可以歸結為您的特定需求和技術專長。如果您重視靈活性、客製化和成本控制,Medusa 是令人信服的選擇。然而,如果您正在尋找一個擁有良好記錄、廣泛內建功能和強大支援的平台,Shopify 仍然是一個強大的競爭者。 ##Hopscotch:郵差的替代方案 ![跳房子:郵差替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/omls8xf9jd2jocktn1mp.png) 您可能聽過 Postman,它是 API 測試領域的大人物。但有一個開源挑戰者踏入了這個圈子:Hopscotch。 ###Hopscotch 與 Postman 相比的優點: **像鳥一樣自由**:作為開源軟體,Hopscotch 不會花費您一毛錢。對於關注預算的小型團隊或個人開發人員來說,這可能是一個巨大的勝利。 **社群氛圍**:像 Hopscotch 這樣的開源工具依靠社群的投入而蓬勃發展。這意味著您有一群充滿熱情的人不斷改進它並加入很酷的新功能。 **透明度**:對於 Hopscotch,不存在任何幕後謎團。您可以看到每一行程式碼,確保您確切知道發生了什麼。 **輕量級**:Hopscotch 往往比 Postman 更輕量級,如果您正在尋找資源密集程度較低的東西,這可能是一個優勢。 **豐富的客製化**:由於是開源的,如果缺少您需要的功能,您可以自行加入或召集社群來提供協助。 ###Hopscotch 與 Postman 相比的缺點: **功能豐富**:Postman 已經廣泛存在並擁有大量內建功能。它就像是 API 測試的瑞士軍刀。 **流暢的使用者介面**:Postman 的使用者介面精美且直觀,讓新手可以輕鬆上手。 **協作功能**:透過其團隊協作工具,Postman 讓團隊可以輕鬆地協同工作、共享集合並保持所有內容同步。 **廣泛的文件**:Postman 參與遊戲已經有一段時間了,因此他們建立了一個龐大的教程、指南和社區帖子庫來幫助您。 **整合生態系統**:Postman 提供與各種其他工具的集成,使其更容易融入現有工作流程。 如果您熱衷於開源,喜歡修補,並且正在尋找一個輕量級工具,那麼 Hopscotch 可能是您最好的新朋友。但如果您想要一個功能豐富且擁有良好記錄的環境,並且不介意花一些錢購買高級功能,那麼 Postman 仍然是一個不錯的選擇。像往常一樣,關鍵是找到適合您需求的工具。 ##Rocket Chat:Slack 替代方案 ![Rocket Chat:Slack 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jwewh09g82kg1ez8egay.png) 當談到團隊溝通工具時,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 Chrome 替代品](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cg5kruse2v60hvr61dwo.png) 就網頁瀏覽器而言,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:自動化競技場 ![n8n vs. Zapier:自動化競技場](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/au3eybw4auja3m6kjipu.png) 在工作流程自動化領域,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 的替代方案 ![Webiny:Webflow 和 Framer 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ihuqbo2d9cqmpvorr98.png) 在網頁設計和開發領域,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 的替代品 ![Penpot:Figma 替代品](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6qbwjeb3qobr4ji0oxpp.png) 在設計界,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 的替代方案 ![Dub.co:Bit.ly 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ye97eh00t801zuixzoe8.png) 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:日曆的替代方案 ![Cal.com:Calendly 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/utln9g2ijnenv4y9d8ub.png) 在安排會議和約會時,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 替代方案 ![NocoDB:Airtable 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/phokr8123e2qpxge9ix5.png) 您可能已經看過 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 的可靠性則讓您的團隊溝通順暢。 關鍵是,你並沒有被歸類。這一切都是為了找到適合工作的工具,有時,這意味著將開源精神與專有軟體的精美體驗相結合。 因此,當您冒險進入科技領域時,請記住:這不是選擇立場的問題。它是為了找到讓您的數位生活更輕鬆、高效和愉快的完美工具。潛入、實驗並製作你獨特的科技馬賽克!

非同步 JS 訓練二:第4課 ── 認識 callback hell 與收尾處理

## 課程目標 - 認識 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 群組,有幾個工程師&想轉職的新手在討論: > 各位前輩們好,小弟是自學轉職的前端工程師,目前有兩個 offer,一個是接案公司;一個是自有產品,自有產品的那間目前只有一個junior前端,進去有問題可能沒人可以問,但看網路上好像都不太推接案公司。猶豫了很久選不出來想聽聽各位前輩的看法。 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好,我決定單獨寫一篇文章討論這件事情,跟大家分享 --- 阿川幫大家從幾個角度來分析比較一下 # 學習的深度、廣度 接案公司通常是使用類似的技術,接不同的客戶專案 好處是可以接觸很多不同的客戶,認識許多不同產業 壞處是做久了可能會開始有「重複感」,也就是好像一直在做類似的事情,有點學不到東西 產品公司通常是長期深入研發自家產品、技術 所以會在同一領域鑽研,通常可以玩得比較深入、學得比較深入 壞處是可能長期只能使用同一技術、框架,沒機會玩別款的 接案公司有時需要面對不同技術需求的客戶,有機會玩玩不同款的語言、框架、技術 # 工作的時程壓力 接案公司的時程壓力來自於「客戶」,通常已經由老闆、PM 跟對方承諾某個時間,甚至已經寫在合約上 如果同時在開發多個專案的話,有時候工程師會感到相當的壓力 通常是忙一陣、閒一陣這樣 產品公司沒有這樣的壓力,壓力通常來自於「公司沒有在賺錢」 如果公司經營穩定、產品前景看好、主管有肩膀好說話 那像這樣的時程壓力,通常會小很多 # 技術債 稍微資深的工程師,在不同公司面試時,一定會問的問題是:入職之後,需要維護 legacy(老舊)專案嗎? 維護老舊專案、負擔技術債,是一件很悲慘的事情,也是開發者的主要離職原因之一 你會被迫用已經過時的工具、語法在開發,並且要把設計拙劣的系統架構「硬搬進自己腦子裡」才能消化開發 這過程能學到東西嗎?我認為不多,基本上是在糟蹋生命 接案公司來說,如果主要負責一些新客戶,那麼經常在重啟新專案,技術債問題或許不大 如果手上負責很多「超舊的專案與客戶」,那麼可能會遇到技術債的問題 自有產品的公司,則是走向另一個極端 如果是持續有在更新版本、升級套件的熱情公司,那麼技術債問題不大 如果是有年紀、穩定的系統,那麼版本問題、系統架構的技術債問題,可能很大 嚴重起來會比接案公司更慘,因為就只有一個專案在跑 # 進去有問題可能沒人可以問 大家都希望團隊能有一個又強、人又好、又願意幫忙自己的好同事 不過這可遇不可求,身為正職工程師,你需要能夠獨立解決問題 畢竟人家也面試過了,應該就是合格了,如果真的丟一些無法解決的問題給你,那也不全是你的錯 另一方面,沒人可以問,代表你獨立做決定的空間很大,這未必是壞事 # 結論 剛轉職的新手上班,我是覺得去接案公司上班也可以 通常接案公司很缺人,也比較願意給半路出家者機會 而且開始工作的前 1-2 年,不管去什麼公司,通常都能學到很多東西 待了 2-3 年之後,覺得無聊了,再找新工作也不遲 所以回到原 po 的問題:我認為兩間公司都可以,沒有說接案公司一定比較不好 畢竟,就算是自有產品的公司,如果產品本身超爛,根本永遠不會賺錢、沒人想用 那就只是一大群人在「陪老闆追逐他的個人夢想」,那其實也是相當浪費時間的,不如在接案公司專心滿足客戶,比較充實 --- 我建議閣下不妨從「人和」的角度來觀察一下:你喜歡面試時看到的那些人嗎? 老闆、主管、同事,你喜歡跟他們相處嗎?還是你有點畏懼他們、覺得他們有點冷漠、城府、可怕? 如果實在不知怎麼選,就選你喜歡的那群人吧!跟合得來的人一起工作,總是不會太不舒服! 以上,簡單分享,給各位參考!也歡迎大家多多在留言區補充經驗、意見!

給想成為自由工作者、接案工作的一些簡單建議

上一篇文章談了「同時上班&接案&創業」的簡單策略 我發現滿多人對於接案這塊比較感興趣,提了很多問題 我簡單分享一些心得&建議 --- > 請問原po,在準備接案有想過:我的能力已經足夠接案,這種類似的想法嗎? 這幾年因為 freelancer 的身份,在一些活動、場合會遇到各種領域的 freelancer 每次遇到這些新朋友,我都會問:你是如何開始的呢? 我發現有 90% 的機率,得到的故事都是以下這樣: 「我工作幾年之後,在 XX 年的時候離職,想說休息一下,看看之後要幹嘛。這時候有前同事來問:他那邊有人在問誰能接案,能否幫忙?」 「我就先接下來,想說那做完這筆,之後再看要不要找工作。結果做完之後再休息一下,這時又有朋友來問,能不能接某個案子。」 「我就又接一個,然後再休息一下,反正不急著找新工作。就這樣加減接案,做一陣、度假一陣。過了幾個月、幾年之後,有一天發現:我好像可以一直這樣下去。」 所以根據我個人經驗&觀察:根本沒有人會下決心說,我要從此離職,轉身變成一個全職 freelancer 都是工作轉換的空檔,自然發生的。如果案子沒了,那就開始找工作上班,幾年之後離職休息,上面的故事會再重複一次。 所以重點是:為什麼這些人在轉換的空檔,會有人來問? 其實就是 1. 在工作上的表現不錯,同事、主管、合作廠商、親朋好友都覺得你值得信賴 2. 有稍微經營個人品牌,身邊的人稍微知道你是做什麼的,然後根據互動經驗覺得你「溝通能力」不錯,會讓人想合作 3. 你稍微有一點勇氣,能夠接受這種「休息一下,想想看之後要幹嘛」的狀態長達數個月之久,很多人在這狀態會很緊張,急著找新工作 然後一些有趣的事情,可能就會自然發生。當然你需要有一點點積極、願意擁抱未知,大概是這樣 --- > 我其實不清楚到底要做到什麼程度?業界常用的必備工具有沒有掌握?發生問題解決辦法能不能處理? 不論是工作、接案,基本上就是養成「挑戰能力範圍之外一點點」的習慣 不要超出能力太多,會被壓力擊倒、會開天窗、你誠信會出問題 不要完全做已經熟悉的事情,這樣沒有進步,久了會有點無聊 就做超出能力一點點的事情,常常這樣的話,久了自然會有把握&經驗 這需要時間累積,沒有捷徑、沒有秘訣 --- > 哥有推薦接案的案源嗎 根據我的經驗,你在台灣註冊任何接案平台,或者去 FB 社團搶案子之類的,案件內容&報酬都會「有點悲劇」 這沒辦法,平台化的東西,大家就是殺價競爭、紅海市場廝殺,比誰更樂意壓榨自己 你就算用英文搜尋,找國外接案平台,狀況也差不多,沒有好到哪去 所以我不推薦任何案源,我推薦你經營個人品牌。雖然有點丟臉,好像讓親朋好友看到你在老王賣瓜 但是行銷就是這樣,你多少要推銷自己一點,不然看起來一點自信都沒有,誰又能放心付個高價錢給你做案子呢? 那怎麼經營個人品牌?參考我後面的回答 --- > 希望能分享關於案源品質管控的部分(怎麼避開爛專案)🙏 如果你很外向、具有那種油條的業務性格,那你就多多跟各種客戶談生意,多多談判,累積經驗就行 如果你很內向、不具有那種談判性格,實在很怕踩雷,那我建議你:只跟你喜歡的人合作 在 LINE 上打字、Email 往來的時候,感覺對方連話都講不清楚嗎?那你們實在溝通方式有差,建議婉轉拒絕吧 用 LINE 語音,或者視訊軟體開會,感覺對方有點城府,你有一點怕他嗎?那你們做人處事原則大概很不一樣,建議婉轉拒絕吧 實在很想避開爛專案,那就只跟你覺得「跟這個人當朋友好像也沒問題」的案主合作吧! 當然工作機會,會減少很多,但是,你跟案主互相折磨、互相為難、互告上法院的機率也會減少很多 --- > 想問有建議其他職業的做法嗎? 抱歉我比較熟悉寫程式領域 但其他職業的話,我覺得經營個人品牌總是不會錯 我滿建議大家 1. 部落格 2. Podcast 3. YouTube 4. 短影片 選擇一種格式來創作,分享一些東西,目標不用高,就花幾年時間,試著經營出 1,000 粉絲就好 分享什麼?結合你的興趣 or 專業,弄點「好笑的有趣的」或「有知識技術含量的」或「能幫讀者省錢或避免踩雷或有利益可圖的」內容,就這些即可,總是會有讀者,因為看到根本賺到 這過程會學到行銷、推銷、品牌、定位,很多很多商業基本知識,零收入沒關係,就是一種商業練習 千萬不要眼高手低、整天空想、整天焦慮沒完沒了,想要搞很大,過了好幾年還是 100 粉絲都沒有 慢慢來吧,但務必要有點進度、養成進步的習慣 以上,簡單幾點分享,希望對你有幫助

阿川的軟體工程師生涯規劃:同時上班&接案&創業~!

阿川收到網友提問如下: > 您可以分享您的軟體工程師職崖規劃嗎?再次感謝 我個人的職涯規劃其實比較偏激,是同時做「上班&接案&創業」這三件事 我簡單說明一下爲什麼我會這樣做,給大家參考 --- 我是 79 年次,2013 年退伍的,大學資管系畢業 出社會第一個月我就發現,我滿不喜歡上班的,但是我沒有能力、也沒有錢創業 於是我設計了一個我稱之為「三把梯子」的方法論,作為長期生涯指引 # 三把梯子理論 第一把梯子是上班:成為資深工程師、跳槽更大公司、賺更多薪水,這樣不斷往上爬 第二把梯子是接案:接親戚朋友介紹的案子、累積個人品牌、得到更多的客源,開公司接案,這樣不斷往上爬 第三把梯子是創業:研發軟體產品,從 side project 開始,從 open source 開始,學習行銷,學賺錢、寫更多產品、開公司創業,這樣不斷往上爬 基本上就是上班族、自由工作者、創業者三種職業生涯 --- 我給自己的三把梯子指引是:先從第一把梯子開始往上爬,稍微爬一段,就往旁邊的第二把梯子踩過去,接著爬 接著在第二把梯子慢慢往上爬,稍微爬一段,準備好了就往第三把梯子爬過去,慢慢往上爬 在這個過程中,只要覺得腳步沒踩穩、會摔死,就往回踩過去,爬前一把梯子 你可能覺得很離譜:想要同時兼顧三件事,不就會變成通通都搞砸嗎? 其實,你只要... # 做同時對兩三把梯子有幫助的事情 職涯的大方向有了,接著就是付諸行動,要做一些能「同時對兩三把梯子有幫助」的事情 ## 部落格 我在 2013 年想到的事情是「寫部落格」,我非常勤奮地寫了兩三年,很多文章都還找得到 - https://blog.turn.tw/ - https://startup.turn.tw/ - https://dev.turn.tw/ 寫部落格、並且試著得到流量,會同時學到寫作、銷售、溝通能力,對三把梯子都會有幫助 我在寫到多篇文章都有數十萬瀏覽量之後,我就大致知道自己掌握這項技能了 ## 研討會 接著我想到的事情是「參與 conference 分享」 其實這沒有大家以為的那麼難,算是寫作的延伸加強版而已,拿原創的文章去一些小聚、研討會發表 我在成為 PHPConf Taiwan 2015 以及 LaravelConf Taiwan 2018 的講者之後,我就大致知道自己掌握這項技能了了 ## 做專案 再來是「寫 side project」以及做「open source」 一開始可以先做好玩為主,但之後要稍微從一些商業野心出發,才能學習 `monetization` (賺錢)這件事 我做了一些專案,在國內外論壇到處分享,成績馬馬虎虎,但我也學到很多 --- 上面這三件事情,會同時對「前兩把梯子」有巨大幫助,在找工作、或者接案的時候,很多人會更信賴你,對第三把梯子也會有點幫助 當然,像這樣同時爬三把梯子,沒辦法跟「專心爬一把梯子」的人比,這是一定的,而且要付出的時間相當龐大 但是,這讓我獲得足夠的安全感,避免一次做太高風險的事情,而且也有後路可退 # 我目前的三把梯子的進度 第一把:我現在去投履歷、找工作,在各種大小的公司都還是有面試機會,也有很多業界的朋友可以幫忙介紹,要上班沒問題 第二把:在完全不主動去找案子的情況下,很多朋友會幫忙轉介紹案子給我 我也是美國接案平台的簽約工程師 https://www.toptal.com/resume/chuan-hao-you 有時會接一些歐美的案子,所以要接案沒問題 第三把:我大概做了70個左右的 side project 目前正在經營的有這幾個 梗圖工具 https://memes.tw/ 每月60萬不重複使用者 咖啡廳資料 https://cafenomad.tw/ 每月3萬不重複使用者 活動平台 https://yii.tw/ 每月2萬不重複使用者 工程師交流 https://codelove.tw/ 您目前正在看的網站 另外還有 房地產 https://landchart.tw/ 書評網 https://wenwen.life/ 美女圖 https://beautyhunt.tw/ 批踢踢閒逛 https://www.ptt.best/ 這些網站,其中有幾個,是有一些收入的,所以第三把創業的梯子也還可以 目前這三把梯子,其實我都還正在爬,並沒有最後一定會待在哪一把梯子上面 # 結論 這邊簡單分享我替自己設計的職業生涯,「三把梯子」算是一種很偏激的職業生涯 業界像這樣做的工程師應該非常少數,最大缺點就是要花費的時間非常多,優點就是,其實樂趣不少 其實,學無止盡,這就只是同時在「技術」跟「商業」兩方面花時間學習而已 能分享的事情還有很多,大家有興趣就多多按讚吧,也許我再多寫一些這方面的文章! 也歡迎大家多多發表文章,這個 CodeLove 就是我做來給工程師們互相交流的地方! 以上簡單分享,希望對你有幫助~!

軟體工程師最討厭的事:七個嚴重破壞生產力的因素

- 原文出處:https://dev.to/surajondev/top-7-things-that-kill-developer-productivity-ef9 ## 1. 會議 ![會議](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fki43f2r0cn4z9wozpnm.png) 無效的會議是最不必要的因素之一,它會導致開發人員的生產力下降。寫程式需要專注。進入專注模式平均需要大約 30 分鐘。但由於多次會議,這種專注被打破,開發人員必須重新開始。 還有時間消耗,因為有時 10 分鐘的會議會延長到一個小時。此外,某些會議也需要不必要的出席。如果會議不直接涉及開發人員的專業知識,通常根本不需要他們出席。 --- ## 2. 技術債(晚點再修) ![技術債](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rwytk0f8i7zknvh2q3ry.png) 技術債務可以簡單地定義為“晚點再修”的心態。 最初,我們嘗試使該功能正常工作,並將優化留到以後進行。這可能在短期內有效,因為它可以加快專案速度,並且您可能會按時完成任務。但一次又一次地這樣做將會留下大量的工作要做。從而使得維護、擴展和改進軟體變得更加困難 技術債務會在很多方面阻礙開發人員的生產力。其中一些是: - 程式碼審查的瓶頸:當技術債務增加時,會導致程式碼審查時間的增加。 - 更多錯誤:由於最初的動機是速度而不是優化,這將導致引入隱藏的和未被注意到的錯誤。 - 程式碼質量下降:只希望「能跑就好」,會導致程式碼質量差、程式碼審查隨意、甚至沒有程式碼註釋、程式碼複雜等等。 上述所有要點都需要額外的時間來解決。從而拉長了專案時間。 --- ## 3. 程式碼審查 ![程式碼審查](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1n2x66ojptbke84tsj4g.png) 程式碼審查需要時間,如果審查過程太慢或過於官僚,可能會延遲新程式碼的整合並減慢整個開發過程。有時開發人員提出 PR,但程式碼審查人員沒有時間審查。從而增加了開發人員處理下一個任務的時間。 對於程式碼審查,開發人員可能必須參加多次會議,從而導致開發人員的工作效率下降。通常,對程式碼的不明確或複雜的反饋可能需要更長的時間才能解決問題,因為需要進一步的對話才能理解。程式碼審查很重要,但以錯誤的方式進行只會導致生產力的降低。 --- ## 4.微管理(缺乏自主權) ![微管理](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wcoiwombq5b0wm9xhz3c.png) 微管理是一種主管密切觀察和管理下屬工作的管理方式。當經理試圖控制開發人員的編碼方式時,就會發生這種情況。這可能會導致開發人員對其程式碼、流程、決策和創造力的控制力減弱。 它可能會以多種方式導致開發人員生產力缺乏。其中一些可以是: - 缺乏動力:微管理可以表明組織對開發人員能力的信任度較低。這樣,開發人員很容易感到失去動力。 - 創造力較少:開發軟體是一項創造性的任務,您需要集中精力探索創造性的解決方案。但微管理會導致對程式碼的控制減少,甚至阻礙開發人員的創造力。 - 決策緩慢:開發人員必須從經理那裡得到簡單決策的確認,在此過程中浪費了大量時間。 在所有這些情況下,開發人員的生產力都會下降。 --- ## 5.倦怠 ![倦怠](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yvffwbq92ll0lymn9bdc.png) 倦怠是開發人員最關心的問題之一。在緊迫的期限內處理複雜且具有挑戰性的專案,以及交付高質量程式碼的持續壓力可能會導致倦怠。它最終會導致開發人員的生產力下降,因為它會降低開發人員的注意力和專注於編碼和建置的能力。 它還會導致開發人員的創造力和解決問題的能力下降。它最終將導致開發週期變慢。 --- ## 6. 糟糕的文件 ![糟糕的文件](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ai2g4hry3o2gkmtszktn.png) 文件對於開發人員來說至關重要,因為它傳達了有關程式碼、專案和流程的關鍵訊息。糟糕的文件可能會導致開發週期的嚴重延遲,因為開發人員將花費更多時間來嘗試理解程式碼庫、專案和流程。從而導致開發人員的生產力降低。 在開發人員入職時,提供糟糕的文件將導致開發人員花費更多的時間在任務上,例如設置專案、管理環境、理解程式碼和其他相關的事情。如果沒有明確的文件,維護和修改現有程式碼就會變得困難。由於擔心破壞功能,開發人員可能會猶豫重構或進行更改。因此,開發人員的生產力將被浪費在非核心任務上。 --- ## 7. 不切實際的最後期限 ![不切實際的截止日期](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1vflqfz9u7pso1jwl2di.png) 截止日期是讓開發人員失去動力的因素之一。當你被要求在短時間進行大量工作時,你會很容易感到沮喪。它會導致倦怠、程式碼質量差、程式碼審查疏忽等,這會導致技術債務的積累。從而導致開發人員的生產率下降。 截止日期很重要,但設定不切實際的截止日期給開發人員施加壓力,會給他們帶來壓力。在壓力下,整體生產力和程式碼質量都會下降。 ## 結論 有些小工具,可以克服這些挑戰,以在開發人員的健康和生產力之間建立平衡。 以下是一些可以幫助您提高生產力的工具: - [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)。 我希望這篇文章能夠幫助您了解開發人員生產力下降的原因。感謝您閱讀這篇文章。

Github Desktop 新手入門教學:第7課 ── 能夠從 Github 抓專案下來

## 課程目標 - 能夠從 Github 抓專案下來 ## 課程內容 我們在上一課發佈專案到 Github 了 這次來學習把專案從 Github 抓下來吧! 首先來把電腦上的專案刪掉,模擬我們今天拿到一台新電腦的情境 在主視窗點選 `Current Repository` 會秀出專案列表 對著我們的專案 `my-first-repo` 按右鍵,然後選 `Remove` 刪除,確認視窗繼續按 `Remove` 會發現 Github Desktop 變回初始畫面了! --- 但目前只是 Github Desktop 停止追蹤專案而已,那個資料夾其實還在電腦上喔 請在電腦上,直接前往那個資料夾,會發現檔案都還在 請把 `my-first-repo` 整個資料夾刪掉,這樣才是真的模擬拿到新電腦 --- 現在來試著把專案從 github 抓下來吧! 點擊 `Clone a Repository from the Internet` 因為已經登入 github 了,應該會顯示專案列表 找到上次發佈的 `my-first-repo` 專案 (如果專案沒出現,畫面上有一個重新整理的按鈕,按一下) 然後 `Clone` 按鈕按下去 成功囉!專案回來囉! `History` 分頁按下去,看看是不是跟之前都一模一樣? 軟體工程師在跨裝置工作(使用多台電腦)、或是多位工程師合作時,就是這樣同步專案內容的! ## 課後作業 接續前一課的作業,專案已經傳到 github 了 現在來模擬你拿到新電腦,第一次從 github 抓專案的情境 請把原本電腦上的那個專案資料夾,整個刪掉 這時去看 Github Desktop,應該會顯示「Can't find」開頭的提示 請將 Github Desktop 視窗截圖,這是本次作業的第一張截圖 截圖完畢之後,點擊畫面上的 `Remove` 將這個專案刪掉 --- 現在電腦上已經沒有專案了,就當作你今天拿到一台新電腦,準備開始工作,要把 github 上的專案抓下來 請點擊 `Add` 然後選 `Clone Repository...` 接著找到你在 github 上的專案 把剛剛那個專案整個抓下來之後,你應該會發現,剛剛整個刪掉的專案資料夾,現在內容又通通出現囉! 請將 Github Desktop 視窗截圖,這是本次作業的第二張截圖 --- 完成以上任務,你就完成這次的課程目標了! --- 交作業的方法: 請把第一張、第二張截圖,分別貼到留言區

Github Desktop 新手入門教學:第6課 ── 能夠發佈專案到 Github

## 課程目標 - 能夠發佈專案到 Github ## 課程內容 我們已經在上一課成功連線 Github 了 這一課,來把我們的專案發佈到 Github 吧! 如果是跟同事合作,處理公司的專案,我們稱為 `Private repository` 如果是開源專案,發佈給全世界工程師使用,我們稱為 `Public repository` 在 Github Desktop 主視窗,會看到 `Publish repository` 按鈕 點下去,會看到 `Name` 預設就是專案名稱,`Description` 可以省略不填 下面的 `Keep this code private` 預設是勾選,也就是私人專案,把這取消掉,就是開源專案了 最後的 `Publish Repository` 按鈕按下去,視窗會自動關閉,代表發佈成功了! 回到 Github,右上方點擊自己的頭像,`Your repositories` 點下去,會看到剛剛發佈的專案! 以我的範例來說,我的專案在這邊,可以看到專案的各種檔案內容 https://github.com/howtomakeaturn/my-first-repo 然後這邊可以看到 commit 歷史記錄 https://github.com/howtomakeaturn/my-first-repo/commits/main 很酷吧! ## 課後作業 接續前一課的作業,現在你打算把專案上傳到 github,當做雲端備份,也方便自己在桌電、筆電上都能工作 請點擊 `Publish repository` 將專案發佈到 github 發佈之後,你應該會在 github 網站上面,找到剛剛發佈的專案、看到專案的程式碼、也能看到多筆 commit 歷史紀錄 完成以上任務,你就完成這次的課程目標了! --- 交作業的方法: 請把 github 專案連結,貼到留言區

Github Desktop 新手入門教學:第4課 ── 學會重置指令

## 課程目標 - 學會重置指令 ## 課程內容 來學一個強大的指令:重置 上一課的取消功能,是針對修改到一半的檔案 這時很自然會浮現一個問題:如果是之前已經提交過的內容,有辦法取消嗎? 點開 `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 視窗的內容,上傳到留言區

Github Desktop 新手入門教學:第3課 ── 學會簡易的檔案變化操作

## 課程目標 - 學會簡易的檔案變化操作 ## 課程內容 來學一點簡單的檔案變化操作吧! 打開 `my-document-1.txt` 然後多加下面這行字 ``` 是一段亂打的字 ``` 你會在 Github Desktop 再次看到 `my-document-1.txt` 檔案出現了,然後內容變化會在右側出現 假設我們今天對這次的變化內容不滿意,想要整個取消,該怎麼用 git 做到呢? 請把滑鼠游標移到檔案上面,點擊右鍵,選擇 `Discard Changes...` 會跳出確認視窗,跟你確認真的要捨棄這些變化嗎?點擊 `Discard Changes` 會發現檔案消失在 `Changes` 分頁囉! 代表檔案內容又變回去了,所以目前沒有任何變化~很酷吧! 軟體工程師在工作時,常常會一口氣修改很多檔案,然後常常改到一半又對某些修改反悔,這時就可以這樣快速取消變化! ## 課後作業 這次來模擬實際工作的時候,檔案改到一半,反悔了,然後取消的過程 繼續修改我們的履歷表專案吧! 首先,你想補充更多學歷資訊 請先在 `background.txt` 加入以下資訊 ``` - 國小:開心國小 - 國中:快樂國中 ``` 你應該會在 `Changes` 分頁看到變化的部份出現 請將 Github Desktop 視窗截圖,這是本次作業的第一張截圖 --- 想了一下,你突然又覺得,國中國小學歷,應該沒人關心,還是別放進去好了 請使用 `Discard Changes...` 功能把 `background.txt` 檔案變回原樣 這時再看 `Changes` 分頁,應該又乾乾淨淨了,裡面沒有東西 請將 Github Desktop 視窗截圖,這是本次作業的第二張截圖 --- 完成以上任務,你就完成這次的課程目標了! --- 交作業的方法: 請把第一張、第二張截圖,分別貼到留言區

Github Desktop 新手入門教學:第2課 ── 學會基本指令

## 課程目標 - 學會基本指令 ## 課程內容 繼續上一課的內容,這次在同個資料夾內,再新增一個檔案 `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 視窗的內容,上傳到留言區

Github Desktop 新手入門教學:第1課 ── 學會專案初始化

## 課程目標 - 學會專案初始化 ## 課程內容 在開始之前,我先再次說明一下 Git 與 Github Desktop 的不同 Git 是軟體工程師每天都會用到的,強大的專案版本管理工具,本身是命令列工具,要一直在終端機打指令 Github Desktop 是 Github 公司,為了方便入門者,所開發的 GUI(圖形化介面)工具,用起來簡單很多 本課程會交替使用這兩個名詞,前者代表 Git 正在發揮作用,後者代表正在操作 Github Desktop 功能 有點分不清楚沒關係,反正就知道有這差別即可,日後經驗更多,會越來越清楚 --- 讓我們開始玩玩看 Github Desktop 吧! 請先前往官網下載並安裝 https://desktop.github.com/ 在登入 Github 帳號的步驟,先選 `Skip this step` 跳過就好,我們後面課程再登入就好 --- 進入到 Github Desktop 主畫面之後,首先我們要設定一下 git 基本資訊 也就是在用 git 管理專案紀錄時,每次提交變化時,當筆提交的「作者資訊」 請在 Github Desktop 上方的導覽列,選擇 `Preferences` 然後選擇 `Git` 把 `Name` 跟 `Email` 欄位填寫一下,然後點擊 `Save` 按鈕,就可以囉! --- 來建立第一個用 git 管理的專案吧! 在主畫面,點選 `Create a New Repository on your Hard Drive` `Name` 就輸入 `my-first-repo` `Description` 可以省略不填 `Local Path` 隨便選一個方便的路徑 其餘的選項都保持預設就好,不用勾選 `Create Repository` 點下去,就建立第一個專案資料夾囉! --- 請在電腦上,直接打開那個資料夾,然後在資料夾裡面新增一個檔案 `my-document-1.txt`,裡面放入以下內容 ``` 我的第一個筆記檔案 ``` 接著打開 Github Desktop 看看狀況 會看到 `Changes` 分頁下面,有出現 `my-document-1.txt` 這個檔案 然後右側的主視窗,有顯示出檔案內容 這代表 git 已經發現它的存在了 我們成功使用 git 開始追蹤專案的歷史變化了! 這是一個很好的開始,本課先做到這樣就好! ## 課後作業 假設你正在準備履歷表,整理一些自我介紹、經營個人品牌的檔案 請建立一個名為 `my-resume` 的資料夾,並使用 git 開始追蹤這個資料夾 請在其中建立一個 `me.txt` 的文字檔案,裡面放入以下內容 ``` # 我是誰 - 我是XXX,目前在自學程式設計 # 我的學歷 - 高中:積極高中 - 大學:品質大學 ``` 你應該會在 `Changes` 分頁看到檔案出現 然後在右側主視窗,看到文字檔案的內容 完成以上任務,你就完成這次的課程目標了! --- 交作業的方法: 請直接截圖 Github Desktop 視窗的內容,上傳到留言區

Laravel 5.8 升級到 8.83 版本心得&筆記分享

手上有多個網站 都是 Laravel 5.8,放在一台 Ubuntu 18.04 的機器上(租用 Linode 機器) 四、五年了,一直沒去更新,最近終於下定決心來更新 首先把 Laravel 5 -> 6 -> 7 分多次升級,然後部署 都還算順利,官方的 upgrade guide 很清楚,簡單照做就完成 但是無法升到 laravel 8 因為需要 php 8 我那台 ubuntu 18.04 安裝 php 8 一直失敗 直接升級 OS 也失敗,一堆問題會出現 最後決定,在 Linode 租一台新的 Ubuntu 22.04 然後把專案通通搬過去 --- 因為專案中很多「用戶上傳的圖片」放在 local,所以都需要一起搬運 最後是用 scp 硬搬檔案 然後用 mysqldump 搬運資料 才終於順利升級到 laravel 8.83 了 詳細用到的指令大概像這樣 ``` scp -r [email protected]:/{PATH}/{FOLDER} /{PATH} scp -r [email protected]:/etc/apache2/sites-available/{CONF_FILE} /etc/apache2/sites-available/ a2ensite service apache2 reload create mysql user & database with phpmyadmin mysqldump --column-statistics=0 --default-character-set=utf8mb4 -h xxx.xxx.xxx.xxx -u {USER} --single-transaction -p{PASSWORD} {DATABASE} > /home/dump.sql; mysql -u root -p{PASSWORD} {DATABASE} < /home/dump.sql artisan down legacy site composer install -> new site is now online ``` --- 簡單筆記分享一下,希望能幫到一些人~ # Refs - https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-22-04#how-to-find-your-server-s-public-ip-address - https://itslinuxfoss.com/install-laravel-ubuntu-22-04-lts/ - https://www.digitalocean.com/community/tutorials/how-to-configure-apache-http-with-mpm-event-and-php-fpm-on-ubuntu-18-04 - phpmyadmin password left blank, so it's random now - https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-phpmyadmin-on-ubuntu-22-04 - skip the whole Step 2 — Adjusting User Authentication and Privileges - `ssh-keygen` because I need a public key

回答網友提問:如果前端要銜接後端的話,是不是學 node.js 比較快?

昨天在我們新手寫程式 LINE 群組,有幾個業界工程師&新手在討論: 如果前端要銜接後端的話,是不是學 node.js 比較快? https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好,我決定單獨寫一篇文章討論這件事情 --- 首先,我很推薦新手前端也去學一點後端,這樣對整體概念會更清楚 這位網友提到的 node.js 很不錯,但是我更推薦去學 php,簡單幾個原因說明如下 # 無框架開發 常見的後端語言,在寫網站時,都需要套件&框架才能開發 - python 需要 django - ruby 需要 rails - java 需要 spring - node 需要 express 我建議你直接寫 php 做好玩的小網站,不要用框架 php 雖然現在都用 laravel 框架,但古早時代大家都寫純 php 如果現在只是自己做個小專案,當然寫純 php 也是夠用的 學框架沒什麼不好,但是,在新手一開始的階段,我更推薦從單純的東西開始學起 一來上手很快,二來等於是紮穩馬步,三來之後學框架可以去思考:如何用純 php 語言寫出框架元件 如果自己想補充後端知識,就試試純 php 吧!先別學 laravel,晚點再去學就好 # 後端先避免非同步程式設計 這件事比較 tricky,javascript 語言本身支援非同步,這在前端 UI 處理很好用 也就是常用的 async/await,`.then().then().then()` 或者到處傳 callback function 那些的 但是!我認為在寫後端的時候,這個語言特色會讓後端開發時,顯得有點囉唆 以後端讀取檔案內容來說,絕大多數情況下,你就是要現在就讀取好檔案、讀取完才讓程式接著繼續跑,才有意義 幾乎不存在「非同步去讀取檔案,不等結果,先直接去處理別的任務」這種情況 於是 node 後端程式碼就需要去傳 callback function 或者 async/await 我認為這有點囉唆,這些情境實在沒必要用「非同步程式設計」處理! node 社群自己也知道,所以除了 `fs.readFile` 之外,還有提供 `fs.readFileSync` 函式 作為一個教育者,我很不喜歡跟新手解釋,為甚麼會有這兩種函式,差異在哪 我認為新手後端,多去學非同步程式設計的觀念與技巧,是徒增挫折 用 python/php/ruby/java 寫後端,都不會遇到這個困擾 新手後端就學好 http 協定,GET 跟 POST 參數是怎麼傳遞的,怎麼使用 session,怎麼連接資料庫就好了 不要多被一個 asynchronous programming 困擾 # 多學一個程式語言 本身是前端工程師,再去學後端想用 node 繼續寫 javascript 當然很合理 不過,長遠來說,多學幾種程式語言,對職業生涯比較健康 首先,你會更有自信一點,並且,能夠開始比較各種程式語言的差異與哲學 很多在 A 語言理所當然的事情,在 B 語言是很罕見的 很多在 A 語言社群大家都說「對」的事情,在 B 語言社群大家都說「錯」 長遠職業生涯來說,你需要至少寫過多種程式語言,才會發現大多數事情都只是「不同社群」的「主觀偏好」 你會發現網路上多數講的斬釘截鐵的對錯觀念,都只是一種偏執。你的觀點會更全面 # 結論 以這位網友的狀況來說,本身是前端,其實,學 nodejs 或 php 都不錯啦 我個人是偏好 php > nodejs 一點,這樣 以上,簡單分享,希望對類似狀況的朋友有幫助!

回應網友提問:我是新手前端,公司叫我學一點 php + laravel 串 API,該從哪邊學起呢?

昨天在我們新手寫程式 LINE 群組,有幾個業界工程師&剛轉職的新手在討論: 我是新手前端,公司叫我學一點 php + laravel 串 API,該從哪邊學起呢? https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好,我決定單獨寫一篇文章討論這件事情 --- 我猜你面臨的情況,老闆不是真的叫你從無到有寫後端,應該是去硬改現成的後端專案 因為是公司馬上需要的,先求速成為主,背後細節就先別管了 就分幾個步驟來做吧 # Step 1 laravel 官網 `Installation` 章節讀一讀,然後看你用什麼作業系統,網路上 laravel 安裝教學找幾份試試看 先想辦法把環境跑起來,讓目前專案可以在電腦上跑 然後找一款有 GUI(圖形化介面)的資料庫管理軟體,在 UI 上點一點,準備好資料庫 # Step 2 `Routing` `Controllers` `Requests` `Responses` 這幾個章節讀一讀 至少稍微看懂,後端是哪些地方在接收參數、回應參數 # Step 3 把 `Eloquent ORM` 章節讀一讀,這個類別提供很多神奇的方法,很輕易就能做到 CRUD 至少稍微看懂,後端是哪些地方在跟資料庫互動,自己有辦法新增資料、更新資料、刪除資料這樣 --- 除此之外,上網找幾份 laravel 的簡易 CRUD 範例教學,不太懂背後原理沒關係,按照指示,做個部落格之類的 然後就去硬改公司現成的後端專案,頂著用,不然短期內也沒辦法真的學精 laravel,就先這樣吧!先能滿足公司需求就好! 其實,以上所說,真的是很混的學習方法:ORM 背後的觀念、資料庫的 SQL 觀念,幾乎都沒學到 長遠來說,如果是真的要學 php + laravel 後端,我都是建議先從「純 php + mysql」開始學起 也就是我鼓勵新手用純 php 寫一個部落格網站,寫純 SQL 去連接資料庫,先搞懂這種最純粹的寫法 然後再開始學 laravel 以及 ORM 等等好用套件工具 不然的話,我知道很多人直接從 laravel 開始寫起,半知半解,工作很久了,卻連哪些功能是 php 提供的,哪些是 laravel 提供的都分不出來 然後在需要換框架 比如 CodeIgniter 或者 Yii 的時候,很多觀念無法融會貫通,長遠來說,根本事半功倍 --- 話說回來,如果老闆不是叫你硬改現成的後端專案,而是叫你從無到有寫後端 那這工作內容實在不太合理,除非你一開始應徵的就是「全端工程師」的職缺&薪資 以上,簡單幾個方向分享,希望對你有點幫助!