🔍 搜尋結果:工程師

🔍 搜尋結果:工程師

初次轉職寫程式:作品集有用嗎?要做什麼作品?面試官會看嗎?

很多朋友轉職寫程式,在補習班或者線上課程,告一段落之後,開始找工作之前,會整理作品集 關於作品集,簡單給大家一些建議 ## 作品集有用嗎? 公司在徵人的時候,其實來應徵的人五花八門 滿多人看起來,根本不會寫程式,連最基本的小網頁或者小程式都寫不出來 連基本技能都沒有準備好,感覺是到處碰碰運氣、履歷亂誇大就到處丟。公司面試時,最怕遇到這種狀況 作品集,至少代表,你寫得出基本東西。很多人根本寫都不會寫,就去應徵了,作品集至少可以讓公司避免踩雷 話說回來,如果你的作品集,只是補習班的幾個分組專案,糊裡糊塗地完成了,就跟在學校敷衍交報告一樣,你對細節其實不了解,那這種作品集,當然幫助不大,對你的信心也沒有多少幫助 ## 要做什麼作品? 所以該做什麼作品呢? 最好做一些你真的需要的「應用程式」,寫起來才有動力、才好玩,內容也才扎實 簡單舉例,如果你在受訓的過程是這些: ### 前端工程師 做個待辦事項清單工具吧!按照自己的喜好設計,做完之後找地方上線 在找工作的這幾個星期,實際拿這個工具來做紀錄,投履歷時、面試時,很自然可以分享你的心得跟小熱情 對面試官來說,看到面試者有即戰力(即便是有一點點)、對自己的程式有熱情(即便只有一點點),都會加分不少 請參考 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 點子給初心者呢? 歡迎留言分享!

在台灣轉職程式設計師:給半路出家學習者的幾點建議

身邊很多朋友工作幾年之後,從非本科轉職寫程式 主要方法大概三種:報名實體課程、報名線上課程、買線上課程自學 ## 報名實體課程 資策會、程式補習班,都屬於此類 需要本人實際到教室,由老師上課 這種課程通常需要耗時數個月,費用會在新台幣十萬上下 好處是有同學一起、有同儕壓力、有問題可以當面問老師、厲害的老師可以現場掌握全班學習狀況 壞處是每個人學習速度不同,有人跟不上、有人覺得教太慢 這種學習法,需要碰運氣,如果遇到優秀的老師,學習氛圍、效果,都會非常好 但是,就我觀察課表,以「全端工程」為主打的課程,進度通常非常倉促,能真正消化的學生非常少數 多數人只是糊裡糊塗把功課、專案做完,畢業後其實還是很沒信心、一頭霧水 (只專注在特定領域開發的課程,狀況比較好一點) 主因是基礎知識還不夠熟,就開始大量學習工具用法 我建議這種狀況,不要對自己起太多懷疑,保持耐心,養成做紀錄的習慣 覺得一知半解的地方就把問題記錄一下,每天都整理出一些問題 整理出一張問題清單,找時間請教別人、或是上網慢慢研究 多數回答,聽完之後應該還是聽不懂,沒關係,先放著 有搞懂的問題就劃掉,一段時間之後,會更清楚程式設計整體觀念,也會更有信心 重點是要知道自己具體是哪些細節不了解、一知半解,才有補充&複習&研究的方向 ## 報名線上課程 坊間許多業者提供這類服務,會有大量教學影片,個人自己找時間看完即可 並且會幫大家分組、需要一起做專案、會有助教指導 好處是每個人可以自行抓節奏,並且費用便宜許多,通常不到實體課程四分之一 如果是組合式的課程商品,就更好了,可以先購買一些基礎課程,滿意才買更多 壞處是需要紀律,督促自己去學習,需要積極、主動一點 通常我是推薦朋友,去買這種課程,因為財務、時間風險,比實體課程小很多 真的找不到相關業者提供課程、有找到政府補助、有找到特別優秀的實體課程名師,才去找實體課程 ## 買線上課程自學 不分學期、沒有分組專案、沒有助教 基本上就是找一些影片自己來看 這種課程國外比較多,需要英文能力好 好處是費用非常便宜,通常幾百元~幾千元就有很不錯的內容 甚至有 freeCodeCamp 這種完全免費的課程 壞處是需要英文能力,並且很多只是小課程,不是完整的一套多課程規劃,會不確定自己的進度到哪了 如果有親戚朋友是業界軟體工程師,比較好,因為可以跟他請教、確認自身進度、以及確認自己求職條件如何 ## 結論 半路出家不容易,我鼓勵大家把學習想成是一個「逐漸清晰」的過程 看過電腦讀取大張高清圖片的樣子嗎?先是模模糊糊的馬賽克,接著一塊一塊慢慢變清晰,最後才是變成完整的美麗圖片 學習會有點類似這樣,一開始到處模模糊糊的沒關係,保持耐心,逐步提高各處的解析度即可 只要先有一整張模糊的圖片即可。不需要執著在圖片一個角落,覺得這塊不清楚,就不能往下走 更千萬不要因為圖片模糊,就覺得「我果然不適合寫程式,放棄好了」,這絕對是搞錯重點 以上,簡單建議分享,希望對你有幫助! --- 您在坊間補習班的學習經驗如何呢?歡迎在留言處跟大家分享您的個人學習經驗!

自學網頁の嬰兒教材:第3課 ── 網格系統:頁面分區塊排個版

# 第3課 課程目標 能夠用 Bootstrap 的網格系統做出多欄式排版、各種排版。 # 第3課 課程內容 業界工程師會去使用 Bootstrap,除了美感之外,通常還有一大理由就是想用它的網格系統。 以網頁設計常見的多欄式設計來說,手寫 html 跟 css 實在有點麻煩: [CSS DIV 兩欄式網頁排版](http://www.wibibi.com/info.php?tid=406) [CSS DIV 三欄式網頁排版設計](http://www.wibibi.com/info.php?tid=407) 所以來學習簡單好用的網格系統吧! 請閱讀以下教學的內容: https://www.w3schools.com/bootstrap5/bootstrap_grid_basic.php https://www.w3schools.com/bootstrap5/bootstrap_grid_system.php https://www.w3schools.com/bootstrap5/bootstrap_grid_examples.php https://getbootstrap.com/docs/5.3/layout/grid/ 內容不用全部讀完,也不用全部讀懂,把其中的程式碼貼一貼,把玩一下,能做出基本的多欄式網頁佈局即可。 # 第3課 作業 繼續承接之前的作業。我們在前幾課做出了 Yahoo 的新聞頁以及導覽列,這一課的作業有兩個。 ## 作業一 請繼續修改之前的作業,除了新聞內容與導覽列之外,請接著利用 Bootstrap 網格系統將整個頁面都做出來。 請至少將側邊推薦其他新聞的區塊做出來,其餘的可以省略。 ## 作業二 請再開一份 Glitch 專案,我們要做 Yahoo 新聞的首頁: https://tw.news.yahoo.com 我們要用 Yahoo 新聞首頁來練習多欄式排版。 請利用 Bootstrap 網格系統,將整個首頁的排版都切出來。 各個區塊的內容盡量省略、簡化,利用純文字或是 `<ul>、<li>` 清單元素,只放標題跟一些文字即可。 完成以上兩份作業,你就完成這次的課程目標了!

15 年開發經驗分享:從新手到中階工程師的心得

我的自學開發之旅始於大約 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/) 在團隊中組織問題和拉取請求的好工具。 ## 結論 🎉 希望您覺得這個列表有用。

新手不用急著學 TypeScript,不如先把 JavaScript 學熟練

> 為什麼有些 JavaScript 工程師沒在用 TypeScript 呢?原因有哪些? 我在推特問大家:為什麼你還沒用 TypeScript? ![](https://res.cloudinary.com/practicaldev/image/fetch/s--By6b0ozU--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3uto8rrbud9yv303gs5b.png) 這篇文章簡單整理大家的答案。 原文出處:https://dev.to/codewithvoid/ive-got-99-problems-but-learning-typescript-aint-one-o70 讓我們開始吧。 ## 先征服 JavaScript 👨‍🏫️ 很多新手和初學者給出了“我還在學習 JS”的原因。 可以理解,他們現在不想承擔超過他們可以吸收的東西。 他們中的大多數人有興趣在未來嘗試一下,而有些人則在尋求指導,看看是否應該這樣做。 ## 純 JavaScript 就很夠用 👌 已經在使用 JS 的開發人員有一個問題 → “為什麼需要?”。 他們不打算遷移過去,因為有一個用 JavaScript 編寫的大型程式庫、易於調試,或者僅僅是因為他們對 JS 感到滿意,因為它可以完成工作。 他們的座右銘是:“如果夠用,就不要碰它”。 ## 對不起,晚點再考慮🕒 一些有經驗的 JS 開發人員已經計劃學習 TypeScript,但認為合適的時機還沒有到來。 與不願意遷移的開發人員不同,這些開發人員看到了 TypeScript 的價值。只是他們還沒有找到合適的專案,這證明了學習曲線的確存在。 此外,他們希望工具(如支持在瀏覽器中本地運行 TS 程式碼)在未來得到改進。 ## 要看情況使用🧐 一些開發人員花時間學習了 TypeScript,但並沒有在每個專案中都使用。 根據他們的說法,主要原因是: - 需要跟團隊一起 - 應用程式已上線 - 程式庫太龐大 他們說“對於個人專案和簡單的應用程序,TypeScript 是一種矯枉過正”。 ## ECMA 即將到來🏁 最後,一些回應是關於 ECMA 6 已經支持足夠的現代性,可在 JS 中編寫乾淨的代碼。 這些開發人員建議,如果你足夠了解 JavaScript 並使用圍繞它構建的工具,你就不需要 TypeScript。 此外,他們希望 TypeScript 中的有用功能最終會包含在原生 JavaScript 中,所以為什麼要費心研究 2 個學習曲線。 ## 總結📝 您對 TypeScript 的心得是什麼?歡迎在留言處分享。

德國資深架構師:給新手工程師的幾點建議

一名資深的德國軟體架構師 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 在命名和寫註解方面有提供一些很好的經驗法則。 --- 以上,希望對大家有幫助!

在 React 中使用 Design Patterns:以 Strategy Pattern 舉例

在 React 前端開發時,常常會需要在不同的元件、hook、utils 中寫一些邏輯。 有些時候,使用策略模式會很有幫助,這篇文章給您參考。 - 原文出處:https://dev.to/itshugo/applying-design-patterns-in-react-strategy-pattern-enn ## 出問題了:霰彈槍手術(Shotgun Surgery) Shotgun Surgery 是一種程式寫很爛的信號。想對程式規格做一點小修改,需要改一大堆地方。 ![](https://refactoring.guru/images/refactoring/content/smells/shotgun-surgery-01-2x.png) 在專案中通常如何發生?假設我們需要為產品寫一個報價卡片,我們根據客戶所在國家,調整價格、貨幣、折扣方式和文字說明: ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5iz9oso7ozaqm0qibd76.png) 大多數工程師可能會這樣寫: - 元件:`PricingCard`、`PricingHeader`、`PricingBody`。 - Utility functions:`getDiscountMessage`(在 **utils/discount.ts** 中),`formatPriceByCurrency`(在 **utils/price.ts** 中)。 - `PricingBody` 元件會計算最終價格。 完整程式碼範例:https://codesandbox.io/s/react-strategy-pattern-problem-h59r02?from-embed 現在假設我們需要更改一個國家/地區的定價計劃,或為另一個國家/地區添加新的定價計劃。您將如何處理這段修改?您必須至少修改 3 個地方,並向已經滿亂的 `if-else` 區塊添加更多條件: - 修改 `PricingBody` 組件。 - 修改 `getDiscountMessage` 函數。 - 修改 `formatPriceByCurrency` 函數。 如果您聽說過 S.O.L.I.D 原則,我們已經違反了前 2 條原則:單一職責原則和開閉原則。 ## 解決方法:策略模式 策略模式非常簡單。我們可以簡單的理解為,每個國家的定價方案都是一個策略。在那個策略類別中,會實現該策略的所有相關邏輯。 假設您熟悉 OOP,我們可以有一個實現共享/公共邏輯的抽像類別(`PriceStrategy`),然後具有不同邏輯的策略將繼承該抽像類別。 `PriceStrategy` 抽像類別如下所示: ``` import { Country, Currency } from '../../types'; abstract class PriceStrategy { protected country: Country = Country.AMERICA; protected currency: Currency = Currency.USD; protected discountRatio = 0; getCountry(): Country { return this.country; } formatPrice(price: number): string { return [this.currency, price.toLocaleString()].join(''); } getDiscountAmount(price: number): number { return price * this.discountRatio; } getFinalPrice(price: number): number { return price - this.getDiscountAmount(price); } shouldDiscount(): boolean { return this.discountRatio > 0; } getDiscountMessage(price: number): string { const formattedDiscountAmount = this.formatPrice( this.getDiscountAmount(price) ); return `It's lucky that you come from ${this.country}, because we're running a program that discounts the price by ${formattedDiscountAmount}.`; } } export default PriceStrategy; ``` 我們只需將實例化的策略作為 prop 傳遞給 PricingCard 元件: ``` <PricingCard price={7669} strategy={new JapanPriceStrategy()} /> ``` `PricingCard` 的 props 定義為: ``` interface PricingCardProps { price: number; strategy: PriceStrategy; } ``` 同樣,如果您了解 OOP,那麼我們不僅在使用繼承,而且還在此處使用多態性(Polymorphism)。 完整程式碼範例:https://codesandbox.io/s/react-strategy-pattern-solution-mm0cvm?from-embed 使用這個解決方案,我們只需要添加一個新的策略類別,而不需要修改任何現有程式碼。這樣,我們也滿足了 S.O.L.I.D 原則。 ## 結論 因為我們在 React 程式碼中檢測到程式碼發臭:Shotgun Surgery,所以我們使用了策略模式來解決它。 ### Before ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7wn31uolfo6xfy3mh8fo.png) ### After ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xheeb2splcwj2kkqwsfo.png) 現在邏輯都存在一個地方,不再分佈在許多地方。 --- 以上是 Strategy Pattern 的簡單說明,希望對您有幫助。

簡單介紹一下 NextJS 框架

Next.js 是一個開源、輕量的 JavaScript 框架。它讓您能用 React 開發高速又好用的 Web 應用程式與靜態網站。 這篇文章簡單介紹一下這個框架! - 原文出處:https://dev.to/documatic/why-use-nextjs-mn3 # 簡介 Next.js 是用來建造 server-side rendering 的 web 應用程式的 ReactJS 框架。包含很多現成功能,例如程式碼自動拆分、基於檔案的路由、hot reloading 和通用渲染。 https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0oqlfzpvx0rkns65juxt.png Next.js 會在 React 之外處理好工具、設定,並額外提供架構、功能、與效能優化。 Next.js 由 Vercel 的軟體工程師 Guillermo Rauch 打造,並由 Vercel 的開發團隊維護。它是一個開源專案,可以在 GitHub 上找到程式碼。 # Next.js 是做什麼用的? Next.JS 常用來建造以下類型的網站: - 電子商務網站 - 部落格 - 投資組合網站 - 文件網站 - 行銷網站等等 # Next.js 和 React.js 的區別 Next.js 和 React 都是建造 Web 應用程式的常用工具。但是,它們之間有明顯差異,適用不同場景。以下分別討論幾點: # 效能 性能是 Next.js 和 React.js 之間的主要區別。 Next.js 內建許多效能優化,例如圖像優化。這些優化使 Next.js 網站跑起來非常快。 另一方面,ReactJS 是在客戶端渲染,對於高性能應用程式來說,就不太夠力。 # SEO 靜態網站比較適合 SEO 優化,使用 Next.js 很容易做出靜態網站。SEO 越好,在搜尋結果越前面。 而 React 因為是渲染 singe page application,對 SEO 來說就比較吃虧。 # Server-side rendering Next.js 提供伺服器端渲染功能 (SSR)。當您需要為不同用戶提供不同渲染方式,它可以撈資料然後回應不同請求。 雖然可以啟用,但 React 預設不支援伺服器端渲染。SSR 可以與一些伺服器軟體整合,但需要一些額外作業。 # 開發者社群 React 社群很活躍、資源很多。 Next.js 大部份討論都在 GitHub 上面。 React.JS 和 Next.JS 都有很好的開發者體驗。 # 設定檔 使用 Create React App 的話,記得要跳出來才能獨立設定各項設定檔。 使用 Next.js 的話,可以在 Next.js 模板直接自訂 `babelrc`、`jest.config` 和 `eslintrc` 等文件。 # 結論 簡單介紹一下 Next.js ,希望對您有幫助!

在 JavaScript 新版 ES2020 之中,值得留意的 10 個新功能

ES2020 已經上線一段時間了,但是滿多新功能都大家不太知道。這篇文章跟大家介紹一下! - 原文出處:https://dev.to/worldindev/10-new-javascript-features-in-es2020-that-you-should-know-3ohf # 1. BigInt BigInt 是最受期待的新功能之一,允許工程師處理資料時,能存一個更大的整數。 目前在 JavaScript 中可以儲存的最大整數是 `pow(2, 53) - 1`。BigInt 讓你可以存更大的數字。 ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/588khrk3rpei76gho4e9.png) 如上所示,需要在後面加上一個 `n`。這個 `n` 表示這是一個 BigInt ,讓 JavaScript 引擎(v8 引擎)能夠特別處理。 這個功能不向後兼容,因為傳統的數字系統是 IEEE754(不能支援這種大小的數字)。 # 2.Dynamic import 動態導入讓你可在程式碼中,有條件地動態導入模組。跟你現在用 Webpack 和 Babel 做的事一樣。 此功能讓你可以按需求讀取程式碼,也就是所謂的 code splitting。讓你不再需要 webpack 或其他模組打包工具就能做到。您還可以在 if-else 中有條件地載入程式碼。這有個額外好處,就是不會污染全域命名空間。 ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/utai4m6xcc1nk3aooqxf.png) # 3. Nullish Coalescing Nullish Coalescing 可以確實檢查 nullish 而不是 falsy 值。什麼是 nullish 與 falsy 值? 在 JavaScript 中,許多值都是 `falsy`,例如空字串、數字 0、`undefined`、`null`、`false`、`NaN` 等等。 但有時候你想要檢查 undefined 跟 null。這種情況下,就可以用新的運算子 `??` ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uupnryjugtdtb6xvv7yk.png) 如圖, **OR** 運算子始終回傳 truthy 值,而 ?? 運算子回傳 non-nullish 值。 # 4. Optional Chaining Optional Chaining 語法讓你可以取得深度嵌套的物件屬性,而不用擔心屬性不存在。如果找不到屬性,會回傳 undefined,而不會報錯壞掉。物件屬性可用,呼叫函數跟陣列也可以用。超方便!請參考: ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r4w5zkv64r0cs46xpjie.png) # 5. Promise.allSettled `Promise.allSettled` 方法接受一個 Promise 陣列,並且只有在所有 Promise 都完成時才 resolve 或 reject。 以前只能用 `race` 和 `all` 做出類似效果。 ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6xi1hpkcazxgxsl81d90.png) # 6. String#matchAll `matchAll` 是添加到 `String` 原型的新方法,與正則表達式相關。這將回傳一個迭代器,該迭代器依次返回所有匹配的組。舉例: ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nmmk478r36d1bfjovi1v.png) # 7. globalThis 如果你是寫跨平台的 JS 程式碼,可以在 Node 上運行、在瀏覽器運行、也可以在 web-workers 中運行,你很難操作全域物件。 因為對於瀏覽器來說它是 window ,對於 Node 來說是 global ,對於 web-workers 來說是 self。如果有其它的運行環境,它們的全局物件也都不同。 變成你需要自己寫一段來檢測環境。所以 ES2020 實作了 globalThis,無論您在哪裡執行,它始終引用全域物件: ![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u5dczfi8moefwl4y1jo6.png) # 8. 模組命名空間匯出 在 JavaScript 模組中,可以使用以下語法: ``` import * as utils from './utils.mjs' ``` ES2020 新增了相對的匯出語法: ``` export * as utils from './utils.mjs' ``` 這等同於以下內容: ``` import * as utils from './utils.mjs' export { utils } ``` # 9. 定義好 for-in 順序 雖然大部份瀏覽器都實做了一樣的順序,但 ECMA 規範其實沒有指定 for (x in y) 的運行順序。在 ES2020 中正式標準化了。 # 10. import.meta `import.meta` 物件帶有一個 `null` 原型。 考慮以下模組,`module.js`: ``` <script type="module" src="module.js"></script> ``` 您可以使用 import.meta 物件取得有關模組的元信息: ``` console.log(import.meta); // { url: "file:///home/user/module.js" } ``` 對於 external scripts,它代表存取腳本的 URL,對於 inline scripts,它代表檔案的 URL。 --- 以上簡單分享,希望對你有幫助!

軟體工程師:面試的時候,你應該問公司的 36 個重要問題

面試的時候,通常面試官會問:你有什麼問題想問我們嗎? 就跟公司面試你一樣,其實你也在面試公司。應該把握機會問對問題。 這邊有幾個重要問題,給你參考,下次面試可以問問看。 - 原文出處: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 是開發人員互相分享的寶庫。可以在上面找到任何與軟體工程有關的東西。就跟一般礦山一樣,要懂得採礦,才能得到有價值的礦物。 我一直在尋找 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 --- 以上,歡迎有空逛逛這些資源,祝您不斷變強。

7個超特別的工程師作品集網頁:讓您大開眼界

工程師要怎麼設計作品集網頁呢?來看看這些人的網頁,或許能給你一些靈感! - 原文出處:https://dev.to/ruppysuppy/7-developer-portfolio-for-inspiration-4no7 # 1. Bruno Simon 如果您有試過開發 3D 網站,那你一定聽過 Bruno Simon。他是 Three.js Journey 的作者。從他的作品集就可看出為什麼他是這個領域的高手。 他的作品集網站,本身就是一個電玩遊戲。你可以在裡面控制吉普車,在 3D 世界裡面開車,然後可在裡面探索他的作品集世界。這網站可說是作品集網站的巔峰之作。 https://bruno-simon.com/ ![](https://imgur.com/kqpLGNH.png) # 2. Robby Leonardi 另一個超厲害的作品集網站!Robby Leonardi 的作品集是一個互動式的履歷表,往下滑就可以瀏覽他的作品、看到更多個人資訊。 http://www.rleonardi.com/interactive-resume/ ![](https://imgur.com/tZ6QJcX.png) # 3. Nitin Ranganath 一個有創意、又很新潮的網站!整個作品集頁面,看起來就像是 VS Code 編輯器! https://vscode-portfolio.vercel.app/ ![](https://imgur.com/4ePEkBe.png) # 4. Dejan Markovic 與傳統網頁設計的風格大相徑庭,但實際操作起來,卻非常順暢、巧妙! https://www.dejan.works/ ![](https://imgur.com/w0jf0i6.png) # 5. Hype4 極簡主義風格的網站,具有超級簡潔、專業的設計感。 https://hype4.com/ ![](https://imgur.com/FhT8j3c.png) # 6. Jacek Jeznach 利用微互動來提高留存率的絕佳範例。雖然網站上的廣告很煩人,但對於互動細節的設計,值得您親自見識一下! https://jacekjeznach.com/ ![](https://imgur.com/NR7v2KV.png) # 7. Tapajyoti Bose 最後一個範例讓我老王賣瓜一下!😜 我做了一個帶有滾動特效的單頁式作品集網站! https://tapajyoti-bose.vercel.app/ ![](https://imgur.com/GpmgsPC.png) --- 以上,希望大家覺得有趣、有啓發性!

軟體工程師必看:20個提高生產力的簡單方法!

每個人都想提高生產力,但該如何提高呢?此文章整理20種簡單、我親自試過、且有效的方法!希望對大家有幫助! - 原文出處:https://dev.to/code_jedi/20-easy-ways-to-be-more-productive-as-a-developer-5f99 # 1. 時間箱子 將您的時間當成多個箱子安排,例如: ``` 9:30 --> 10:00 回電子郵件 10:00 --> 12:00 處理新登錄頁面的設計與功能 12:00 --> 13:00 午餐和休息 13:00 --> 15:00 編輯文件 15:00 --> 17:30 動手重新設計登陸頁 ``` # 2. 深度工作 深度工作是一種強調進入狀態來提高工作效率的方法。這方法希望你嘗試長時間(2 到 3 小時)不被打斷地工作,讓你進入一種心流狀態。然後,當你處於那種狀態時,就不太會被中斷、就不會在工作上又拖拖拉拉的。 # 3. 80/20 法則 80/20 法則也稱為柏拉圖法則,它鼓勵您專注在最高價值的工作。這法則認為您 80% 的產出往往來自您 20% 的努力。這方法的重點在於要認出哪些任務最重要、能夠提供最大的回報。重點在於將心力花在「正確的任務」上,而不要浪費時間在次要細節上。 # 4. 三的法則 對於那些常常寫下一堆待辦事項,卻沒完成幾件的人來說,這法則會很有幫助。您需要找出最重要、有意義的三件事情。要列出的不是任務本身,而是明確的結果。比方說「部署 AWS 應用程式」。每天都安排三件明確、有意義的事情,就可以不斷提醒自己,什麼是最重要的、最需要關心的。這個小技巧的效果非常巨大。 # 5. 做點小事情 我們都有那種感覺整天什麼都做不了的經驗。覺得沒有任何動機與精力、好像做什麼都沒力氣。發生這種情況時,最好的辦法就是做點小事情。在房子/公寓周圍做一些家事,寫一些程式碼(未必要與您的工作/專案相關),寫一篇部落格文章。光是做一些小事情,通常就足以將您拉回正軌! # 6. 硬著頭皮開始 想想看你拖延了很久的事情。可能是一個困難的專案,或者是學一些很困難的東西。別再猶豫了,硬著頭皮開始吧。可能會犯一些錯或者看半天看不懂,但只要有了起步,之後一定會慢慢適應的! # 7. 不要重複做工(Don’t Repeat Yourself 原則) 重複使用已經做過的東西(簡稱 DRY 原則),可以節省不少時間。重複做工是很低效且沒必要的。DRY 原則鼓勵您建立工作流程與模板,盡量減少重複做工。程式碼、電子郵件、部落格文章,都可以適用。 # 7. 不要重複做工 開玩笑的哈哈😄 # 8. 兩分鐘法則 如果待辦事項中有兩分鐘內可以完成的任務,就應該立刻去完成再說。這法則讓您可以克服拖延的習慣。如果有一封該回的郵件放著會讓你心煩意亂,但回起來只要兩分鐘的話,那就立刻先回覆。這會讓你覺得有進度,反過來又會激勵自己、增強動力。此外,它還可以幫助您理清思緒,讓您不必再為那些待辦小任務煩惱。 # 9. 單工 多工(一次忙很多事)會降低生產力。單工是鼓勵您一次專注一件事。如此一來,您將花費更少的時間和精力在任務之間來回切換。 # 10. 必須、應該、想要 在一天開工之前,根據以下標準整理一份清單: ``` 我必須 ... 我需要 ... 我想要 ... ``` 這將幫助您確定優先順序與當天的目標。 # 11. 艾森豪矩陣 名字聽起來很花俏,但這方法只是列出所有待辦任務,然後分成四種類別而已。 這四個類別是: ``` 緊急而重要的任務 重要但不緊急的任務 緊急但不重要的任務 不緊急也不重要的任務 ``` 這能幫助您根據類別來安排時間優先順序。 # 12. 生物黃金時間 在一天當中,觀察、發覺您的自然能量水平。 請花幾週時間,記錄您一整天的精力充沛程度。 對於一天中的每個小時,給它一個 1-10 之間的等級(10 是最高能量)。根據結果 - 相應地規劃您的一天作息。如果您在早上精力充沛 – 就在早上做您最需要做的事情。 如果您下午的精力不足 – 將比較不花心力的任務留到下午吧。像是寫電子郵件或寫部落格文章之類的。 # 13. 每週回顧 每週一次,找一個安靜的地方坐坐,在那裡思考和反省一下。如果您想動手紀錄,也可以使用筆記本和筆。 回顧過去一周的工作效率、精力水平、哪些事情對您有用,哪些事情沒有用。 例如: - 早上洗個冷水澡對我的工作效率有幫助。 - 早上吃得太少讓我在接下來的幾個小時裡感覺沒力氣。 除了思考這一周過得如何,您還需要查看您做出了哪些決定以及您想要更改哪些決定。可以想想改善的方法,或者想想哪些事情沒做到。 # 14. 番茄鐘 這可能是最知名的生產力方法了。番茄工作法就是: - 工作 20-30 分鐘 - 休息 5-10 分鐘 - 重複以上 這種方法剛好與深度工作法相反。所以如果深度工作方法對你有用,就不要理會這個,反之亦然。 # 15. 非待辦清單 許多提高效率的方法都會鼓勵您列出某種待辦事項清單。但是,不要做的事情,也可以寫成列表,而且也很有用! 每天開工前,列一個不要做的清單。此列表包含您希望避免做的無用事情,例如使用社群網站、邊上班邊跟朋友聊天、收聽分散您注意力的播客。 如此一來,您就會清楚知道一天中要避免做的無用事情。 # 16. 今天就組織明天 睡覺前組織和計劃明天的任務。如此一來,您就可以在第二天毫不猶豫、也不用計劃就開始這些任務。 # 17. 檢查表清單 對於每件做過多次的事情、或者想完成的複雜任務,創建一個詳細的檢查表清單,列出你需要做什麼才能正確完成它。 例如: ``` 寫部落格文章 * 寫提綱 * 寫下大概的內容 * 審查和編輯 * 讀過一遍 * 最終檢查和編輯 * 發布 ``` # 18. 不要打斷連續工作日數 這方法希望您能在一段時間內,每天固定有一些進度。每天完成之後,就在日曆標記已完成。像是寫部落格文章、學習新東西、或閱讀30分鐘的書。 做出承諾的前幾天通常是最難的,但渴望改變的心將幫助您度過難關。 隨著連續日數變長,希望連續記錄不被打破,本身就會激勵你繼續前進。 # 19. SMART目標法 SMART 是一個目標設定公式,鼓勵你對於目標盡可能詳細和具體。SMART代表特定的(Specific)、可衡量的(Measurable)、可分配的(Assignable)、實際的(Realistic)、與時間相關的(Time-related)。這意味著當你設定一個目標時,它應該被清楚定義。 包括:你想要達到的目標是什麼、如何衡量成功、誰負責、有基礎、可行、需要在什麼時間範圍內實現。 # 20. 充電法 當你覺得自己累了,不能再工作時,不要逼迫自己,承認你需要休息,然後休息一下。當你精神疲憊時,休息一下通常比逼迫自己更好,原因有 3 個: 1. 你會少犯錯誤 2. 你會減輕壓力 3. 你的頭腦會更清晰 # 結論 希望這些方法,對您有幫助!

寫出優雅 JavaScript 程式碼的 8 個簡單技巧

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 時,不要自動信任拿到的資料格式,請試著處理可能出乎意料的格式,來讓您的程式碼更健壯。 ![](https://imgur.com/KVzrdd0.png) # 2. 使用 linter (ESLint) linter 是一種靜態程式碼分析工具,可根據一組預定義的規則和配置檢查程式和風格錯誤。簡而言之,它將改進您的 Javascript/Typescript 程式碼品質,並讓風格更加一致。 # 3. 在編輯器中​追蹤 Javascript issues 保持 Javascript 程式庫簡潔的一個重要方式,是能夠輕易追蹤和查看程式碼本身的問題。在編輯器中追蹤 issues 允許工程師: - 全面了解技術債等更大的問題 - 查看每問題的上下文 - 減少上下文前後查看的頻率 - 持續地處理技術債 您可以使用各種工具來追蹤您的技術債,但最快速、最簡單的入門方法是使用與 Jira、Linear、Asana 和其他專案管理工具整合的 VSCode 或 JetBrains 的免費 Stepsize 外掛。 # 4.使用模板字符串 模板字符串讓您在保留格式的同時將值注入字符串,並且程式碼比字串運算更容易閱讀。 ![](https://imgur.com/ccagbwx.png) # 5. 需要搜尋字串時,使用正規表示式 正規表示式雖然乍看之下很深奧,但它是非常強大的字串解析工具,允許您建立複雜的模式來解決各種困難的字串配對情境。 # 6. 使用可選串連運算子 停止使用冗長的邏輯運算子,使用可選串連運算子來簡化您的程式碼。 ![](https://imgur.com/4TtpBdm.png) # 7.避免巢狀結構 巢狀結構絕對會增加程式碼的複雜度,也讓它更難閱讀、更難理解。如果深度超過兩層,請考慮重構,改成在根層就有條件回傳、使用更短小的區塊、並將巢狀邏輯抽像化成獨立的函式。 # 8. 替所有特殊程式碼寫註解,但不要讓它取代程式碼可讀性 有時需要針對特殊情境寫專門處理。替這段程式碼寫註解,解釋它的功能與上下文的由來,這對其他工程師幫助會很大。也能幫助未來重讀這段的自己。但讓程式碼本身就很易讀還是最優先,不要習慣用寫註解來偷懶!

資深軟體工程師:10年經驗教會我的20件事情!

在軟體產業工作超過十年之後,我總結出了二十條原則,跟大家分享如下: - 原文出處: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. **完美的代碼不存在**——最好接受這事實,而不是浪費時間、追逐不可能的事情。

給工程師的12個超好用API、可串接大量有趣資料~!

不管是寫程式的新手、老手,在做專案的時候,常常需要資料,來讓專案內容更豐富吧! 這時候需要去找有趣、夠酷、免費的 API 來用! 這篇文章一次整理出 12 個有豐富資料的有趣 API!有空要用用看喔! - 原文出處:https://dev.to/monicafidalgo/12-apis-that-you-as-a-developer-will-love-it-4ec6 # ✨1. PokéAPI 來串寶可夢精靈 API 吧!可以撈到大量神奇寶貝資訊(動作、類型、能力)! - https://pokeapi.co/ - 需要 API 密鑰:否 # ✨2. GIPHY GIPHY 是世界上最大的 GIF 資料庫,可以撈到一大堆梗圖,方便你開發有趣的 side project! - https://developers.giphy.com/ - 需要 API 密鑰:是 # ✨3. Open Weather 串接這個API,馬上得知明天天氣!Open Weather API 收集和處理來自不同來源的天氣數據,例如全球和本地天氣模型、衛星、雷達、各種氣象站資訊! - https://openweathermap.org/api - 需要 API 密鑰:否 # ✨4. {JSON} Placeholder 快速撈一些 json 假資料,方便開發時有資料可以快速測試! - https://jsonplaceholder.typicode.com/ - 需要 API 密鑰:否 # ✨5. SWAPI 電影「星際大戰」API,擁有大量行星、宇宙飛船、車輛、電影和物種的數據~! - https://swapi.dev/ - 需要 API 密鑰:否 # ✨6. NASA NASA 就是美國國家航空暨太空總署,提供大量來自 NASA 的真實數據,包括 NASA 好奇號、機遇號和精神號探測器在火星上收集的圖像數據! - https://api.nasa.gov/ - 需要 API 密鑰:是 # ✨7. Unsplash 由大量攝影師上傳照片的優質圖片資料庫!開發網站首頁、串接漂亮照片的必備 API 網站! - https://unsplash.com/developers - 需要 API 密鑰:是 # ✨8. Dev.to dev.to 是國外一個開發者討論區,在上面寫文章的話,可以透過 API 把文章撈出來! - https://developers.forem.com/api - 需要 API 密鑰:否 # ✨9. Breaking Bad Netflix 神劇,《絕命毒師》的的 API。它可以讓你拿到劇中名言、人物、集數、各式死亡資訊! - https://breakingbadapi.com/documentation - 需要 API 密鑰:否 # ✨10. Random Data 想發揮創意並在專案中使用各種奇怪資料嗎?也許是一款隨機獲得啤酒或電腦的遊戲?試試看隨機資料 API 吧~! - https://random-data-api.com/documentation - 需要 API 密鑰:否 # ✨11. Rest Countries Rest Countries 讓您可以通過 RESTful API 拿到有關各個國家/地區的大量豐富資訊~! - https://restcountries.com/#rest-countries - 需要 API 密鑰:否 # ✨12. Rick and Morty Rick and Morty 系列很受工程師歡迎!這個 API 可以讓你按劇集、角色、地點進行查詢~! - https://rickandmortyapi.com/documentation - 需要 API 密鑰:否