## 介紹 編寫乾淨的程式碼是每個軟體開發人員的基本技能。乾淨的程式碼不僅使您的程式碼庫更易於維護和理解，而且還能促進團隊成員之間的協作。在這篇綜合文章中，我們將探討什麼是乾淨的程式碼、為什麼它很重要，並為您提供一組最佳實踐和原則來幫助您編寫乾淨且可維護的程式碼。 - 原文出處：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 提供了程式碼審查、分支和合併工具，促進協作和程式碼整潔。 ##結論 編寫乾淨的程式碼不僅僅是一套規則，更是一種心態和紀律。它是關於建立易於閱讀、維護和擴展的軟體。通過遵循這些最佳實踐和原則，您可以成為一名更熟練的開發人員，生成高質量的程式碼。投入時間仔細檢查其他工程師的程式碼庫，特別是在開源專案中，可能是一種啟發性的體驗。通過這種探索，您將獲得對不同編碼風格和策略的寶貴見解。這種接觸使您能夠提煉出編寫原始、可持續程式碼庫的精髓。請記住，乾淨的程式碼是一個持續的旅程，通過練習，它會成為第二天性，從而實現更高效、更愉快的軟體開發。
發現一篇文章，國外的技術研討會舉辦者，分享了舉辦這類活動的辛苦＆心得 很有意思，翻譯與大家分享一下。 原文出處：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 ）來獲得更完整的知識。在那裡您將獲得更多示例和更多關於此內容的解釋。 希望這篇文章有幫助！ 🦀🦀
老話一句，程式設計領域發展太快速，新進的學習者容易眼花撩亂 為了讓新手清楚脈絡，我認為有必要稍微從歷史脈絡談起 別擔心，老舊的寫法我們就稍微寫過、帶過就好，實務上幾乎都是寫很新的語法 寫完了這份教材，我相信你實務上不論看到哪種語法，都能看懂！ --- 寫完本課內容，我認為實務上你已經可以處理絕大多數的需求了！ 不過，關於非同步程式設計、promise、async/await 還有很多可以學的 消化、研究完本課程之後，請接著前往下一份教材，繼續邁向資深之路吧！ **教材開發中，敬請期待**
## 課程目標 - 認識 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 萬元我是覺得也不錯呀～我還有多餘時間可以接案欸 以上，簡單心得，跟大家分享一下，未來有更多數據＆心得再跟大家分享！
昨天在我們新手寫程式 LINE 群組，有幾個工程師＆想轉職的新手在討論： > 各位前輩們好，小弟是自學轉職的前端工程師，目前有兩個 offer，一個是接案公司；一個是自有產品，自有產品的那間目前只有一個junior前端，進去有問題可能沒人可以問，但看網路上好像都不太推接案公司。猶豫了很久選不出來想聽聽各位前輩的看法。 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情，跟大家分享 --- 阿川幫大家從幾個角度來分析比較一下 # 學習的深度、廣度 接案公司通常是使用類似的技術，接不同的客戶專案 好處是可以接觸很多不同的客戶，認識許多不同產業 壞處是做久了可能會開始有「重複感」，也就是好像一直在做類似的事情，有點學不到東西 產品公司通常是長期深入研發自家產品、技術 所以會在同一領域鑽研，通常可以玩得比較深入、學得比較深入 壞處是可能長期只能使用同一技術、框架，沒機會玩別款的 接案公司有時需要面對不同技術需求的客戶，有機會玩玩不同款的語言、框架、技術 # 工作的時程壓力 接案公司的時程壓力來自於「客戶」，通常已經由老闆、PM 跟對方承諾某個時間，甚至已經寫在合約上 如果同時在開發多個專案的話，有時候工程師會感到相當的壓力 通常是忙一陣、閒一陣這樣 產品公司沒有這樣的壓力，壓力通常來自於「公司沒有在賺錢」 如果公司經營穩定、產品前景看好、主管有肩膀好說話 那像這樣的時程壓力，通常會小很多 # 技術債 稍微資深的工程師，在不同公司面試時，一定會問的問題是：入職之後，需要維護 legacy（老舊）專案嗎？ 維護老舊專案、負擔技術債，是一件很悲慘的事情，也是開發者的主要離職原因之一 你會被迫用已經過時的工具、語法在開發，並且要把設計拙劣的系統架構「硬搬進自己腦子裡」才能消化開發 這過程能學到東西嗎？我認為不多，基本上是在糟蹋生命 接案公司來說，如果主要負責一些新客戶，那麼經常在重啟新專案，技術債問題或許不大 如果手上負責很多「超舊的專案與客戶」，那麼可能會遇到技術債的問題 自有產品的公司，則是走向另一個極端 如果是持續有在更新版本、升級套件的熱情公司，那麼技術債問題不大 如果是有年紀、穩定的系統，那麼版本問題、系統架構的技術債問題，可能很大 嚴重起來會比接案公司更慘，因為就只有一個專案在跑 # 進去有問題可能沒人可以問 大家都希望團隊能有一個又強、人又好、又願意幫忙自己的好同事 不過這可遇不可求，身為正職工程師，你需要能夠獨立解決問題 畢竟人家也面試過了，應該就是合格了，如果真的丟一些無法解決的問題給你，那也不全是你的錯 另一方面，沒人可以問，代表你獨立做決定的空間很大，這未必是壞事 # 結論 剛轉職的新手上班，我是覺得去接案公司上班也可以 通常接案公司很缺人，也比較願意給半路出家者機會 而且開始工作的前 1-2 年，不管去什麼公司，通常都能學到很多東西 待了 2-3 年之後，覺得無聊了，再找新工作也不遲 所以回到原 po 的問題：我認為兩間公司都可以，沒有說接案公司一定比較不好 畢竟，就算是自有產品的公司，如果產品本身超爛，根本永遠不會賺錢、沒人想用 那就只是一大群人在「陪老闆追逐他的個人夢想」，那其實也是相當浪費時間的，不如在接案公司專心滿足客戶，比較充實 --- 我建議閣下不妨從「人和」的角度來觀察一下：你喜歡面試時看到的那些人嗎？ 老闆、主管、同事，你喜歡跟他們相處嗎？還是你有點畏懼他們、覺得他們有點冷漠、城府、可怕？ 如果實在不知怎麼選，就選你喜歡的那群人吧！跟合得來的人一起工作，總是不會太不舒服！ 以上，簡單分享，給各位參考！也歡迎大家多多在留言區補充經驗、意見！
業界很多關於非同步的教材，會從 async/await 語法開始教起 雖然這是最新、也是目前最流行的語法，但我認為對於新手來說，非常難吸收 要教 async/await 必須先談 promise 的基本 `.then()` 語法 然而，要談 promise，我認為再退一步，從 calback hell 開始學起，更好 所以我設計了這份教材，從歷史脈絡開始談起，讓你實務上不論看到哪種語法，都能看懂！ --- 關於非同步程式設計、promise、async/await 還有很多可以學的 本課程只是稍微幫您突破盲點，您現在應該有更好的基礎，可以廣泛探索相關概念了！ 消化、研究完本課程之後，請接著前往下一份教材，繼續邁向資深之路吧！ https://codelove.tw/@howtomakeaturn/course/d3obxP
阿川收到網友提問如下： > 您可以分享您的軟體工程師職崖規劃嗎?再次感謝 我個人的職涯規劃其實比較偏激，是同時做「上班＆接案＆創業」這三件事 我簡單說明一下爲什麼我會這樣做，給大家參考 --- 我是 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 就是我做來給工程師們互相交流的地方！ 以上簡單分享，希望對你有幫助～！
阿川收到網友提問如下： > 阿川您好 我是一位工業設計師，最近想轉職前端工程師，但年齡已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 功能了，持續觀察幾天看看！
現在幾乎所有軟體專案都會使用 git 進行管理 不過，對新手來說，git 的設定與指令需要學習一段時間，有點太難 所以很多人會先用 Github Desktop 來管理專案，其實暫時也夠用 不過，很多 git 的進階指令與強大功能，只用 Github Desktop 是做不到的 剛開始工作，懶得學 git，就先用 Github Desktop 沒關係 但是長遠來說，我還是鼓勵大家找時間去把 git 學好，在程式碼管理比較複雜的情境，才有辦法自己動手解決 --- 找時間休息、整理、消化一下目前的內容，感受一下 Github Desktop 的強大與魅力吧！ 這些好用的功能，以個人開發專案來說，已經足以應付絕大多數情境 不過，在實務上，以團隊開發來說，只會這些功能是不夠的 還需要有 branch 的觀念，以及 branch 管理的技巧，才能團隊合作 這些會在後續的課程提到！ **新教材研發中，敬請期待！**
在我們新手寫程式 LINE 群組，有幾個業界工程師＆想要轉職的新手在討論： 非本科轉職，到底要學什麼語言？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這個問題在群組中，重複出現快十次了！ 我決定設計一個量化指數，給大家參考，一次回答這個「大哉問」！ --- # CodeLove 程式語言新手友善指數 - 簡介 我設計的這個指數，我命名為「CodeLove 程式語言新手友善指數」 因為每次有人問我，我都是請對方報名補習班之前，先打開人力銀行，親眼看一下那些職缺＆產業是否喜歡！ 如果歡迎新手的職缺很少，那這個語言不管多強大、多好學，在台灣都不能算是適合新手！畢竟大家轉職就是想儘快找到工作！ 指數公式是這樣： - 打開 104 人力銀行，搜尋「某某程式語言」、只搜尋職務名稱、經歷要求1年以下，得到歡迎新手的職缺數 X - 打開 1111 人力銀行，搜尋「某某程式語言」、僅搜尋職缺名稱、工作經驗選無經驗，得到歡迎新手的職缺數 Y - 把 X + Y = 最終結果 這個最終數字，大概就是你今天去找工作，市場上歡迎你這種非本科、無經驗的職缺數量！ 不論你是補習班畢業或者自學結束，請參考這些數字：願意給你機會的職缺大概是這麼多！ --- # CodeLove 程式語言新手友善指數 - 2023年8月份排行榜 - `#1` Java (267) - `#2` C# (241) - `#3` PHP (167) - `#4` Python (87) - `#5` Golang (32) - `#6` Ruby (3) - `#7` Rust (2) # 結論 非本科轉職，到底要選什麼程式語言？ 你當然要綜合考量： - 有沒有喜歡的補習班開課 - 程式語言本身的學習難度 - 身邊熟識的工程師是專精哪個 - 相關的免費、付費線上自學資源多寡 我知道，上面這個指數，公式過度簡化，但至少有個參考數字！ 我有留意到，有些人，因為煩惱這個問題，重複研究了很久，遲遲做不了決定，很害怕選錯 實務上，有些職缺會貼在 FB 社團、或其他人力資源網站、有些職缺沒把語言寫在「職務名稱」上，所以真正的職缺其實更多！ 我個人認為，1 ~ 4 光看數字就知道還不錯！有心動的課程就去報名吧，別一直胡思亂想嚇自己！ 5 你就再多多評估、研究一下！應該也還行！ 6 7 這種數字，我只是想說明，如果你有認識的工程師，推薦你非本科去學 Ruby 或 Rust，那你可能要同時請他推薦職缺了！因為幾乎沒有願意給你機會的職缺！ 以上，簡單分享，希望對你有幫助！ 可以留言：你想看的程式語言，我找時間做一份更新、涵蓋更多語言的！
## 前情提要 本文跟六角學院沒有任何關係ＸＤ ## 文章開始 今天要討論自學，關於線上課程，我認為買一些課是好的，但別傻傻看了促銷就買。 誰跟你說學程式一定要花錢？ 告訴我，誰跟你講的？就是賣你課的人啊傻子。 . . . 我今天這篇文章要教你怎麼免錢學程式，而且是有系統的學，不是自己在那邊維基百科或谷歌一百年那種。 答案是：爬文。 . . 好啦我知道你們這些伸手牌就是懶得爬文所以才會想要花錢了事，今天我爬完了。 ## 好料放送(一) 把免費資源直接丟給你吧。 [「Python 網路爬蟲與資料分析入門實戰」範例程式碼](https://github.com/jwlin/py-scraping-analysis-book)  裡面包含 ``` 網頁爬蟲範例實戰 3-1 PTT 八卦板今日熱門文章 3-2 Yahoo 奇摩電影本週新片 3-3 兩大報當日焦點新聞 3-4 Google 搜尋股價資訊 3-5 Dcard 今日熱門文章 ``` 所有書本裡面的程式碼作者都直接公開了，我也不知道為什麼，反正就是免費給你。 現在你也不用自己google研究，直接複製丟到GPT那邊寫一個教學文章給你， 你就等於能夠免費讀到這本書。而且不用手打程式，你最愛的那種。 ## 好料放送(二)  [hahow 線上課程: Python 網頁爬蟲入門實戰](https://github.com/jwlin/web-crawler-tutorial/tree/master) . 同一個作者丟出來的，總之既然人家想放github那就看啊！ 用法也是一樣，人家有個lecture可以看看課綱與大致上的說明自己去配上GPT以及谷歌， 然後不需要自己打扣，直接有現成範例可以拿去跑看看，年代問題導致的錯誤還可以當作功課自己改。 . . . ## 總結 還在靠北沒資源或是一直問要怎麼自學？現在告訴你了， 這樣的教材原本他起碼都賣幾千塊，你可以免費學幹嘛不學？ 別問我怎麼知道的，我也是爬文爬到的，只是我人很好分享給你們知道而已。 . . 謝謝，別那麼感動。 . . 我也只是一個很愛免費白嫖的爬文仔而已。
簡單複習一下，在這次的課程中，我們學會了 - 用 express 處理 http get 請求 - 用 express 處理 http post 請求 - 用 express 提供靜態檔案 - 取得 url 參數 - 取得表單參數 是不是很有趣呢？ --- 再次說明，這次的課程主要是學習網頁協定＆基本觀念，實務上後端開發有很多東西要學 舉例來說，下面這些東西本課程都省略了： - ejs 模板的 layout 功能 - 連接資料庫軟體 - 會員系統、註冊登入、驗證功能 雖然省略了很多東西，但我認為已經能讓你對於 http 協定與後端開發，有大致的了解 因此基本功比一般的前端開發者更好！這也是本課的目的所在！ 很多前端工程師，工作了好一陣子，卻還是搞不清某些觀念、任務屬於前端還是後端！要避免這種混淆，職業發展才能順利又有效率！ 後面的課程，我會進一步教你清楚認識前端、後端的區別、以及釐清一些常見迷思！讓你在前端之路上，走得更順遂！ --- 消化、研究完本課程之後，關於 JavaScript 更多必學的基本觀念 請接著前往「自學網頁の嬰兒教材：JavaScript（十二）」開始學習吧！ **教材研發中，敬請期待**
## 課程目標 - 使用 ejs 模板並讀取變數 ## 課程內容 這一課來學習如何讀取變數之後，放進 ejs 模板呈現！ 先來安裝之前用過的 readline-sync 套件 ``` npm install readline-sync ``` 替這課建立一個資料夾，然後建立 `index.js` `hello.ejs` `users.json` 這幾個檔案 此時資料夾會長類似這樣 ``` repo ├── package.json ├── package-lock.json ├── node_modules ├── lesson1 │ └── index.js ├── lesson2 │ ├── hello.ejs │ └── index.js └── lesson3 ├── users.json ├── hello.ejs └── index.js ``` 在 users.json 放入以下內容 ``` [ { "name": "小明", }, { "name": "小華", }, { "name": "小王", } ] ``` 在 hello.ejs 放入以下內容 ``` <div> <% for(var i = 0; i < users.length; i++) { %> <p> <%= users[i].name %>同學，你好！ </p> <% } %> </div> ``` 在 index.js 放入以下內容 ``` const express = require('express'); const app = express(); const engine = require('ejs-locals'); const fs = require('fs'); app.engine('ejs', engine); app.set('views', './lesson3'); app.set('view engine', 'ejs'); app.get('/', function(req, res){ const data = fs.readFileSync('./lesson3/users.json'); const users = JSON.parse(data); res.render('hello', { users: users }); }); app.listen(3000); ``` 然後去終端機輸入 ``` node lesson3/index.js ``` 接著打開瀏覽器，在網址輸入 ``` http://localhost:3000/ ``` 你會看到很多則訊息，分別跟多位同學打招呼！ --- 這段程式不用我多加說明了吧！檔案讀取也是之前教過的內容！ 這邊唯一多學的東西，就是 ejs 關於 for 迴圈的語法，反正就是 `<%` 跟 `%>` 之類的東西包起來而已 ejs 還有支援很多豐富的語法＆功能，有興趣的話，自行研究一下吧！ ## 課後作業 這次要練習匯入資料到 ejs 模板 請新建立 hw3 資料夾，採用以下結構 ``` /repo /hw3 /index.js /homepage.ejs /posts.json ``` 請修改 homepage.ejs 內容，將文章內容移出來，放在 posts.json 裡面 ``` [ { "title": "第一篇日記", "content": "今天天氣很好，夏天太陽很大，讓我心情很好" }, { "title": "第二篇日記", "content": "早起出門運動，回家沖個澡，整天心情很好" }, { "title": "第三篇日記", "content": "下大雨一整天，整天在家追劇，滿舒服的" } ] ``` 這樣 homepage.ejs 內就不會只是 html 了，你會練習到 ejs 獨有的模板語法！ 完成以上任務，你就完成這次的課程目標了！ --- 請更新你的 github 專案內容，此時應該變成這樣 ``` /repo /hw1 /index.js /hw2 /index.js /homepage.ejs /hw3 /index.js /homepage.ejs /posts.json ``` 依此類推，之後就這樣交作業！
## 課程目標 - 使用 node 與 express 回應 http get request ## 課程內容 在 node 中開發後端程式，通常會使用一款叫做 express 的套件 雖然不用 express 也能夠開發後端應用，但 express 提供很多現成好用功能 所以先來安裝 express 吧！ ``` npm install express ``` 建立一個資料夾，放我們每課的練習內容，這一課就叫 lesson1 吧 然後建立一個 index.js 檔案 此時資料夾會長類似這樣 ``` repo ├── package.json ├── package-lock.json ├── node_modules └── lesson1 └── index.js ``` 在 index.js 檔案放入以下內容 ``` const express = require('express'); const app = express(); app.get('/', function(req, res){ res.send('<h1>恭喜您，成功囉！</h1>'); }); app.listen(3000); ``` 然後去終端機輸入 ``` node lesson1/index.js ``` 接著打開瀏覽器，在網址輸入 ``` http://localhost:3000/ ``` 你會看到一段大大的打招呼訊息！ --- 讓我們逐行說明一下 前面兩句是載入 express 套件，然後建立主程式物件 `app.get()` 是註冊登記一個處理 `HTTP GET 請求` 第一個參數是 `要處理的網址` 第二個參數是放進一段「函式定義」代表要如何處理 函式定義通常會用 `(req, res)` 當參數，有人會寫 `(request, response)`，都可以，分別是代表 `請求` 與` 回應` 的物件 這段看不太懂沒關係，需要稍微研究一下「HTTP 協定」才會知道定義 反正就先用 `res.send` 來回應一段 html 就對了！ 最後用 `app.listen(3000);` 來在 port 3000 跑這段後端程式 --- 在一台電腦上，多個程式之間彼此溝通，通常會在電腦上各自使用一個 port 號碼 在瀏覽器中，通常只會輸入網址，例如 `https://www.google.com.tw` 之類的 只輸入網址，代表使用 443 當作 port，舉例來說，你可以在網址輸入 `https://www.google.com.tw:443` 看看，結果一模一樣 一個 port 只能同時給一個程式使用，為了避免用到別的程式在用的 port，我們請 node 在這邊使用 3000 這個冷門的 port，方便我們測試 然後 `localhost` 不是真的網址，是請瀏覽器直接在本機電腦上尋找網站開啟的意思！ 以上通通看不懂沒關係，需要對 `網際網路協定` 稍微研讀才比較懂，先照做即可！ ## 課後作業 這次的系列作業，要練習開發一個「個人日記 APP」 首先來練習如何用 node 回應 http get request 請開發一個 app，打開首頁 `http://localhost:3000/` 會顯示 `<h1>我的個人日記 APP</h1>`，先做到這樣就好 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 請建立一個 repo 上傳到 github 這個 repo 的檔案結構應該會是這樣： ``` repo ├── package.json ├── package-lock.json ├── node_modules └── hw1 └── index.js ``` 接下來的每次作業，都新開一個小資料夾 然後把 github 專案連結，貼到留言區即可
這兩家服務好像不錯 https://vercel.com/ https://render.com/ 基本上研究服務，首先點進「Pricing」頁面看看收費，有沒有免費方案，就對了 這兩款，好像點幾下按鈕，就可以從 github 直接把專案部署了，還不錯呀
上次的（十）是純 CLI 應用 先幫大家脫離 ` js 一定是網頁、一定是 html/css 相關` 的刻板印象 接著再回來碰 backend programming 開發，銜接回來 web 領域 這樣才順暢，才不會一直搞混在一起 教材研發中，近期上線，敬請期待～
收到網友提問如下： ``` 這是最近跟一個朋友聊天聊到的 朋友是寫 .net Framework 的 我剛碰Vue的時候，跟他說我看不懂Vue在背後是怎麼運作的、為什麼這樣寫會變成這樣的結果？ 他跟我說，不用去在意框架背後幫你做了哪些事情 反正就是做那些制式的動作，把功能實現就好 不然工程師哪有那麼多腦力去記住程式底層都做了什麼 這樣真的是好的嗎？ 工程師的等級差距並不在於是否知其所以而不知其所以然嗎？ ``` 這應該是每個年輕工程師都有的疑問，寫一篇完整、公開回答跟大家分享，給類似狀況的人參考。 我先講結論：這取決於你想不想越變越強、不斷提升競爭力，還是只想混口飯吃 如果只想混口飯吃，什麼工具都是學個用法，懶得研究，然後東西做出來交差了事，那可以永遠不去管工具背後原理 不過，這種心態，職涯成長、薪水成長空間會很有限，然後在 40 多歲的時候會有「中年危機」，會很慘、壓力很大 因為屆時新工具你跟年輕人一樣不太會用，舊有的經驗又幫不上忙，因為你從來不肯學背後通用的觀念 回到問題本身，我認為有兩件事情值得分享，有兩個觀點你需要去權衡，我們先談談「抽象」 # Abstraction 抽象 軟體工程師的主要工作就是「抽象化」，把各種邏輯分不同層次「封裝為抽象」 這樣才有重用性，別人才能基於你的成果，進一步開發更豐富的東西 網路的七層架構，各種協定，程式語言，語言上面的工具、套件、框架，都是抽象 # The Law of Leaky Abstractions，抽象滲漏法則：除非無關緊要，否則所有抽象都或多或少會滲漏 這是在軟體圈知名的一個理論，稍微資深的開發者都應該要知道這篇文章 https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ 我簡單說明一下，抽象滲漏法則就是在說：所有抽象都一定會在某些情境下失效，此時便是滲漏。 你只要工作時間夠久就會知道，長遠來說，你還是要花時間去研究它抽象背後的東西。 你本以為只是前端隨便寫一寫交差，卻發現有一天需要認真去看 HTTP 協定、CORS 在講什麼，否則無法處理資安問題 你本以為只是後端 CRUD 隨便寫一寫交差，卻發現有一天需要認真去看 database 索引機制、記憶體管理，否則無法處理效能問題 結論：「抽象」幫助我們省下一些工作的時間，但關於技術細節的學習時間，無法省下來。 # 你的生產力要對公司商業產值有幫助 我認為工程師常常在另一個方面犯錯，就是鑽研自己喜歡的細節，不去管對於公司的商業產值與個人生產力 我曾遇過公司要求協助更換一張網頁圖片，某工程師居然兩個星期還沒更換完成 問他原因，原來是他看圖片尺寸不順眼，在研究分割、壓縮、整個網頁的整合機制，以及相關工具的導入 問題是，那個網頁跟圖片並不重要，此時專案還沒進到效能優化的階段，此功能應該盡快上線，視情況決定下一步 這完全是沒搞清楚優先順序，只顧著研究自己爽的東西，也沒跟相關人士確認任務目標 # 結論 回到原 po 的描述 ``` 不然工程師哪有那麼多腦力去記住程式底層都做了什麼 ``` 這是大錯特錯，隨便找一個優秀的資深工程師，從 Vue 到 React 到各種工具，背後原理、相關機制，都能深入淺出跟你說明 什麼 shadow DOM / virtual DOM / pure function / fiber tree / proxy / immutable 等等，就算好幾個月不碰工具，還是能輕鬆解釋，根本不是死記硬背的，這全都是經驗＆融會貫通的結果 但是過猶不及，不顧公司需求，自顧自地研究技術細節也不好 該花多少時間研究背後機制？這是一個需要權衡的問題 請從公司需求的角度，以及個人長期職涯的角度，視情況判斷 以上，簡單分享
你的轉職路上，還缺少一份練功作業包！寫完這九包，直接拿作品去面試上班！
本學院另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
