https://html5drummachine.com/virtual-drum-machine/ 看了很多前端的練習作品 老實說 真的都挺無聊的.... 對我來說這種網站才酷啊!!!!!!!!! 話是這樣說 但基本功還是要慢慢練 不過我打算做這種網站 先蒐集這些厲害的網頁 未來可以分析他的元素 只不過要搞這種 圖片部分好像會先是第一道難點.... 我已經有分析網頁的一些要點 有些是靠提供素材 例如netflix 某盜版網 好讀 這種 網站的價值來自裡面的sourse 並不一定是什麼創意的點子 前端後端服務等等 有些則是靠功能 例如某某遊戲計算機 實現訂便當 todolist 線上鬧鐘 身分證檢驗&產生等等 當然論壇也包含於此類 這就是要有點技術 這應該算是滿深的思考 相信未來深入的話 面試作品集應該能更有東西 不知道其他的朋友或版主們 有沒有遇見過什麼酷網站 喜歡哪一部分的效果等？ 可以來討論 未來我也會加入我的構造網站筆記～
框架背後有什麼必學觀念的？這篇文章簡單整理如下 原文出處：https://dev.to/lexlohr/concepts-behind-modern-frameworks-4m1g --- 很多初學者會問“我應該學哪個框架？”和“學一個框架之前需要學多少JS或TS？” - 無數自以為是的文章都在宣傳作者首選框架或庫的優勢，而不是向讀者展示其背後的概念、教他們如何做出明智的決定。讓我們先解決第二個問題： ## “在學習框架之前要學多少 JS/TS？” 盡可能多地理解它們的基本概念。您將需要了解基本資料類型、函數、基本運算符和文檔對像模型 (DOM)，這是 HTML 和 CSS 在 JS 中的基礎。雖然先學一點當然沒關係，但沒必要先精通框架或庫。 如果您是一個完全的初學者，[JS for cats](http://jsforcats.com/) 可能是您第一步的好資源。繼續前進，直到您感到自信為止，然後繼續前進，直到您開始感到自信不足。那就是你了解足夠的 JS/TS 並可以開始學框架的時間。其餘的你可以邊走邊學。 ## “你指的是什麼概念？” - 狀態 - 效果 - 記憶化 - 模板和渲染 所有現代框架都從這些概念中衍伸出它們的功能。 ### 狀態 狀態只是讓您的應用程式跑起來的資料。它可能在全局級別上，適用於應用程式的較大部分，或適用於單個元件。讓我們以一個簡單的計數器為例。它保留的計數是狀態。我們可以讀取狀態並寫入狀態以增加計數。 最簡單的表示通常是一個變數，其中包含我們的狀態所包含的資料： ``` let count = 0; const increment = () => { count++; }; const button = document.createElement('button'); button.textContent = count; button.addEventListener('click', increment); document.body.appendChild(button); ``` 但是這段程式碼有一個問題：對 count 的更改，就像對 increment 所做的更改一樣，不會更新按鈕的文本內容。我們可以手動更新所有內容，但這對於更複雜的用例來說並不能很好地擴展。 `count` 更新其用戶的能力稱為*反應性*。這是通過訂閱並重新執行應用程式的訂閱部分來更新的。 幾乎每個現代前端框架和庫都有一種響應式管理狀態的方法。解決方案分為三部分，至少採用其中之一或混合使用： - Observables / Signals - Reconciliation of immutable updates - Transpilation #### Observables / Signals Observables 基本上是允許藉由訂閱閱讀器的函數來進行讀取的結構。然後訂閱者在更新時重新執行： ``` const state = (initialValue) => ({ _value: initialValue, get: function() { /* subscribe */; return this._value; }, set: function(value) { this._value = value; /* re-run subscribers */; } }); ``` 這個概念的第一個用途之一是在 [knockout](https://knockoutjs.com/) 中，它使用相同的函數，帶和不帶參數進行寫/讀存取。 這種模式目前正在以「信號」的形式復興，例如在 [Solid.js](https://www.solidjs.com/docs/latest/api#createsignal) 和 [preact signals](https://preactjs.com /guide/v10/signals/)，但在 [Vue](https://vuejs.org/) 和 [Svelte](https://svelte.dev/) 的底層使用了相同的模式。 [RxJS](https://rxjs.dev/) 為 [Angular](https://angular.io/) 的反應層提供動力，是這一原則的延伸，超越了簡單狀態，但有人可能會爭辯說它模擬複雜性的能力可能反而綁手綁腳。 [Solid.js](https://www.solidjs.com/) 還以儲存（可以通過 setter 操作的物件）和可變（可以像平常一樣使用的物件）的形式進一步抽象這些信號 JS 物件或 [Vue](https://vuejs.org/) 中的狀態來處理巢狀狀態物件。 #### Reconciliation of immutable states 不變性意味著如果一個物件的屬性發生變化，整個物件引用必須改變，所以簡單的引用比較可以很容易地檢測到是否有變化，這就是協調器所做的。 ``` const state1 = { todos: [{ text: 'understand immutability', complete: false }], currentText: '' }; // updating the current text: const state2 = { todos: state1.todos, currentText: 'understand reconciliation' }; // adding a to-do: const state3 = { todos: [ state.todos[0], { text: 'understand reconciliation', complete: true } ], currentText: '' }; // this breaks immutability: state3.currentText = 'I am not immutable!'; ``` 如您所見，未更改專案的引用被重新使用。如果協調器檢測到不同的物件引用，它會再次使用狀態（props, memos, effects, context）來重跑所有元件。由於讀取存取是被動的，這需要手動指定對反應值的依賴性。 顯然，您不是以這種方式定義狀態。您可以從現有屬性建置它，也可以使用所謂的 reducer。reducer 是一個函數，它接受一個狀態並返回另一個狀態。 [react](https://reactjs.org/) 和 [preact](https://preactjs.com/) 使用此模式。它適合與 vDOM 一起使用，我們將在稍後描述模板時探討它。 並非每個框架都使用其 vDOM 來使狀態完全響應。 例如 [Mithril.JS](https://mithril.js.org/components.html#state)，元件會在設置的事件後變化後更新狀態；否則你必須手動觸發 `m.redraw()`。 #### Transpilation Transpilation 是一個建置步驟，它重寫我們的程式碼以使其在舊瀏覽器上執行或賦予它額外的能力；在這種情況下，該技術用於將簡單變數更改為反應系統的一部分。 [Svelte](https://svelte.dev/) 基於一個轉譯器，該轉譯器還通過看似簡單的變數宣告和存取為其反應式系統提供動力。 順便說一句，[Solid.js](https://solidjs.com) 使用轉譯，但不是針對它的狀態，只是針對模板。 ### 效果 在大多數情況下，我們需要對反應狀態做更多的事情，而不是從中衍伸並渲染到 DOM 中。我們必須管理副作用，這些都是由於視圖更新之外的狀態更改而發生的所有事情（儘管 [Solid.js](https://solidjs.com) 等一些框架也將視圖更改視為效果）。 還記得第一個例子中，訂閱處理被故意遺漏的狀態嗎？讓我們完成這個處理效果，來作為對更新的反應： ``` const context = []; const state = (initialValue) => ({ _subscribers: new Set(), _value: initialValue, get: function() { const current = context.at(-1); if (current) { this._subscribers.add(current); } return this._value; }, set: function(value) { if (this._value === value) { return; } this._value = value; this._subscribers.forEach(sub => sub()); } }); const effect = (fn) => { const execute = () => { context.push(execute); try { fn(); } finally { context.pop(); } }; execute(); }; ``` 這基本上是 [preact signals](https://preactjs.com/guide/v10/signals/) 或 [Solid.js](https://solidjs.com) 中反應狀態的簡化，沒有錯誤處理和狀態突變模式（使用接收前一個值並返回下一個值的函數），但這很容易加入。 它允許我們使前面的範例具有反應性： ``` const count = state(0); const increment = () => count.set(count.get() + 1); const button = document.createElement('button'); effect(() => { button.textContent = count.get(); }); button.addEventListener('click', increment); document.body.appendChild(button); ``` > ☝ 使用您的開發人員工具在 [空白頁面](about:blank) 中嘗試上述兩個程式碼塊。 在大多數情況下，框架允許不同的時間安排，讓效果在渲染 DOM 之前、期間或之後執行。 ### 記憶化 Memoization 意味著緩存從狀態計算的值，它會從狀態衍伸的變化更新時更新。它基本上是一種回傳衍伸狀態的效果。 在重新執行元件功能的框架中，例如 [react](https://reactjs.org/) 和 [preact](https://preactjs.com/)，這讓某些複雜計算不需要每次都重複計算。 對於其他框架，情況恰恰相反：它允許您選擇部分組件進行響應式更新，同時緩存之前的計算。 對於我們簡單的反應式系統，memo 看起來像這樣： ``` const memo = (fn) => { let memoized; effect(() => { if (memoized) { memoized.set(fn()); } else { memoized = state(fn()); } }); return memoized.get; }; ``` ### 模板化和渲染 現在我們有了純的、衍伸的和緩存形式的狀態，我們想把它展示給用戶。在我們的範例中，我們直接使用 DOM 來加入按鈕並更新其文本內容。 為了對開發人員更加友好，幾乎所有現代框架都支持一些特定領域的語言來編寫類似於程式碼中所需輸出的內容。儘管有不同的風格，比如 `.jsx`、`.vue` 或 `.svelte` 文件，但它們都歸結為用類似於 HTML 的程式碼表示 DOM，因此基本上 ``` <div>Hello, World</div> // in your JS // becomes in your HTML: <div>Hello, World</div> ``` 你可能會問“我要把狀態放在哪裡？”。很好的問題。在大多數情況下，`{}` 用於表示屬性和節點周圍的動態內容。 最常用的 JS 模板語言擴展無疑是 JSX。對於 [react](https://reactjs.org)，它被編譯為純 JavaScript，其方式允許它建立 DOM 的虛擬表示，一種稱為虛擬文檔對像模型或簡稱 vDOM 的內部視圖狀態。 這樣設計的原因是：建立物件比存取 DOM 快得多，所以如果你能用當前的替換後者，你可以節省時間。但是，如果您在任何情況下都有大量 DOM 更改或建立無數物件而沒有更改，則此解決方案的優點就變成必須通過「記憶化」來規避的缺點。 ``` // original code <div>Hello, {name}</div> // transpiled to js createElement("div", null, "Hello, ", name); // executed js { "$$typeof": Symbol(react.element), "type": "div", "key": null, "ref": null, "props": { "children": "Hello, World" }, "_owner": null } // rendered vdom /* HTMLDivElement */<div>Hello, World</div> ``` 不過，JSX 不僅限於 react。例如，Solid 使用其轉譯器更徹底地更改程式碼： ``` // 1. original code <div>Hello, {name()}</div> // 2. transpiled to js const _tmpl$ = /*#__PURE__*/_$template(`<div>Hello, </div>`, 2); (() => { const _el$ = _tmpl$.cloneNode(true), _el$2 = _el$.firstChild; _$insert(_el$, name, null); return _el$; })(); // 3. executed js code /* HTMLDivElement */<div>Hello, World</div> ``` 雖然轉譯後的程式碼乍看可能令人望而生畏，但解釋這裡發生的事情卻相當簡單。首先，建立包含所有靜態部分的模板，然後複製它以建立其內容的新實體，並加入動態部分並連接以根據狀態更改進行更新。 Svelte 走得更遠，不僅可以轉換模板，還可以轉換狀態。 ``` // 1. original code <script> let name = 'World'; setTimeout(() => { name = 'you'; }, 1000); </script> <div>Hello, {name}</div> // 2. transpiled to js /* generated by Svelte v3.55.0 */ import { SvelteComponent, append, detach, element, init, insert, noop, safe_not_equal, set_data, text } from "svelte/internal"; function create_fragment(ctx) { let div; let t0; let t1; return { c() { div = element("div"); t0 = text("Hello, "); t1 = text(/*name*/ ctx[0]); }, m(target, anchor) { insert(target, div, anchor); append(div, t0); append(div, t1); }, p(ctx, [dirty]) { if (dirty & /*name*/ 1) set_data(t1, /*name*/ ctx[0]); }, i: noop, o: noop, d(detaching) { if (detaching) detach(div); } }; } function instance($$self, $$props, $$invalidate) { let name = 'World'; setTimeout( () => { $$invalidate(0, name = 'you'); }, 1000 ); return [name]; } class Component extends SvelteComponent { constructor(options) { super(); init(this, options, instance, create_fragment, safe_not_equal, {}); } } export default Component; // 3. executed JS code /* HTMLDivElement */<div>Hello, World</div> ``` 也有例外。例如，在 [Mithril.js](https://mithril.js.org/) 中，雖然可以使用 JSX，但我們鼓勵您編寫 JS： ``` // 1. original JS code const Hello = { name: 'World', oninit: () => setTimeout(() => { Hello.name = 'you'; m.redraw(); }, 1000), view: () => m('div', 'Hello, ' + Hello.name + '!') }; // 2. executed JS code /* HTMLDivElement */<div>Hello, World</div> ``` 雖然大多數人會發現開發人員缺乏經驗，但其他人更喜歡完全控制他們的程式碼。根據他們主要想解決的問題，缺少轉譯步驟甚至可能是有益的。 儘管很少有人這樣推薦，許多其他框架都允許在不進行轉譯的情況下使用。 ## “我現在應該學習什麼框架或庫？” 我有一些好訊息和一些壞訊息要告訴你。 壞訊息是：沒有萬靈丹。沒有哪個框架在每個方面都比其他框架好得多。他們每個人都有自己的優勢和妥協。 [React](https://reactjs.org/) 有它的鉤子規則，[Angular](https://angular.io/) 缺乏簡單的信號，[Vue](https://vuejs.org/)缺乏向後兼容性，[Svelte](https://svelte.dev/) 不能很好地擴展，[Solid.js](https://www.solidjs.com/) 禁止解構，[Mithril.js]( https://mithril.js.org/) 並不是真正的反應式，僅舉幾例。 好訊息是：沒有錯誤的選擇——至少，除非專案的要求真的很有限，無論是在 bundle 大小還是性能方面。每個框架都會完成它的工作。有些人可能需要配合團隊的設計決策，這可能會使您的速度變慢，但無論如何您都應該能夠獲得可行的結果。 話雖這麼說，沒有框架也可能是一個可行的選擇。許多專案都被過度使用 JavaScript 破壞了。其實帶有一些互動性的靜態頁面就可以完成這項工作。 現在您已經了解了這些框架和庫應用的概念，請選擇最適合您當前任務的概念。不要害怕在下一個專案中切換框架。沒有必要學習所有這些。 如果你嘗試一個新的框架，我發現最有幫助的事情之一就是跟它的社群有所連結，無論是在社群媒體、discord、github 還是其他地方。他們可以告訴您哪些方法適合他們的框架，這將幫助您更快地獲得更好的解決方案。 ## “拜託，你*總是*有個人喜好吧！” 如果你的主要目標是就業，我建議學習 [react](https://reactjs.org/)。如果您想要輕鬆的性能和控制體驗，請嘗試 [Solid.js](https://solidjs.com)；你可能會在 Solid 的 [Discord](https://discord.com/invite/solidjs) 上見到我。 但請記住，所有其他選擇都同樣有效。你不應該因為我這麼說就選擇一個框架，而應該使用最適合你的框架。
軟體工程師寫部落格，對於職業生涯很有幫助，有很多好處。這篇文章的作者簡單分享心得。 原文出處：https://dev.to/nasirovelchin/every-software-developer-should-write-a-blog-4622 --- 作為一名軟體工程師，我常常打算明天、下週甚至下個月，就要開始寫部落格。但幾年過去了，我還沒有寫過一篇文章。我沒有開始的原因是，我覺得，我不是專家、不是名人、也不擅長寫作，只是一個普通的軟體工程師。因此，為什麼我要花時間寫一篇文章，根本沒有人會讀。這總是阻止我開始寫。但最近，在我閱讀了幾篇軟體工程師的文章後，我改變了主意，決定開始寫。 有很多理由開始寫文章，而且，我認為每個軟體開發人員都應該擁有部落格。理由大致如下： **更快地學習並提高您的技術技能** 當我試圖解釋或教別人時，我自己也學得更快。我從大學的電腦科學課的小組作業專案中了解到這一點。我仍然記得我試圖向其他小組成員解釋和展示的一切。解釋會促使你更多地了解這個主題，這不僅對你的讀者有好處，對你自己也有好處。開設技術部落格與教學非常相似，因為在您的部落格中，您將向世界教授寫程式和電腦科學。 **推銷自己並開始你的職業生涯** 您的部落格將為您可能無法找到的各種網絡和商業機會打開大門。通過部落格，您可以得到很多機會成為自由工作者和接案者。舉個真實的例子，我的一個朋友，他開始學習 Java 程式語言，並在他的部落格上分享他的進度，有招聘人員向他發送了他從未申請過的工作機會，他們發現他在網上分享的文章。而且，他甚至在完成 Java 課程之前就開始了他的軟體工程師生涯。 **記錄您的回饋進度** 您每周有多少次找到完美的 StackOverflow 文章來解決您的問題並節省您數小時的頭撞牆？有多少次您花費數小時解決問題，但沒有其他人從您的解決方案中獲益？ 即使你不時地、每週寫一篇文章，你也可以展示你面臨什麼樣的挑戰，你是如何解決它們的，你使用了哪些方法和技術，你避免了哪些。一年後，當您回顧時，您會發現您的文件對別人幫助很大，這些有用的見解，以及解決問題的方法，都很有幫助。 此外，與經驗豐富的軟體工程師相比，寫程式經驗很少的人可以更好地展示他們如何在某些主題上掙扎，陷阱和不明顯的部分在哪裡。因此，閱讀您貼文的人不會陷入您所寫內容的陷阱。 **學習如何交流和表達你的想法** 信不信由你，但您的軟體職業生涯在很大程度上取決於您溝通和表達想法的能力。即使你是一個優秀的軟體工程師，如果沒有良好的溝通和展示自己的能力，你的軟體生涯也不會大放異彩，而且會受到限制。此外，許多軟體工程師都說寫文章也能幫助他們寫出更好的程式碼。 **消除你的壓力** 脫離日常的寫程式生活，給自己一些自由，隨心所欲地寫一些你想分享的東西，分享你自己的觀點，寫下來並發表。這些都會讓你感到放鬆。 總的來說，作為軟體開發人員，寫部落格是提升個人風格的絕佳方式。寫部落格可以促進您所做或計劃做的任何事情。它打開了您意想不到的大門。值得一試，看看會發生什麼好事吧。
## 課程目標 認識並且能使用 vanilla-lazyload 套件 ## 課程內容 這次的套件是 https://github.com/verlok/vanilla-lazyload 文件與 demo 在 https://www.andreaverlicchi.eu/vanilla-lazyload/ 當畫面上圖片很多的時候，頁面載入會很慢 lazy load 是所謂的延遲載入技術 也就是不會在一開始就通通載入，而是使用者在網頁上下滑動的時候，圖片元素出現在畫面中的時候，才動態去載入圖片 ``` <img alt="A lazy image" class="lazy" data-src="lazy.jpg" /> ``` 使用了 img 元素，class 設為 lazy，但不設定 src 屬性（因為設了瀏覽器就會直接去抓圖片），而是使用 data attribute 來另外給一個 data-src 屬性 這是一種常用的 API 設計，套件會自己去找出 `.lazy` 的元素，然後去找元素的 `data-src` 屬性，接著載入圖片 要啟用套件，需要以下 javascript ``` var lazyLoadInstance = new LazyLoad({ // Your custom settings go here }); ``` 這樣就完成了，很簡單吧？ 這邊用到了 javascript 的 OOP 物件導向語法，new 出一個新物件。可以先不管 OOP 細節，照做就好，反正就是創造一個物件然後執行一些函式 創造的同時，會傳一個用大括號 `{}` 包起來的物件進去，當作套件的設定值。這邊因為都用預設的設定，所以傳空物件進去就好 `//` 開頭的是註解，是給開發者自己看的提醒文字，沒有實際功能 比較進階的用法會類似這樣 ``` var lazyLazy = new LazyLoad({ elements_selector: ".horizContainer", callback_enter: initOneLazyLoad, unobserve_entered: true // Stop observing .horizContainer(s) after they entered }); ``` 這個例子傳了有三個屬性的物件進去 各個設定與功能效果，可以再查文件，反正會用 `{}` 包起來的物件去進行參數設定就對了 這種「傳一個物件當參數，來進行套件的功能設定」的設計，也是 javascript 套件的常用 API 設計 關於物件這種資料型態，之後的課程會再進一步學習 ## 課後作業 請使用 https://jsfiddle.net 接著上網尋找 10 張漂亮圖片。參考圖庫：https://unsplash.com/ 假設正在開發一個包含大量高畫質、大圖片的企業形象網站，包含這 10 張圖片，上往下依序排列 一次載入，實在太慢了，尤其是手機用戶、舊電腦的用戶、或者網速很慢的用戶 請替這些圖片加上 lazy loading 功能 做出以上功能，你就完成這次的課程目標了！
建議您將自己完成的網站分享給您的朋友，讓大家看看您最新學會的技能！ 完成這些，你就完成這次的課程目標了！ 想成為網頁設計師的朋友，之後可以開始找更多資源學習CSS的進階技術。 想成為前端工程師的朋友，之後可以開始找 JavaScript 的資源學習。 想成為後端工程師的朋友，之後可以開始找喜歡的後端程式語言學習（例：PHP）。 最後，謝謝你耐心的完成這整套課程！
很多朋友轉職寫程式，在補習班或者線上課程，告一段落之後，開始找工作之前，會整理作品集 關於作品集，簡單給大家一些建議 ## 作品集有用嗎？ 公司在徵人的時候，其實來應徵的人五花八門 滿多人看起來，根本不會寫程式，連最基本的小網頁或者小程式都寫不出來 連基本技能都沒有準備好，感覺是到處碰碰運氣、履歷亂誇大就到處丟。公司面試時，最怕遇到這種狀況 作品集，至少代表，你寫得出基本東西。很多人根本寫都不會寫，就去應徵了，作品集至少可以讓公司避免踩雷 話說回來，如果你的作品集，只是補習班的幾個分組專案，糊裡糊塗地完成了，就跟在學校敷衍交報告一樣，你對細節其實不了解，那這種作品集，當然幫助不大，對你的信心也沒有多少幫助 ## 要做什麼作品？ 所以該做什麼作品呢？ 最好做一些你真的需要的「應用程式」，寫起來才有動力、才好玩，內容也才扎實 簡單舉例，如果你在受訓的過程是這些： ### 前端工程師 做個待辦事項清單工具吧！按照自己的喜好設計，做完之後找地方上線 在找工作的這幾個星期，實際拿這個工具來做紀錄，投履歷時、面試時，很自然可以分享你的心得跟小熱情 對面試官來說，看到面試者有即戰力（即便是有一點點）、對自己的程式有熱情（即便只有一點點），都會加分不少 請參考 https://todomvc.com/ 這是各種前端工具寫的 todo list 應用程式，你還可以比較自己的程式碼，與社群所寫的差異 ### 後端工程師 我鼓勵後端的入行者，寫一個「個人專屬部落格」 這個部落格要有以下功能 - 首頁列出文章清單 - 能簡單單篇文章瀏覽 - 自己可以登入後台 - 在後台可以新增、編輯、刪除文章 有餘力的話，還可以加個留言功能 這種部落格，會實際做完資料的 CRUD 基本功能，還有簡易的註冊、登入、驗證 找地方把這個部落格上線，或者買網址、租主機，實際上線 在找工作的這幾個星期，實際拿這個部落格，來寫文章、技術筆記、經驗分享 面試官絕對會覺得你是積極的人、有備而來 （錄取之後就停止寫網誌的習慣也沒關係） ### 全端工程師 我鼓勵全端的入行者，寫一個「個人行事曆工具」並且是 single page application (SPA) 這個行事曆要有以下功能 - 有一個行事曆頁面 - 有個按鈕可以新增活動 - 點擊行事曆內的活動，可以編輯、刪除 - 有一個清單業面，可以用條列式顯示全部活動 - 全程使用 ajax，不能整個刷新頁面 這種行事曆，會實際做完資料的 CRUD 基本功能，還有基本的 SPA routing 在找工作的這幾個星期，實際拿這個行事曆，紀錄生活是像、活動 面試時分享，面試官絕對會覺得你是積極的人、是個即戰力 ## 結論 除此之外，做個人履歷表的網頁也不錯 可以搜尋 'Portfolio website examples' 看看各種漂亮設計 實際把履歷做成網頁，也可稍微證明自己能力 在工程師生涯，不斷地做自己的 side project 是一個有趣、進步的好習慣 甚至有一天，你做的某個 side project 大受歡迎，還可能變成一個獨立的小產品呢 有空可以逛逛 https://www.producthunt.com/ 看看大家都在做什麼 side project 或許模仿其中一些，做個簡易版本，你會學到很多的～！ --- 您有沒有什麼好的點子、推薦的 side project 點子給初心者呢？ 歡迎留言分享！
我的自學開發之旅始於大約 15 年前，當時我還是個小孩。它慢慢從熱情變成了我的工作。 我成為了一名普通的開發人員、自由職業者。有時我因為興奮每天在電腦前瘋狂地呆上 20 個小時，有時我因為過度勞累和壓力而筋疲力盡。 這些經驗，讓我想分享幾點心得。 原文出處：https://dev.to/entrptaher/reflections-on-my-15-year-journey-from-novice-to-intermediate-developer-pje --- ## 您如何定義初級軟體工程師？ 有幾個跡象表明軟體工程師是初學者。其中包括： - 不熟悉核心編程概念和最佳實踐。 - 很難編寫乾淨、結構良好且高效的程式碼。 - 在沒有完全理解其工作原理的情況下，依賴從線上資源複製和貼上程式碼。 - 難以排除和除錯程式碼中的錯誤和問題。 - 對編程語言和工具的了解有限。 - 缺乏在實際專案或團隊環境中工作的經驗。 這些是軟體工程師可能是初學者的一些潛在跡象。重點是，初學者不一定是壞事——每個人都必須從某個地方開始，每個人都有不同程度的經驗和專業知識。 但是，如果你在軟體工程師身上發現這些跡象，則可能表示他們仍處於學習的早期階段，可能需要更多的指導和支持。 ##初學者應該知道的事情 以下是我想給剛開始學習如何編碼的人的一些提示： 1. **首先確保每個專案或任務都有可以實現的明確目標。** 這可以幫助您集中精力工作，避免被不重要的程式碼分心。 使用 Notion、ClickUp、Github Issue 等工具。 2. **找出最重要的任務和功能**並首先處理它們。 這可以幫助您在專案上取得進展並按時完成任務，同時仍然給您時間來嘗試新想法。 3. **向更有經驗的軟體工程師尋求回饋和幫助**。 這可以幫助您找出可能在不必要或無用的程式碼上花費太多時間的地方，並教您如何更有效地工作。 檢查 Github 問題、Stackoverflow、Dev.to、Facebook 群組。 4. 使用工具和方法更好地**追蹤您的時間和任務。** 這可以通過使用專案管理軟體、使用敏捷開發方法或遵循其他高效編程的最佳實踐來完成。 使用 DeskTime、TimeDoctor 等工具。 5. **經常休息**，不要不停地長時間工作。 這可以幫助您避免在工作中精疲力盡，並讓您的注意力集中在手頭的任務上。 番茄鐘是一個很好的方法。 6. **除非需要，否則不要重構**。 重寫或重構程式碼是提高程式碼易讀性、修復難易度或執行速度的好方法。但這可能會花費很多時間，而且並不是永遠必要的。 在開始一個大的重構專案之前，你應該仔細考慮它是否會帶來真正的好處。你不應該為了改變而改變。 7. **與其他軟體工程師一起工作**並與他們交談。 作為初學者，您可以從比您了解更多或經驗更多的其他軟體工程師那裡學到很多東西。 通過一起處理專案、共享想法和程式碼以及互相提供回饋和幫助，您可以更快地學習和成長為一名軟體工程師。 8. **使用版本控制**來管理你的程式碼。 版本控制軟件，如 Git，可讓您跟踪程式碼的更改，與其他人一起工作，並在需要時恢復到舊版本。 這可以幫助您組織、加快並確保您的工作安全。它還可以幫助您避免丟失重要程式碼或犯錯誤。 9. **將你的工作組合成一個作品集**，以展示給可能的雇主看。 當您剛開始作為一名軟體工程師時，可能很難找到您的第一份工作或專案。 建立您的作品集是脫穎而出並向潛在雇主或客戶炫耀您的技能的一種方式。 這可以包括已完成的專案、您的程式碼範例或展示您的技能和潛力的其他工作示例。 10. **不斷學習**關於編程的新事物並跟上最新的變化（與你的目標相關）。 編程是一個總是在變化的領域，所以總是有新的語言、框架、工具和方法需要學習。作為一名軟體工程師，您可以不斷進步，並通過保持好奇心和與時俱進，在競爭越來越激烈的領域保持領先地位。 11. **編寫乾淨易讀的程式碼。** 作為初學者軟體工程師，您可能只想專注於讓您的程式碼正常工作，而沒有考慮閱讀或修復程式碼的難易程度。但是編寫乾淨且易於閱讀的程式碼很重要，原因不止一個。 它可以使您的程式碼更易於理解和更改，從長遠來看可以節省您的時間和精力。它還可以使您的程式碼更易於查找和使用，這在與其他軟體工程師合作或將您的程式碼放入更大的系統時會很有幫助。 12. **寫很多測試。** 測試是開發過程的重要組成部分，它可以幫助您發現錯誤並修復它們。 通過編寫和執行測試，您可以確保您的程式碼按您希望的方式工作，並且您可以在問題變得更糟之前找到並修復任何問題。 這可以節省您的時間、精力和挫折感，並幫助您為用戶或客戶提供品質更高的程式碼。 13. 照顧好**您的身心。** 編程對您的思想和身體來說都很難。可能需要長時間集中註意力、解決問題以及與他人合作，這對您的身體和思想來說都是艱難的。 如果您想避免倦怠並保持良好的工作狀態，照顧好自己很重要。充足的睡眠、規律的鍛煉、良好的飲食和工作中的休息都是做到這一點的方法。 照顧好你的健康會讓你保持專注、充滿活力和積極性，讓你成為一個更好的軟體工程師。 14. **了解如何除錯**您的程式碼。 除錯是開發的一個重要部分，每個軟體工程師都需要知道如何去做。 通過學習查找和修復程式碼中的錯誤和錯誤，您可以使其更可靠、更快速，並且您不會將時間浪費在無法按您希望的方式工作的程式碼上。 您可以使用許多工具和方法來修復程式碼中的錯誤。如果你想成為更好的軟體工程師，你應該學習和練習這些技能。 15. **遵守編碼規則和最佳實踐**。 如果您剛開始成為一名軟體工程師，您可能不知道在您的語言或領域中編寫程式碼的規則和最佳實踐。 學習並遵循這些標準和最佳實踐非常重要，因為它們可以幫助您編寫更易於閱讀、維護和使用的程式碼。 它們還可以幫助您避免常見的錯誤和陷阱，並且可以使其他軟體工程師更容易理解和使用您的程式碼。 通過遵循編碼標準和最佳實踐，您可以提高程式碼質量並使其對您和其他人更有用。 16. **承擔困難的專案和問題**。 如果您剛開始成為一名軟體工程師，您可能會傾向於只從事小型或簡單的專案，這樣您就不會太忙或太沮喪。 但重要的是要推動自己並承擔更大、更艱鉅的專案，因為這是你作為一名軟體工程師學到最多和成長的方式。 通過解決難題和克服障礙，您可以提高自己的技能、獲得信心並建立一個您可以引以為豪的工作體系。 17. **積極主動，主動出擊。** 不要只是等待別人告訴你該怎麼做。尋找學習和成長的機會，迎接新的挑戰。 18. **Google 一切。** 了解如何使用 google、觀看視頻和教程、存取 stackoverflow 和 reddit。但切勿在不了解其工作原理的情況下複製程式碼塊。 另外，在詢問其他高級開發人員之前，給自己設定一個谷歌搜尋的時間限制。 ##初學者應該避免的事情 以下是新軟體工程師不應該做的一些事情： 1. **忽略編程領域的最新趨勢**或時尚。 編程世界瞬息萬變，總有新的語言、框架、工具和技術需要學習。 然而，並非所有這些發展都具有同等價值或相關性，追逐每一個新趨勢或時尚可能會浪費時間和精力。 相反，專注於編程的基本概念和原則，並學習與您的目標和專案最相關和最有用的工具和技術。 2. **忽略成為完美**軟體工程師的壓力。 作為初學者，很自然地會感到要做到完美、避免犯錯或達到更有經驗的軟體工程師的標準的壓力。 然而，完美是可望不可及的，更重要的是專注於學習和提高。 樂於犯錯，從中吸取教訓，並作為一名軟體工程師繼續成長和發展。 3. **忽略將自己與他人比較**的誘惑。 作為初學者，很容易將自己與其他可能比您有更多經驗、更多技能或更成功的軟體工程師進行比較。 然而，比較很少有用，而且可能會損害您的信心和動力。 相反，專注於你自己的目標和進步，並慶祝你自己的成就，無論它們看起來多麼微不足道。 4. **忽略那些告訴你你不夠好或者你做不到的聲音**。 作為一名初級軟體工程師，你可能會遇到很多聲音告訴你你不夠好，你沒有合適的技能或知識，或者你應該放棄。 這些聲音可以來自很多方面，包括你自己的疑惑，別人的期望，或者領域的挑戰。忽略這些聲音並相信自己和自己的能力很重要。 你有潛力成為一名成功的熟練軟體工程師，如果你願意付出努力和奉獻，你就可以實現你的目標。 5. **忽略讓你的解決方案過於復雜化的誘惑**。 作為初學者，您可能會試圖使您的解決方案過於復雜，加入不必要的功能或增強功能，或者試圖用您的程式碼打動別人。 然而，簡單直接的解決方案往往是最好的，而且它們比複雜精密的解決方案更有效、更易於維護和有效。 通過關注核心需求並避免不必要的複雜化，您可以編寫對自己和他人更有價值和有用的程式碼。 6. **忽略對失敗的恐懼。** 作為初學者，您可能害怕失敗、犯錯誤或達不到他人的期望。 這種恐懼會讓你退縮，阻止你冒險、探索新想法或挑戰自己。重要的是要忽略這種恐懼，並將失敗視為學習和成長的機會。 通過從錯誤和失敗中吸取教訓，您可以成為更好的軟體工程師，並且可以培養在該領域取得成功所必需的韌性和毅力。 --- 作為初學者，很難採納建議，即使建議的人是出於善意。但如果你能堅持下去，按照有經驗的人告訴你的去做，你就會變得比你想像的更快。所以不要害怕邁出這一步並嘗試新事物。
向您介紹這個開發人員工具列表。它是一個開源專案，由社群整理。 讓我們開始吧！ 🚀 原文出處：https://dev.to/dostonnabotov/ultimate-tools-for-developers-2aj2 --- ## 程式碼編輯器和 IDE 💻 - [Visual Studio Code](https://code.visualstudio.com/) 作為免費的開源程式碼編輯器，Visual Studio Code 是開發人員的絕佳工具。它帶有許多功能和外掛，使其成為開發人員的絕佳選擇。 - [CodeSandbox](https://codesandbox.io/) 簡單來說，CodeSandbox 就是 Visual Studio Code 的在線版本。 - [Dev - Visual Studio Code](https://github.dev/) github.dev 基於網絡的編輯器是一種輕量級的編輯體驗，完全在您的瀏覽器中執行。 有兩種方法可以打開基於 Web 的編輯器 1. 在任何存儲庫或拉取請求上按 `.` 鍵 2. 將 URL 中的 .com 替換為 .dev。例如。 `https://github.dev/username/repo` - [CodePen](http://codepen.io/) CodePen 是網絡前端的遊樂場。這是一個試驗、測試和展示您的前端工作的地方。此外，您還可以從其他開發人員那裡找到許多靈感。 - [Replit](https://repl.it/) Replit 是一個簡單、強大且協作的在線 IDE。這是編碼、協作和託管專案的好地方。 - [StackBlitz](https://stackblitz.com/) 面向前端和全棧開發人員的 Web IDE。 - [TypeScript Playground](https://www.typescriptlang.org/play/) 想玩玩看 TypeScript 嗎？ TypeScript Playground 是一個適合你的地方。 ## 圖片 🖼 - [Unsplash](https://unsplash.com/) 為您的下一個專案輕鬆找到精美、高質量的照片。所有照片均可免費用於商業和個人用途。 - [Pexels](https://www.pexels.com/) Pexels 是免費庫存照片的重要來源。所有照片均可免費用於商業和個人用途。 - [Carbon](https://carbon.now.sh/) Carbon 是一個很棒的平台，可以建立和共享程式碼的精美圖像，允許您使用語法突出顯示、主題、字體等自定義圖像。 ## 顏色 🎨 - [Color Space](https://mycolor.space/) 再也不會浪費時間尋找完美的調色板！只需輸入顏色！並生成漂亮的調色板 - [Coolors](https://coolors.co/) 建立完美的調色板或從數千種美麗的配色方案中汲取靈感。 - [Color Wheel](https://www.canva.com/colors/color-wheel/) 想知道什麼顏色搭配起來好看嗎？ Canva 的色輪讓色彩組合變得簡單。 ## 排版 📝 - [Google Fonts](https://fonts.google.com/) Google Fonts 是一個包含免費授權字體系列的庫。只需選擇您想要的字體，將它們下載到您的計算機或使用提供的 CSS 或 HTML 鏈接將它們嵌入您的網頁。 - [Fontsource](https://fontsource.org/) 如果您不想從 CDN 獲取字體，則可以使用整齊打包的 NPM 包中的自託管開源字體。 - [Nerd Fonts](https://www.nerdfonts.com/) Nerd Fonts 使用大量字形（圖標）修補針對開發人員的字體。 ## 設計 🎨 - [Figma](https://www.figma.com/) 一個免費的線上協作界面設計工具和原型製作工具。 - [Pinterest](https://www.pinterest.com/) Pinterest 是一種視覺發現工具，可用於為您的所有專案和興趣尋找創意。 ## 文檔 📚 - [MDN 網絡文檔](https://developer.mozilla.org/en-US/) 學習Web開發的最佳平台。每當您對 HTML、CSS、JavaScript 或任何其他網絡技術有疑問時，請務必先查看 MDN。 - [W3Schools](https://www.w3schools.com/) 幾乎所有您能想到的程式語言的參考。 - [CSS 技巧](https://css-tricks.com/) 提供使用 CSS（層疊樣式表）的提示、技巧和技術的最佳平台之一。 ## 工具 🛠 等一會兒！工具中的工具？是的，你沒有聽錯。這裡有一些工具可以幫助您找到更多工具。 😃 - [Stack Overflow](https://stackoverflow.com/) Stack Overflow 是一個面向專業和狂熱工程師的問答網站。這是提出問題和獲得答案的好地方。 - [Micro Digital Tools](https://mdigi.tools/) 一組對開發人員有用的工具。 - [Small Dev Tools](https://smalldev.tools/) 一組對開發人員有用的工具。 - [Can I Use](https://caniuse.com/) Can I Use 提供了最新的瀏覽器支持表，以支持桌面和移動 Web 瀏覽器上的前端 Web 技術。 - [網站圖標生成器](https://favicon.io/) 您是否曾經為了替自己的網站建立網站圖標而苦惱？不同的尺寸，不同的格式，不同的平台。 從文本、圖像或從數百個表情符號中選擇快速生成您的網站圖標。 - [Font Awesome](https://fontawesome.com/) 免費和高級圖標庫。 - [OverAPI.com](https://overapi.com/) 以有組織的格式查找大量不同技術的備忘單。 - [Transform](https://transform.tools/) 多語言網絡轉換器。輕鬆將 HTML 轉換為 Pug、將 TypeScript 轉換為 JavaScript、將 Markdown 轉換為 HTML 等等... - [Frontend Tools](https://murtazajoo.github.io/tools/) 一個網站，您可以在其中找到具有更好用戶體驗的所有工具。 - [GitProtect](https://gitprotect.io/) 適用於所有 GitHub、GitLab、Bitbucket 和 Jira 資料的 DevOps 備份和災難恢復軟體。 - [Linear](https://linear.app/) 在團隊中組織問題和拉取請求的好工具。 ## 結論 🎉 希望您覺得這個列表有用。
為您的開源專案提供良好的文檔是一項重要（且經常被忽視）的功能，可以促進採用並展示您的軟體的全部潛力。 不幸的是，文檔的增長速度通常比程式碼慢得多，主要是因為一些看起來相當簡單的實現，會產生大量可能的用例和變化。不可能涵蓋所有可能的場景，這就是為什麼技術作家的首要工作是確定範圍和確定優先級。關注基本知識非常重要，必須首先記錄以支持最常見的用例。 在這篇文章，我將分享一些技巧，為您的專案打造一個好的 README 文件。 原文出處：https://dev.to/erikaheidi/documentation-101-creating-a-good-readme-for-your-software-project-cf8 ## README 檔案 專案的 README 文件通常是用戶與您的專案的第一次接觸，因為這是他們在訪問您的專案時首先看到的內容。這就是為什麼優先考慮將好的 README 作為專案文檔的起點很重要。 自然地，不同的專案在 README 中有不同的東西要展示，但這些技巧應該作為大多數軟體專案的良好起點。 ## 1. 少即是多 你可能想把所有東西都放在你的 README 中，比如如何安裝和使用項目，如何部署，如何調試......更詳細地涵蓋這些主題的更完整文檔的鏈接。 當您開始時，只有一個 README 就可以了。很長的 README 沒有吸引力，因為沒有目錄或菜單可供導航，因此更難找到訊息，這最終不利於良好的用戶體驗。鏈接到相關資源的較短的自述文件使專案看起來更有條理且不那麼複雜。 如果我不想為這個專案創建一個專門的文檔網站怎麼辦？那麼，在這種情況下，您可以考慮在根目錄中創建一個 `docs` 文件夾，您可以在其中保存額外的 markdown 文檔，這些文檔可以直接從您的代碼託管平台（假設是 GitHub）瀏覽。 ## 2. 將 README 拆分為其他文檔 對於存儲庫中的文檔，您可以在應用程式的根目錄中創建一個“/docs”目錄，並使用“/docs/README.md”文件作為文檔的入口點或索引。 此文件夾的內容大概就像： - installation.md - 詳細顯示如何安裝項目的文檔。 - usage.md - 項目使用情況和主要命令的更詳細視圖。 - advanced.md - 包含一些進階使用選項和用例的文檔。 這些只是一些可以作為起點的想法。如果您覺得需要創建一個包含子文件夾的更複雜的結構，您應該認真考慮為您的項目創建一個專門的文檔網站（我們將在本系列的後續文章中介紹）。 ## 3. README 文件要點 以下是您的 README 文件中絕對應該包含的一些內容： - 項目的大致概述，包括編寫它的語言、它的作用、它為什麼有用； - 安裝要求； - 安裝文檔的鏈接； - 使用概述，讓用戶簡要了解如何執行它； - 故障排除或測試提示（可以是指向單獨文檔的鏈接）； - 連接到其他資源以了解更多訊息。 理想情況下，這些應該是簡短的說明，可在必要時鏈接到更全面的文檔。 根據項目的規模和目標，您應該考慮將其他內容放在那裡： - 指向 CONTRIBUTING.md 文檔的鏈接，其中包含有關用戶如何為您的專案做出貢獻的詳細訊息 - 指向包含項目行為準則的 CODE_OF_CONDUCT.md 文檔的鏈接。 如果您的項目託管在 GitHub 上，這些將顯著顯示在右側欄的項目頁面中，就在“關於”部分的正下方。 ### 示例結構 以下是 markdown 的一般結構，您可以將其用作構建專案自述文件的基礎： ``` # Project Name A paragraph containing a high-level description of the project, main features and remarks. ## Requirements Here you should give a general idea of what a user will need in order to use your library or application. List requirements and then link to another resource with detailed installation or setup instructions. - Requirement one - Another requirement Check the [installation notes]() for more details on how to install the project. ## Usage Include here a few examples of commands you can run and what they do. Finally link out to a resource to learn more (next paragraph). For more details, check the [getting started guide](). ## Useful Resources Include here any other links that are relevant for the project, such as more docs, tutorials, and demos. ``` ## 4. 使用徽章 您可以使用徽章通過自動從專案中提取的快速訊息來豐富您的 README，例如最新構建的狀態、最新的穩定版本、專案許可證等。 有不同的服務可以為開源專案提供徽章。正如@mohsin 在這篇文章的評論部分所指出的，您可以直接從 GitHub Actions 中提取徽章，方法是轉到您的工作流程頁面，單擊右上角顯示的三個點，然後從中選擇“創建狀態徽章”菜單：  這將向您顯示一個帶有降價代碼的對話框，您可以將其複製並貼上到您的 README 文件中。 另一個不錯的選擇是使用網站 [Shields.io](https://shields.io/)，它提供了幾種不同的徽章，您可以在您的開源項目中免費使用。 例如，這是顯示最新版本 [yamldocs](https://github.com/erikaheidi/yamldocs) 的圖像 URL： ``` https://img.shields.io/github/v/release/erikaheidi/yamldocs?sort=semver&style=for-the-badge ``` 這會生成以下徽章，顯示最新版本：  這是帶有多個徽章的 README 示例：  ## 結論 文檔是任何軟體專案的重要組成部分，應該從一開始就認真對待。最好的開始方式是創建一個好的自述文件，向用戶顯示基本信息，而不是用他們可能不需要的內容來淹沒他們，以便開始使用您的專案。
在 Web 開發世界中，有時感覺就像每天都有新的前端框架問世！大多數來去匆匆，但有一件事是肯定的：Svelte 將繼續存在。 不過，這並不意味著您應該放下一切並在今天學習！追逐最新潮流會讓您分心和不知所措。 這篇文章將一勞永逸地回答：**我應該學習 React 還是 Svelte？**。 您將看到一些程式碼範例，這些範例解釋了為什麼 React 開發人員會為 Svelte 瘋狂，但我們也必須實際一點。 React 已經存在了很長時間。有更多的套件、支援、職缺。 Svelte 還能取代 React 嗎？讓我們找出答案！ - 原文出處：https://dev.to/mikehtmlallthethings/svelte-vs-react-which-framework-to-learn-in-2023-50gf --- * 📍 什麼是 React？ * 📍 什麼是 Svelte？ * 📍 React 和 Svelte 的 5 個區別 * Svelte 的捆綁包尺寸更小 * Svelte 更容易學習 * Svelte 使用純 HTML、CSS 和 JavaScript 進行編譯 * React 有更多的套件 * React 有 React Native * 📍 React 是庫還是框架？ * 📍逐行比較 React 和 Svelte 專案 * 📍 Svelte 比 React 快嗎？ * 📍 何時從 React 切換到 Svelte * 📍 結論 ### **What is React?** 讓我們從 React 開始。 React 是一個漸進式 JavaScript 前端框架（或函式庫，具體取決於您詢問的對象），可幫助您構建複雜的 Web UI。 它由 Facebook（現為 Meta）於 2013 年創建，能夠很快在前端 Web 開發領域站穩腳跟。 React 的核心是狀態和渲染狀態，這意味著要使用它，您必須添加其他庫來處理客戶端功能和路由。 ### **What is Svelte?** Svelte 也是一個前端 JavaScript 框架，但採用了更加一體化的方法。 Svelte 具有內建的狀態管理、路由和客戶端 (DOM) 功能。  React 需要第三方庫和工具，如 Redux、React Router、JSX，而 Svelte 內建了很多這樣的功能。它不太靈活，但更方便和一致。 它採用更幕後（魔術）風格的方法，它直譯非常基本的 JavaScript 程式碼並為您處理 UI 和狀態管理： ``` <script> let count = 0; function handleClick() { count += 1; } </script> <button on:click={handleClick}> Clicked {count} {count === 1 ? 'time' : 'times'} </button> ``` Svelte 由紐約時報的開發人員 Rich Harris 於 2016 年創建，用於以高效的方式處理複雜的圖表和圖形。它從那裡成長為 React 和 Vue 之類的備受喜愛的競爭對手。 ### **React 和 Svelte 之間的 5 個區別** ### **1。 Svelte 的構建包大小要小得多** 我們在下面構建的相同（功能）應用程序。部署包大小在 React 是 41.2 kB，在 Svelte 是 2.1 kB。這幾乎減少了 **20x** 🤯 為了獲得這些數字，我構建了一個在 Svelte 和 React 中具有相同功能的應用程序。我們將在 React 與 Svelte 代碼分解部分深入研究這些應用程序。  我用 React 和 Svelte 構建了一個相同的應用程序。看看 Svelte 包小了多少！ ### **2。 Svelte 更容易學習，因為它的語法簡單** Svelte 採用更幕後的魔術方法，允許您編寫非常少量的樣板或語法糖來完成複雜的綁定。模板語法只是帶有一些額外內容的 HTML，這與 JSX（React 等價物）有很大不同並且更容易學習。 React 變數宣告：  Svelte 變數宣告：  Svelte 看起來像純 JavaScript，但它具有與 React 完全相同的功能。更新 Svelte 變數將自動更新它所在的 UI 元素。 ### **3。 Svelte 符合純 HTML、CSS 和 JavaScript** Svelte 將您編寫的程式碼編譯成基本的 HTML、CSS 和 JavaScript。它不需要像 React 那樣與你的代碼捆綁在一起！ React.js 需要存在於一個 bundle 中以完成所有正確的虛擬 DOM 比較和創建，Svelte 不使用虛擬 DOM 來處理 UI。相反，它選擇了基本的 JavaScript 元素創建函數，例如 document.createElement。 ### **4。 React 擁有更多為它構建的庫和包** React 已經存在了 3 年多，也是目前 JavaScript 框架事實上的王者👑。正因為如此，它擁有大量用戶和公司創建的軟件包。 用戶創建的包通常只是為了使路由和狀態管理更容易，或者添加滑塊、燈箱等。這些並不重要，因為 Svelte 具有可靠的選項，並且兼容/適應大多數 JavaScript 套件。 有點困難的是，要跟任何其他框架之前創建的 React 套件整合時不容易。我在 Solana 和以太坊上從事 Web3 專案時經常遇到這個問題。 ### **5。 React 有 React Native** React Native 是使用率最高和受支持最多的跨平台框架之一。它提供了使用 React 創建 iOS 和 Android 應用程式的能力。全部來自同一個代碼庫。由於其成熟度，它擁有大量的庫、支援和學習資源。 儘管有 Svelte 的替代方案，例如稱為 Svelte-native 的 NativeScript 改編版，但它們不具有與 React-native 相同的可靠性和功能。 ### **React 是函示庫還是框架？** 儘管 React 通常被稱為框架，但可以說，由於其範圍，它更像是一個函式庫。它專門負責管理 UI 的狀態並使其與應用程式中的資料狀態保持同步。 因此，它需要第 3 方函式庫來處理應用程式路由 (React Router)、UI 創建 (JSX) 和元件之間的狀態管理 (Redux)。 另一方面，Svelte 內建了上述所有功能，因此更像是一個完整的 UI 管理解決方案。 你可以看到大多數人都同意這是一個函式庫，但仍有一些爭論👇 https://twitter.com/htmleverything/status/1597574223148765185 ### **逐行比較 React 和 Svelte 專案** 比較兩種 Web 技術的最佳方法是深入研究並使用它們進行構建。構建完全相同的應用程序有助於了解每個庫/框架如何處理不同的功能。 讓我們看看： * 條件渲染 * 模板循環 * 更新狀態 * 事件掛鉤 ### **我們在建造什麼？** 編碼是一項口渴的工作，因此我們將構建一個簡單的網絡應用程序，允許用戶跟踪他們全天喝了多少杯水（或🍺）。 額外的好處是顯示每杯喝醉的歷史和時間。 我們將保持 UI 簡單，以更多地關注底層框架。 （見下面的用戶界面） https://codesandbox.io/embed/react-water-example-scrimba-ny5q0m?fontsize=14&hidenavigation=1&theme=dark ### **React** 為了分解代碼，首先讓我們深入了解一些 React 概念和術語👇 React 有幾種類型的語法你需要學習。鉤子、狀態和模板 (JSX) 是主要的。 鉤子 - 允許您進入應用程序的生命週期 State - 允許您根據數據的變化更新 UI 元素。它將“狀態”（或更簡單的變量）更改與 UI 更新聯繫起來 模板 - 允許您直接在 HTML 中使用變量和 JavaScript React 組件的樣式通常由單獨的 .css（或 .scss）文件處理。 ### **React 代碼分解** https://codesandbox.io/embed/react-water-example-scrimba-ny5q0m?fontsize=14&hidenavigation=1&theme=dark&view=editor 變數是使用 useState 掛鉤設置的，它允許更新變量並讓 UI 動態呈現這些更新。 `useEffect` 用於在加載應用程序時設置今天的日期。 JSX 模板使用基本的“{}”符號以及 HTML 中的標準 JavaScript 函數，允許顯示變量和循環數組（使用“.map”）。 ### **Svelte** Svelte 採用不同的方法，採用更“幕後魔術”的風格。邏輯看起來很像純 JavaScript。在後台，代碼做的事情幾乎與 React 代碼做的一樣。 Svelte 仍然有像 `onMount` 和 `onDestroy` 這樣的鉤子，但是簡單地分配一個變量並讓它完全響應並在模板 (HTML) 中可訪問不需要任何特殊的語法糖。 另一個很大的區別是您可以直接在 Svelte 組件中編寫 CSS/SCSS。這只是一個選項，因為您仍然可以像在 React 中一樣導入樣式，但我注意到大多數 Svelte 項目都使用樣式內組件。 ### **Svelte 代碼分解** https://codesandbox.io/embed/svelte-water-example-scrimba-2vsoid?fontsize=14&hidenavigation=1&module=%2FApp.svelte&theme=dark&view=editor 上面的代碼實例化了一個 cupsOfWater 數組，將新的日期變量設置為當前日期。 聲明一個函數來創建一個新日期並將其存儲在一個名為 cup 的變量中，然後將其添加到 cupsOfWater 數組中。 模板部分更接近 HTML 並增加了一些功能。再次使用“{}”表示法，您可以從“<script>”部分引用任何聲明的變量。您還可以使用事件偵聽器（如 `on:click`）、條件（如 `{#if}`）和使用 `{#each}` 循環。 ### **Svelte 比 React 快嗎？** 是的，從快速的 HTML 生成到更快的構建和開發環境，Svelte 的性能都大大優於 React。 * 生成 HTML * 根據狀態更新 UI * 第一次內容豐富的渲染 * 互動時間 * 速度指數 所有這些都看到了可衡量的差異，而 Svelte 具有優勢。您的應用程序越大越複雜，差異就越明顯。 在 Zeitspace 的一篇文章中可以看到性能比較 https://www.zeitspace.com/blog/we-built-an-app-with-svelte.-heres-what-we-learned ### **Svelte 比 React 好嗎？** 當開始一個新專案時，Svelte 有足夠的優勢，它應該始終是一個考慮因素。 話雖如此，React 在使用率方面仍然絕對勝過 Svelte。這可能會導致專案的第 3 方插件支持、僱用和壽命問題。 不過，為了應對這一點，Svelte 語法的易用性使其非常容易上手，尤其是對於 React 開發人員而言。這是公司在招聘 Svelte 項目時可以藉鑑的東西（不要將自己局限於 Svelte 開發人員）。 ### **何時從 React 切換到 Svelte** Svelte 是構建複雜網站或 Web 應用程序的絕佳選擇。許多老牌公司已經開始將 Svelte 用於內部和外部應用程序： * 1Password * Avast * Chess.com * Alaska Airlines * Fusion Charts * Rakuten * GoDaddy * IBM * Square * 紐約時報 * 飛利浦 但這並不意味著您必須將當前的 React 應用程序放入垃圾桶！ 那麼什麼時候是接觸 Svelte 的合適時機？ 如果您的應用/網站： * 由於頻寬限制，需要較小的包大小 * 需要盡可能快 * 需要快速建造 When is not the right time to reach for Svelte? 什麼時候不適合使用 Svelte？ 如果您的應用/網站： * 嚴重依賴第 3 方集成/工具 * 需要轉換為移動應用程序 這些很快就不會成為問題，但在投入之前確實需要進行一些研究和盡職調查。 ### **結論** 建議投入其中並嘗試在 Svelte 中構建一些東西。如果你來自 React，我幾乎可以向你保證你會喜歡它的簡單性和速度。
一名資深的德國軟體架構師 Jeroen De Dauw，寫了一篇很好的文章，給新手工程師一些寫程式的建議。 - 原文出處：https://dev.to/jeroendedauw/advice-for-junior-developers-30am --- ## 給新手工程師的一般建議 ### 1. 程式碼不是重點 作為開發者，我們喜歡寫程式。大多數工程師希望收到的任務明確，可以不用管技術之外的事情，專心解決有趣的技術挑戰。 請花足夠的心力去確認，您正在解決正確的問題。引用管理學大師 Peter Drucker 的話：高效率地去做一件根本沒必要的事情，結果依然是完全沒意義。儘早、經常去搜集回饋，透過「持續交付」來向真正的用戶互動，成為敏捷（Agile）的工程師。 軟體開發成本高昂，現實世界專案的絕大部份工作都是在維護而已。再加上目標應該是對用戶、對生意有幫助，所以結論就是：寫程式最好的方法，經常是完全不寫。引用比爾蓋茲的話：用程式碼有幾行來衡量工程進度，就像用重量來衡量飛機的製造進度。 另請參閱：YAGNI 原則、KISS 原則、The Last Responsible Moment 文章。 ### 2. 軟體設計很重要 在我開發生涯的前五年，我以為軟體設計是架構師或其他特殊職位的人在做的事。我以為開發者專注在完成任務即可，以為軟體設計、最佳實踐、寫測試這些，都不關我的事。我的程式能跑，我的生產力很高，我以為這樣就對了。 直到我閱讀了 Robert C. Martin 的 Clean Code，這書刺激了我對軟體設計的關注，並包含許多範例與啟發。其中最啟發我的是：走得快的唯一方法，就是走得好。也就是說，如果你把事情搞得一團糟，結果只會讓你速度更慢。 學習寫出設計良好的乾淨程式碼，需要時間和精力。而且剛開始的時候，會寫比較慢，並且會犯錯誤。 ### 3. 使用最佳實踐 寫測試通常會有幫助。雖有例外，但大多數時候，寫自動化測試會大有幫助。寫測試就是一種最佳實踐。 如果你不太會寫測試，請遵循最佳實踐並為所有內容寫測試。**開始時，盲目遵循最佳實踐比遵循自己弱弱的判斷要好**。一段時間之後，您將知道怎麼寫測試比較有效，並能夠區分您搞砸了和不值得編寫測試的情況。因為 bug 變少了、重構起來更輕鬆了，您將開始理解測試帶來的深入的價值。**到有了自己的判斷力後，您將能夠超越最佳實踐**。 此建議適用於您在學習任何最佳實踐的新手時期。自動化測試只是一個例子。 有個陷阱要注意，明智的最佳實踐，與荒謬、適得其反的做法之間，只有一線之隔。因為大多數程式碼都很亂，而且大多數開發者（包括資深人員）不了解軟體設計的基礎知識，因此事情就更複雜了。有一個好的指導者很重要。除此之外，根據我自己的經驗，要小心只存在您的語言、框架社群的最佳實踐。尋找那些已經存在了幾十年的長青建議比較好。 --- ## 給新手工程師的技術建議 ### 4. 寫測試 寫自動化測試。也許在寫程式之前先寫測試，例如運用測試驅動開發（TDD）。這讓您可以輕鬆反覆驗證幾段程式是否正確，而不用一直手動跑測試、除錯。 > 你覺得先寫測試很煩嗎？但之後再忙著抓 bug 有比較好？ 更重要的是，測試為您重構時提供了額外保障。你需要持續重構來保持程式乾淨。沒有可靠的測試保障，程式碼就可能越變越亂。 如果您的程式碼設計不佳，例如使用繼承進行重用，或使用靜態函數，則編寫測試會很困難。另一方面，如果您有遵循 SOLID 原則、沒有全局依賴項，那麼寫出好的測試並不困難。 設計好測試也很重要，因為糟糕的測試只會拖慢開發速度。避免將測試綁定到被測程式碼的實作細節或系統結構。 ### 5. 不要用繼承來做到程式碼重用 這是讓人以為是最佳實踐的其中一個反例。我的建議是：剛開始時，根本就不要用繼承來做到程式碼重用。這通常都幫助有限，而且帶來一大堆麻煩。請多用組合、少用繼承（關鍵字：composition over inheritance）。 ### 6. 寫出 OOP 程式碼 學習 SOLID 原則，避免寫出 STUPID 原則的程式碼 ( https://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/ )。理解這些原則和反模式非常有價值。 創造一些真正的物件。只有靜態方法的類別，根本不算是物件導向。盡量避免完全使用靜態寫法。 ### 7. 寫出函數式程式碼 不要把函數式程式設計，跟指令式程式設計搞混了。 重點不是完全切換到函數式語言。而是學習使用函數式風格的優點。例如減少狀態、讓函數專心一件事。另請參閱：https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell ### 8. 程式碼稍微重複沒關係 將一大塊程式碼到處複製貼上當然很不好。有尊嚴的開發者很快就發現這一點，並開始遵循某種形式的：不重複自己原則 Don't Repeat Yourself （DRY）。不幸的是，對 DRY 的追求往往會導致過度工程和額外的複雜性。所以會有一條新原則：寫兩次原則 Write Everything Twice（WET）。也就是僅在第三次出現重複時，才動手改善重複段落。 ### 9. 型別、命名、註解 試著寫一些能夠表達自我的程式碼，避免寫註解。 > 每次寫註解時，都應該要皺一下眉頭，感受到自己的表達能力有點失敗。 —— Robert C. Martin 註解很危險，因為有可能說謊。程式碼可以不更新註解就修改，那一開始的註解就變錯誤了。這種情況下，註解不但沒幫助，還會誤導到別人。 要寫出能夠表達自我的程式碼： - **一個函數只做一件事** 因為只做一件事，就能給一個清楚的命名。 - **減少狀態** - **使用型別** 定義清楚的型別，加上跑測試，能讓系統更穩定。 - **減少混合型別** 避免可以同時是整數、布林值或字串的參數或回傳值。如果讓每個函數專心一件事，這自然會做到。 - **寫測試** 良好的全面測試，也同時會是程式碼的使用說明範例。 Robert C. Martin 的書 Clean Code 在命名和寫註解方面有提供一些很好的經驗法則。 --- 以上，希望對大家有幫助！
每週做一些紀錄，一段時間之後，才會明確知道自己到底有沒有成長、以及到底學會了哪些東西。 來留言吧！ 說說看最近在學什麼技術＆覺得什麼部份特別難！ 大家也可以針對大家的留言，分別回覆一些建議＆指引方向！ 留言吧！養成紀錄的習慣，絕對是一個好習慣！
寫 JavaScript 時，仍在使用 console.log 來除錯抓蟲？ 是時候**升級你的技能**並學習 JavaScript console 物件的全部功能了。 從 console.table 到 console.time，這些進階方法和技巧將改善您 **debug 訊息的品質和可讀性**，讓您更輕鬆地故障排除和修復問題。 在 2023 年成為 JavaScript 除錯高手吧！ - 原文出處：https://dev.to/naubit/why-using-just-consolelog-in-2023-is-a-big-no-no-2429 ## 😞 問題 僅使用 console.log 的最大問題之一是，它會使程式碼混亂且難以閱讀。此外，它本身的資訊量不是很大。它只是輸出你傳遞給它的任何內容的值，沒有任何上下文或其他資訊。 所以，這裡有十個你應該知道的 JavaScript console 物件方法和技巧，值得了解一下！ ## 1️⃣ console.table 此方法以可讀且易於理解的格式，輸出資料表格。console.table 不是只顯示陣列或物件，而是以表格格式顯示，使它更易於瀏覽和理解。 ``` // Output an array of objects as a table const users = [ { id: 1, name: 'John Doe' }, { id: 2, name: 'Jane Doe' } ]; console.table(users); ``` 這將以表格格式輸出 users 陣列，每個物件的屬性作為列，物件作為行。  ## 2️⃣console.group console.group 和 console.groupEnd。這些方法可以在控制台中，創建嵌套的可摺疊資料組。**這對於組織和構建 debug 訊息非常有用**，讓您可以輕鬆查看程式碼不同級別發生的情況。 ``` console.group('User Details'); console.log('Name: John Doe'); console.log('Age: 32'); console.groupEnd(); ``` 這將在 console 中創建一個嵌套的、可摺疊的資料組，標題為“使用者詳細資訊”。組內的日誌消息將縮進並分組在一起。  ## 3️⃣console.time console.time 和 console.timeEnd 可以測量執行程式碼所需的時間。這對於識別程式中的性能瓶頸、效能優化非常有用。 ``` console.time('Fetching data'); fetch('https://reqres.in/api/users') .then(response => response.json()) .then(data => { console.timeEnd('Fetching data'); // Process the data }); ``` 這將測量「從特定 URL 獲取資料並解析 JSON 回應」所需的時間。耗用時間會在控制台中輸出。  ## 4️⃣console.assert 此方法允許您在程式碼中寫 assertions，這些是應該始終為 true 的語句。如果 assertions 失敗，console.assert 將在控制台中輸出錯誤消息。**這對於除錯抓蟲、確保程式碼正常運作非常有用。 ``` function add(a, b) { return a + b; } // Test the add function const result = add(2, 3); console.assert(result === 5, 'Expected 2 + 3 = 5'); ``` 如果 add 函數在給定輸入 2 和 3 時未返回預期結果 5，就在控制台中輸出錯誤訊息。  ## 5️⃣設置日誌樣式 使用 `console` 物件輸出樣式和顏色。 `console` 物件**允許您輸出不同顏色和樣式的文字**，使您的除錯輸出更具可讀性和更容易理解。 您可以在 console.log 語句中使用 %c 佔位符來指定輸出文字的 CSS 樣式。 ``` console.log('%cHello world!', 'color: red; font-weight: bold;'); ``` 這將輸出文字“Hello world!”，並使用指定的 CSS 樣式，以紅色和粗體顯示。  ## 6️⃣console.trace 使用 `console.trace` 方法輸出堆疊追踪（stack trace）。這對於理解程式碼中的執行流程、識別**特定日誌消息的來源非常有用。** ``` function foo() { console.trace(); } function bar() { foo(); } bar(); ``` 這將在控制台中輸出堆疊跟踪，顯示導致 `console.trace` 呼叫的函數呼叫序列。看起來像這樣：  ## 7️⃣console.dir 使用 `console.dir` 方法以分層格式輸出物件的屬性。這對於**探索物件的結構**、查看其屬性和方法非常有用。 ``` const obj = { id: 1, name: 'John Doe', address: { street: '123 Main St', city: 'New York', zip: 10001 } }; console.dir(obj); ``` 這將以分層格式輸出 `obj` 物件的屬性，允許您查看物件的結構及其所有屬性和值。  ## 8️⃣console.count 使用 `console.count` 方法計算特定日誌消息的輸出次數。這對於**追蹤特定程式碼路徑的執行次數**以及識別程式碼中的熱點很有用。 ``` function foo(x) { console.count(x); } foo('hello'); foo('world'); foo('hello'); ``` 這將在控制台中輸出字串“hello”，然後是數字 1。然後它將在控制台中輸出字串“world”，然後是數字 1。最後，它會再次輸出字符串“hello”，然後出書數字 2（因為它被呼叫了兩次）。  ## 9️⃣console.clear 使用 `console.clear` 方法清除控制台輸出。這能保持您的除錯輸出**有條理和整潔**，讓您更容易專注於您感興趣的訊息。 ``` console.log('Hello world!'); console.clear(); console.log('This log message will appear after the console is cleared.'); ``` 這將輸出字串 “Hello world!”，接著一個空行（因為控制台已清除）。然後它會輸出字串 “This log message will appear after the console is cleared.”  ## 1️⃣0️⃣console.profile 使用 `console.profile` 和 `console.profileEnd` 方法來衡量程式碼的性能。這對於**識別性能瓶頸和優化代碼**、提高速度和效率非常有用。 ``` console.profile('MyProfile'); // Run some code that you want to measure the performance of for (let i = 0; i < 100000; i++) { // Do something } console.profileEnd('MyProfile'); ``` 這將開始分析 `console.profile` 和 `console.profileEnd` 呼叫之間的程式碼，並在執行 `console.profileEnd` 時在控制台中輸出結果。輸出將包括有關執行所花費時間的詳細訊息、以及其他與性能相關的各種訊息。  ## 💭 最後的一些想法 在 2023 年，不要僅僅滿足於 `console.log` - JavaScript 控制台物件中有許多**更強大、更有價值的工具和技術。** 從 `console.table` 到 `console.time`，這些方法和技巧將幫助您提高除錯輸出的品質和可讀性，並使其**更容易排除和修復代碼中的問題**。 所以，為什麼不在 2023 年提高您的除錯技能並嘗試這些技術呢？ 以上簡單分享，希望對您有幫助！
面試的時候，常常會被問到這題。看似簡單，其實有一些進階注意事項，此篇與您分享。 - 原文出處：https://dev.to/andyrewlee/stand-out-in-a-react-interview-by-rendering-a-list-like-a-pro-1cn5 # 基本做法 以下是最基本做法。根據陣列內容，直接渲染成一個列表。 ``` import { useState, useEffect } from "react"; const App = () => { const [posts, setPosts] = useState([]); const [currentPost, setCurrentPost] = useState(undefined); useEffect(() => { const initialize = async () => { const res = await fetch("https://jsonplaceholder.typicode.com/posts"); const json = await res.json(); setPosts(json); }; initialize(); }, []); const onPostClick = (post) => { setCurrentPost(post); }; return ( <div> {currentPost && <h1>{currentPost.title}</h1>} <PostList posts={posts} onPostClick={onPostClick} /> </div> ); }; const PostList = ({ posts, onPostClick }) => { return ( <div> {posts.map((post) => ( <Post post={post} onPostClick={onPostClick} /> ))} </div> ); }; const Post = ({ post, onPostClick }) => { const onClick = () => { onPostClick(post); }; return <div onClick={onClick}>{post.title}</div>; }; export default App; ``` # 改進方法 以下是四個可以改進的方向，以及背後的原因。 ## 1. 指定 key 替每個元件提供一個 key 屬性，可以幫助後續 React 渲染時改善效能。要注意 key 屬性要是唯一值，不要直接用陣列索引當成 key。 ``` {posts.map((post) => ( <Post key={post.id} post={post} onPostClick={onPostClick} /> ))} ``` ## 2. 優化渲染 每次點擊列表項目時，都會重新渲染 `PostList` 和每個 `Post`。 ``` const Post = ({ post, onPostClick }) => { console.log("post rendered"); const onClick = () => { onPostClick(post); }; return <div onClick={onClick}>{post}</div>; }; ``` 可以使用 React 提供的 `memo` 功能來優化 `PostList` 元件。用 `memo` 包裝元件時，等於告訴 React：除非 props 改變，否則不要重新渲染這個元件。 ``` import { useState, useEffect, memo } from "react"; const PostList = memo(({ posts, onPostClick }) => { return ( <div> {posts.map((post) => ( <Post post={post} onPostClick={onPostClick} /> ))} </div> ); }); ``` 不過，實際跑下去，會發現還是重新渲染了。因為每次 currentPost 改變時，App 都會重新渲染。每次重新渲染都會重新建立 onPostClick 函數。當一個函數被重新建立時（即使函式內容一樣），都算是新的實體。所以技術上來說，props 確實發生了變化，所以 `PostList` 會重新渲染。 ``` const fn1 = () => {}; const fn2 = () => {}; fn1 === fn2; // => false ``` 這種狀況，就可以使用 useCallback hook 來告訴 React 不要重新建立函數。 ``` const onPostClick = useCallback((post) => { setCurrentPost(post); }, []); ``` 上面的例子中，使用 useCallback 沒問題，可以避免全部貼文被重新渲染。但要知道的是，並非什麼函式都適合包在 useCallback 裡面。 ``` const Post = ({ post, onPostClick }) => { const useCalllback(onClick = () => { onPostClick(post); }, []); return <div onClick={onClick}>{post.title}</div>; }; ``` 比方說，在 Post 元件使用 useCallback 就不太有意義。因為這個元件是輕量級的。應該只在有意義的情況下使用 useCallback（可以用 profiling 工具分析效能確認）。`useCallback` 有缺點：它增加了程式碼的複雜性。使用 useCallback 會在每次渲染時運行的額外程式碼。 ## 3. 元件卸載時清理乾淨 目前的元件沒有在卸載時進行清理。例如，如果在收到 URL 回應結果之前就離開頁面怎麼辦？這時應該要取消請求。 ``` useEffect(() => { const initialize = async () => { const res = await fetch("https://jsonplaceholder.typicode.com/posts"); const json = await res.json(); setPosts(json); }; initialize(); }, []); ``` `useEffect` 可以分為兩部分：掛載時運行的程式碼、卸載時運行的程式碼： ``` useEffect(() => { // When component mounts what code should I run? return () => { // When component unmounts what code should I run (clean up)? }; }, []); ``` 我們可以使用 AbortController ，並在清理時呼叫 controller.abort() 來取消請求。 ``` useEffect(() => { const controller = new AbortController(); const signal = controller.signal; const initialize = async () => { try { const res = await fetch("https://jsonplaceholder.typicode.com/posts", { signal }); const json = await res.json(); setPosts(json); } catch (err) { console.log(err); } }; initialize(); return () => { controller.abort(); }; }, []); ``` ## 4. 增加無障礙輔助功能 以上範例太過簡單，沒有太多無障礙功能可以加入。一旦應用程式變複雜，絕對應該要開始考慮這點。 有個簡單的無障礙測試：可以單獨只使用鍵盤就操作一個應用程式嗎？ 關於這點，快速解法是：把每個項目都轉成按鈕，用鍵盤時就可以在元件之間切換。 ``` const Post = ({ post, onPostClick }) => { const onClick = () => { onPostClick(post); }; return <button onClick={onClick}>{post}</button>; }; ``` # 結論 在 React 中渲染列表，乍看之下，只是個簡單的面試問題。但其實可深可淺。下次面試時遇到這問題，可以思考一下此篇文章談到的各個面向。
面試的時候，通常面試官會問：你有什麼問題想問我們嗎？ 就跟公司面試你一樣，其實你也在面試公司。應該把握機會問對問題。 這邊有幾個重要問題，給你參考，下次面試可以問問看。 - 原文出處：https://dev.to/semaphore/36-questions-to-ask-your-future-software-employer-552g --- # 可以問人資的問題 面試通常會先跟人資聊聊，有些問題可以先問他們。建議可以問一下公司的運作方式以及面試流程。 ## 關於職位 **1. 公司為什麼要招人？** 這是個暖身問題。可以了解公司的大致狀態。缺人是因為在擴編？還是有人剛離職呢？ **2. 這個職位上一個人怎麼樣了？他們是辭職了，還是被開除？** 如果不是擴編，那可以先搞清楚這職位剛發生什麼事。弄清楚這段，可以更了解公司對這個職位的期望。 **3. 公司的離職率是多少？去年僱用了多少開發人員，又有多少人辭職了？團隊中待最久、跟最新進的人員分別是多久？** 這問題可以嗅出一些端倪。高流動率代表工作條件有點問題。可能得不到直接答覆，但別擔心，後面的流程有機會深入討論。 **4.到職流程如何運作？面試過程的下一步是什麼？** 獲取準備下一步所需的資訊。 ## 關於員工生活 **5. 公司是否投資於員工發展、培訓或認證？是否有用於學習活動或參加研討會的預算？** 公司當然喜歡積極進修的員工。所以員工至少要有一點時間能學習或參加活動。如果他們有提供進修預算，那非常加分。 **6. 公司允許遠端工作嗎？我應該在辦公室待多少天？遠端工作者的比例是多少？** 疫情讓遠端成為常態。有些公司 100% 遠端工作。有些公司則是混合辦公。你需要知道公司是哪種 。如果是完全遠端，你要問一下有沒有定期的團建活動，或是聚餐之類的。 **7. 有補助去共享空間工作嗎？** 有些人在家很難專心。這時可以考慮去租共享工作空間。 **8. 有育嬰假嗎？有無薪假嗎？病假和特休等等，怎麼安排？** 如果應徵公告沒有寫清楚，你可以這時先問清楚相關規則。 --- # 技術面試後要問的問題 這時你應該在跟技術人員交談。可能是未來的同事、技術主管、或技術長。 藉此機會暸解工作環境。有些問題可以防止踩雷。 ## 關於每日作息 **9. 通常我一周開幾次會議？** 會議一定會有，但有些公司實在開太多了。這問題可幫助評估，工作時會不會一直被打斷。 **10. 公司有 CI/CD 嗎？或者其他開發流程呢？** DevOps、Scrum、Lean 和 Agile 等術語已被濫用到沒什麼意義了。CI/CD 的意義清楚多了。公司有實踐嗎？如果沒有，代表團隊依賴手動部署、測試。 當然，也有CI/CD不可行的地方。但 99% 的情況下，利大於弊。 **11. 多久部署一次？如何部署？** 關於 CI/CD ，需要知道一天部署幾次。這代表部署流程多順暢。 除非是受到政府監管的產業，不然手動、久久部署一次，代表緩慢又低效率的開發文化。 **12. 你們使用 TDD 還是 BDD？如何寫測試？** 測試驅動開發和行為驅動開發對生產力很有幫助。無論是不是在測試團隊，都應該知道一下公司的測試習慣。如果公司完全不寫測試，那就要小心了。 **13. 你們如何追蹤錯誤/問題？寫功能和修理之間的比例是多少？** 這能幫助了解技術債。有技術債是正常的，但如果太多，你可能就一直在救火、整理超亂的程式碼。 **14. 你們偏好哪種：系統穩定或者快速上新功能？你們對技術債的態度是什麼？** 直接問技術債的態度，但也要知道滿足客戶需求的重視程度。 **15. 文件完整嗎？有程式碼風格指南嗎？有現成的測試規格嗎？** 了解一下文件的習慣。可以詢問 API 規範、技術文件、風格指南、用戶故事之類的。文件不夠通常代表你需要一直開會、一直詢問同事。 測試本身就是一種文件，所以有寫測試也很重要。 ## 工具和文件 **16. 使用什麼版本控制系統？** 如果沒有在用版本控制，建議直接換別間面試。除非你在面試技術長或者技術副總之類的。這情況，要詢問能否導入。如果能，你需要很痛苦的花幾個月導入，談薪水的時候要一併考慮進去。 **17. 使用什麼技術/語言/框架？** 不熟悉也沒關係。通常幾週內就都能上手。 **18. 我可以使用我 ${最愛的 IDE} 嗎？** 用自己最愛的，最棒。 **19.公司有提供設備嗎？我有設備的全部權限嗎？我可以用自己的設備嗎？** 如果在自己的電腦上沒有根權限，代表公司不信任員工。 ## 開發團隊文化 **20. 你為什麼選擇加入這家公司？** 如果跟面試官聊開了，請問一些個人問題。了解你將要為之工作或與之共事的人的價值觀，是很有價值的。 **21. 團隊有多大？新手與資深工程師的比例是多少？** 試著深入了解團隊組成與規模。如果你是應徵初階職位，同事大部分都是資深人士，那就是好事一件。 **22. 有多少女性員工？公司有確保員工多樣性的流程嗎？** 了解一下團隊都是同一種人、或者具有很高多樣性。這對工作氛圍也有影響。 **23. 你在這家公司犯過的最大錯誤是什麼？** 我喜歡這個問題，因為它與「生成式文化」的概念有關。生成式文化是一種風險共擔、鼓勵創新、人們不會因失敗而受到譴責（而是被用作學習機會）的文化。 當人們在心理上感到安全，他們會把握更多機會並進行更多嘗試，從而實現創新。 反例則是，病態或官僚文化。在這種情況下，人們傾向於「謹慎行事」——以免因失敗而受到懲罰。這絕對是很差的工作環境，對你的工作跟心情都很不好。 ## 工作與生活的平衡 **24. 人們平均每週工作多少小時？人們通常什麼時候下班？** 你需要每天早點回家、好好享受生活，才能持續打拼。長期過勞代表團隊生產力很差，只能透過加班彌補。 **25. 有 on-call 的時間表嗎？標準工時以及您對加班的期望？我將多久 on-call 一次？緊急情況或人們被迫加班的頻率有多高？** 這個問題是對上一個問題的補充。一個月通常要加班幾次？ 大量加班、習慣性的周末工作以及不頻繁、手動部署，是工作與生活不平衡的跡象。如果公司有這些危險信號，請繼續貨比三家。 **26. 我是否需要一直在 Slack/Teams 上面，還是可以分批處理我的工作？** 我常常在沒有鍵盤的時候解決問題。常常在散步或洗澡的時候有新想法。能夠離開電腦散步一下，生產力會更好。 --- # 向經理、首席執行長或創辦人提出的問題 痛苦的技術面試完成後，你可能會見到經理、首席執行長、甚至創辦人。可以把握機會了解公司在市場上的表現、也能讓公司知道你對公司很有興趣。 ## 關於公司 **27. 有公司運作 SOP 嗎？** 查看各種 SOP 可以知道公司的運作方式，讓新員工快速進入狀況。 **28. 公司是怎麼賺錢的？損益兩平了嗎？成長速度有多快？** 如果在面試新創公司，獲利需要好幾年的時間，而且機率不高。所以，你其實正在賭一個高風險、高報酬的事情。 您的專業成長通常會反應到公司的成長。如果你追求穩定並打算待好幾年，那麼選擇一家現金流穩定的老牌公司比較好。 **29. 公司或團隊現在面臨的最大挑戰和機會是什麼？** 開放式問題可以讓你深入了解公司的目標和管理層的心態。檢查您的職涯目標是否與公司的目標一致。 **30. 您認為未來 5/10 年後，公司會在哪？** 面試的時候，被問這個是最難回答的。所以你當然也要問公司，這樣才公平。 **31. 公司如何設定季度/年度目標？這一季/今年的目標是？** 如果沒有公司或團隊目標，那麼您要么是在與錯誤的人交談，要么是在與錯誤的公司交談。 對公司的目標表現出興趣，更重要的是，了解當季、當年的優先事項。是否使用 OKR 管理？如果沒有，那是用什麼規劃目標？如何評估成效？ ## 關於職位 **32. 你如何定義我這個職位的成功？你希望我在頭 3 個月內完成什麼？您將如何評估我在試用期的表現？您如何確定某人是否適合您的公司？** 你需要了解試用期如何評估。 **33. 績效考核如何進行？升遷流程如何運作？績效考核與加薪掛鉤嗎？** 您和您的主管可能對成功有不同定義。但績效評估使您、您的主管和公司保持一致。雖然很可怕，但能促進人員和公司的持續改進。這是主管提供回饋、認可成就並提供職業發展指導的好時間。 沒有績效評估，就沒有回饋，晉升或加薪的機會也很小。 **34. 我有多少自主權來決定要做什麼？工作的優先順序如何？是否有分配用於副專案/實驗的時間？** 弄清楚有多大自主空間，藉此了解團隊目前專注什麼。 如果有分配用於副專案/實驗的時間，那就太幸運囉。 ## 提升職業生涯 **35. 我的主管會定期進行一對一的交流嗎？** 一對一對於讓你和主管保持一致非常重要 **36. 我可以為 XXX 開源專案做貢獻嗎？可以去研討會演講嗎？是否需要任何批准？** 如果你有這些興趣，就要問問。這些都是職業發展的寶貴機會。 --- # 結論 公司會展現好的一面，吸引面試者。你需要看穿表面宣傳、弄清楚真實狀況。找到有興趣的問題，不斷提問，直到放心為止。 不要問你本來就該知道的事情。職位描述看清楚，公司網站跟之前的對話看清楚，問重複問題會很鳥。 祝你好運，感謝閱讀！
Github 是開發人員互相分享的寶庫。可以在上面找到任何與軟體工程有關的東西。就跟一般礦山一樣，要懂得採礦，才能得到有價值的礦物。 我一直在尋找 github 上面的寶庫，以下列出五個優質寶庫： - 原文出處：https://dev.to/wizdomtek/5-github-repositories-every-developer-should-know-1p93 # 1. Professional Programming 整理了大量經典書籍、優質網站的專案。 閱讀相關內容會有點花時間，但如果你想要持續提升自己，那這專案很適合你。 https://github.com/charlax/professional-programming # 2. Web Dev For Beginners 這是由 Microsoft 的 Azure Cloud Advocates 團隊，提供的 12週、24週線上課程。通通關於 JavaScript、CSS 和 HTML 基礎知識。每節課都包括課前和課後測驗、內容說明、解決方案、作業等。這種以寫專案為主的教學法，讓您一邊開發、一邊學習，是一種讓有效學習新技能的方法。 https://github.com/microsoft/Web-Dev-For-Beginners # 3. The art of command line 命令列是一門藝術，每個開發人員都有自己的使用習慣。最有用的指令是 man，可以用來查詢各種指令。 這個專案列出了各種常用指令與說明，值得一讀。 https://github.com/jlevy/the-art-of-command-line # 4. Project Based Learning 以專案開發為主的一系列學習資源。由一群熱心分享的工程師所整理。內含多種程式語言。 動手開發是學習程式設計的最好方法。不斷解決問題時，同時學習了知識。因為有了目標，大腦的記憶也更有效率。 https://github.com/practical-tutorials/project-based-learning # 5. Every Programmer Should Know 無論您有多熟練，您對技術的了解可能永遠都不夠。 聽起來很刺耳，但這句話是真的。技術世界太廣闊了，不可能了解一切。但這不是停止學習的理由。 瀏覽此專案，可以掌握很多新知識。 如果您想學習一些新鮮有趣的東西，可以將它當成學習工具。 https://github.com/mtdvio/every-programmer-should-know --- 以上，歡迎有空逛逛這些資源，祝您不斷變強。
Javascript 是一個很棒的程式語言，但是，要寫出乾淨的 javascript 程式碼可不簡單，即便是資深工程師也一樣。 乾淨的 JavaScript 程式碼該長怎樣？它應該要： - 易於閱讀 - 易於測試 - 高效和高性能 以下是您可以使用的優質工具和技巧，可將您的 Javascript 功力提升到全新水平： - 原文出處：https://dev.to/alexomeyer/8-must-know-tips-for-writing-clean-code-with-javascript-i4 # 1. 對所有 api 請求和 JSON 方法使用 try catch 發出 api 請求來撈資料時，許多事情都可能出錯，因此必須注意這些情況。在處理 JSON 時，不要自動信任拿到的資料格式，請試著處理可能出乎意料的格式，來讓您的程式碼更健壯。  # 2. 使用 linter (ESLint) linter 是一種靜態程式碼分析工具，可根據一組預定義的規則和配置檢查程式和風格錯誤。簡而言之，它將改進您的 Javascript/Typescript 程式碼品質，並讓風格更加一致。 # 3. 在編輯器中追蹤 Javascript issues 保持 Javascript 程式庫簡潔的一個重要方式，是能夠輕易追蹤和查看程式碼本身的問題。在編輯器中追蹤 issues 允許工程師： - 全面了解技術債等更大的問題 - 查看每問題的上下文 - 減少上下文前後查看的頻率 - 持續地處理技術債 您可以使用各種工具來追蹤您的技術債，但最快速、最簡單的入門方法是使用與 Jira、Linear、Asana 和其他專案管理工具整合的 VSCode 或 JetBrains 的免費 Stepsize 外掛。 # 4.使用模板字符串 模板字符串讓您在保留格式的同時將值注入字符串，並且程式碼比字串運算更容易閱讀。  # 5. 需要搜尋字串時，使用正規表示式 正規表示式雖然乍看之下很深奧，但它是非常強大的字串解析工具，允許您建立複雜的模式來解決各種困難的字串配對情境。 # 6. 使用可選串連運算子 停止使用冗長的邏輯運算子，使用可選串連運算子來簡化您的程式碼。  # 7.避免巢狀結構 巢狀結構絕對會增加程式碼的複雜度，也讓它更難閱讀、更難理解。如果深度超過兩層，請考慮重構，改成在根層就有條件回傳、使用更短小的區塊、並將巢狀邏輯抽像化成獨立的函式。 # 8. 替所有特殊程式碼寫註解，但不要讓它取代程式碼可讀性 有時需要針對特殊情境寫專門處理。替這段程式碼寫註解，解釋它的功能與上下文的由來，這對其他工程師幫助會很大。也能幫助未來重讀這段的自己。但讓程式碼本身就很易讀還是最優先，不要習慣用寫註解來偷懶！
在軟體產業工作超過十年之後，我總結出了二十條原則，跟大家分享如下： - 原文出處：https://dev.to/ondrejsevcik/20-principles-i-learned-from-10-years-of-developing-software-5354 1. **謙虛**——世界上沒有無所不知的工程師，你也一樣。 2. **先讓它能跑，再讓它正確**——可能的話，再讓它更快。 3. **修改時再優化**——寧可出現重複，也不要出現錯誤的抽象化設計。 4. **始終寫測試**——如果您不寫測試，那麼您就是在手動測試。 5. **解決 80% 的使用情境就好**——你永遠無法解決所有人的問題。 6. **盡量用函數式編程**——比較容易理解。如果您的程式碼需要博士學位才能看懂，那你的方法有點問題。 7. **刪除越多程式碼越好** 8. **足夠好勝於完美**——不要僅僅因為它不完美，就放棄有意義的改進。 9. **私下批評，公開表揚** 10. **做筆記**——如果你認為你會記住它，那你就是在自欺欺人。 11. **與您的用戶溝通**——最好的軟體是由對用戶有同理心的工程師開發的。 12. **有意識地學習**——練習時要牢記一個明確而具體的目標 - 你想要改進什麼以及如何改進（刻意練習）。 13. **不要過早概括**——等到你有至少 3 段重複的程式碼，再進行抽象化（又名：三規則）。 14. **修復破損的窗戶**——代碼中的一段技術債會導致另一段技術債。您的程式碼很快將變得難以管理。 15. **解決問題**——不管是誰的錯，都是你要負責解決。 16. **做有用的事，而不是時髦的事**——先和一個小團隊一起嘗試。如果可行，請擴大實施。如果不行，則中止。 17. **良好的休息才有最佳成果**——定期休息對於獲得最佳表現至關重要。你也不會認為專業短跑運動員一直在短跑吧。 18. **採取小步驟**——大的重寫是行不通的。您將在過程中失去動力和注意力。試著每天發布更新。它使您可以在必要時，自由地調整重點。 19. **表揚出色的工作**——我們在動物身上觀察到的這件事，同時也適用於人類。當你表揚人們的好表現而不是懲罰他們的壞表現時，你會得到更好的結果。 20. **完美的代碼不存在**——最好接受這事實，而不是浪費時間、追逐不可能的事情。
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
