昨天在我們新手寫程式 LINE 群組，有幾個工程師＆想轉職的新手在討論： > 各位前輩們好，小弟是自學轉職的前端工程師，目前有兩個 offer，一個是接案公司；一個是自有產品，自有產品的那間目前只有一個junior前端，進去有問題可能沒人可以問，但看網路上好像都不太推接案公司。猶豫了很久選不出來想聽聽各位前輩的看法。 https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情，跟大家分享 --- 阿川幫大家從幾個角度來分析比較一下 # 學習的深度、廣度 接案公司通常是使用類似的技術，接不同的客戶專案 好處是可以接觸很多不同的客戶，認識許多不同產業 壞處是做久了可能會開始有「重複感」，也就是好像一直在做類似的事情，有點學不到東西 產品公司通常是長期深入研發自家產品、技術 所以會在同一領域鑽研，通常可以玩得比較深入、學得比較深入 壞處是可能長期只能使用同一技術、框架，沒機會玩別款的 接案公司有時需要面對不同技術需求的客戶，有機會玩玩不同款的語言、框架、技術 # 工作的時程壓力 接案公司的時程壓力來自於「客戶」，通常已經由老闆、PM 跟對方承諾某個時間，甚至已經寫在合約上 如果同時在開發多個專案的話，有時候工程師會感到相當的壓力 通常是忙一陣、閒一陣這樣 產品公司沒有這樣的壓力，壓力通常來自於「公司沒有在賺錢」 如果公司經營穩定、產品前景看好、主管有肩膀好說話 那像這樣的時程壓力，通常會小很多 # 技術債 稍微資深的工程師，在不同公司面試時，一定會問的問題是：入職之後，需要維護 legacy（老舊）專案嗎？ 維護老舊專案、負擔技術債，是一件很悲慘的事情，也是開發者的主要離職原因之一 你會被迫用已經過時的工具、語法在開發，並且要把設計拙劣的系統架構「硬搬進自己腦子裡」才能消化開發 這過程能學到東西嗎？我認為不多，基本上是在糟蹋生命 接案公司來說，如果主要負責一些新客戶，那麼經常在重啟新專案，技術債問題或許不大 如果手上負責很多「超舊的專案與客戶」，那麼可能會遇到技術債的問題 自有產品的公司，則是走向另一個極端 如果是持續有在更新版本、升級套件的熱情公司，那麼技術債問題不大 如果是有年紀、穩定的系統，那麼版本問題、系統架構的技術債問題，可能很大 嚴重起來會比接案公司更慘，因為就只有一個專案在跑 # 進去有問題可能沒人可以問 大家都希望團隊能有一個又強、人又好、又願意幫忙自己的好同事 不過這可遇不可求，身為正職工程師，你需要能夠獨立解決問題 畢竟人家也面試過了，應該就是合格了，如果真的丟一些無法解決的問題給你，那也不全是你的錯 另一方面，沒人可以問，代表你獨立做決定的空間很大，這未必是壞事 # 結論 剛轉職的新手上班，我是覺得去接案公司上班也可以 通常接案公司很缺人，也比較願意給半路出家者機會 而且開始工作的前 1-2 年，不管去什麼公司，通常都能學到很多東西 待了 2-3 年之後，覺得無聊了，再找新工作也不遲 所以回到原 po 的問題：我認為兩間公司都可以，沒有說接案公司一定比較不好 畢竟，就算是自有產品的公司，如果產品本身超爛，根本永遠不會賺錢、沒人想用 那就只是一大群人在「陪老闆追逐他的個人夢想」，那其實也是相當浪費時間的，不如在接案公司專心滿足客戶，比較充實 --- 我建議閣下不妨從「人和」的角度來觀察一下：你喜歡面試時看到的那些人嗎？ 老闆、主管、同事，你喜歡跟他們相處嗎？還是你有點畏懼他們、覺得他們有點冷漠、城府、可怕？ 如果實在不知怎麼選，就選你喜歡的那群人吧！跟合得來的人一起工作，總是不會太不舒服！ 以上，簡單分享，給各位參考！也歡迎大家多多在留言區補充經驗、意見！
工作了很多年，還是搞不太懂 promise、async/await 是什麼嗎？用這份作業包一次搞定觀念！ https://codelove.tw/@howtomakeaturn/course/Pam6qL @hung @birdie2019 @superyngo 找時間來寫寫看～
## 課程目標 - 認識 async/await 語法 ## 課程內容 體驗過 promise 之後，你會發現雖然改善很多，但還是有一點點麻煩 因為你需要 `.then()` 還有 `return`，而且，還是有一層巢狀結構 因此，工程師在 ES2017 又提出了一個解決辦法，叫做 async/await 因為 async/await 只是 promise 的另一種語法，背後一模一樣，所以繼續拿 jquery 當範例看看 原本的串接 ``` $.get(url, params).then((data) => { // do something with data to get params2 return $.get(url2, params2); }).then((data) => { // do something with data to get params3 return $.get(url3, params3); }).then((data) => { // do the final task with data }); ``` 可以用 async/await 改寫成 ``` const data1 = await $.get(url, params); // do something with data to get params2 const data2 = await $.get(url2, params2); // do something with data to get params3 const data3 = await $.get(url3, params3); // do the final task with data ``` 神奇吧？看起來跟一般的同步程式設計，幾乎一模一樣了！ 這邊要知道的是，await 後面的內容，其實就是 `.then()` 裡面 `return` 回傳的內容 只是寫法不同，其實背後是完全一樣的東西！ --- 這句話很重要，再看一次！未來只要有點迷惘，就用這句話再思考一次： 你每次只要看到 await，就要去想「現在是去剝開 promise 的 then 裡面，拿出最後回傳的內容！」 有點看不懂沒關係，就先跟著使用方式，照做即可！ 工作上多用幾次之後，會逐漸抓到感覺！ 就先跟著作業，試著使用看看 async/await 吧！ --- 你可能會問：那 `async` 是什麼時候用？ 在 JS 環境中，有些時候，可以直接寫 `await` 有些時候，會跳警告，要求必須要使用 `async` 關鍵字包裝過，才能使用 `await` 僅此而已，暫時分不清 `async` 關鍵字使用時機，沒關係，遇到警告錯誤，再補上就可以了 最簡單的做法，你就把整段程式碼，放進一個隨便命名的 `main` 函式裡面，加上 `async` 關鍵字，然後執行 main ``` const main = async () => { // move your code to here } main(); ``` 老話一句，工作上多用幾次之後，會逐漸抓到感覺！ ## 課後作業 在前一課的作業中，你稍微體驗到 2015 年代，前端工程師使用的「Promise Chain 鏈接」寫法 在這一課的作業，我們將時間快轉到 2017 年代，體驗一下所謂 `async/await` 是什麼 --- jquery 有支援 promise 介面，所以當然可以直接用 async/await 原本的 `.then()` 寫法 ``` $.get(url, params).then(callback) ``` 可以改寫為 ``` const data = await $.get(url, params) ``` 請將上一課的作業，使用 async/await 改寫 寫完之後，你應該會看到多個 await 出現，並且整段程式碼看起來很像「一般程式語言中，同步程式設計」的寫法！ 而且，完全沒有 callback function 的傳遞！ 做出以上功能，你就完成這次的課程目標了！ ### ⚠️特別注意事項：請耐心 debug！⚠️ 請注意，跟上一課一樣，由於本課簡化內容，沒有寫錯誤處理，錯誤訊息可能不會顯示！ 請用 `console.log` 慢慢查看每行程式碼的執行結果，慢慢寫出這一課作業！
上一篇文章談了「同時上班＆接案＆創業」的簡單策略 我發現滿多人對於接案這塊比較感興趣，提了很多問題 我簡單分享一些心得＆建議 --- > 請問原po，在準備接案有想過：我的能力已經足夠接案，這種類似的想法嗎？ 這幾年因為 freelancer 的身份，在一些活動、場合會遇到各種領域的 freelancer 每次遇到這些新朋友，我都會問：你是如何開始的呢？ 我發現有 90% 的機率，得到的故事都是以下這樣： 「我工作幾年之後，在 XX 年的時候離職，想說休息一下，看看之後要幹嘛。這時候有前同事來問：他那邊有人在問誰能接案，能否幫忙？」 「我就先接下來，想說那做完這筆，之後再看要不要找工作。結果做完之後再休息一下，這時又有朋友來問，能不能接某個案子。」 「我就又接一個，然後再休息一下，反正不急著找新工作。就這樣加減接案，做一陣、度假一陣。過了幾個月、幾年之後，有一天發現：我好像可以一直這樣下去。」 所以根據我個人經驗＆觀察：根本沒有人會下決心說，我要從此離職，轉身變成一個全職 freelancer 都是工作轉換的空檔，自然發生的。如果案子沒了，那就開始找工作上班，幾年之後離職休息，上面的故事會再重複一次。 所以重點是：為什麼這些人在轉換的空檔，會有人來問？ 其實就是 1. 在工作上的表現不錯，同事、主管、合作廠商、親朋好友都覺得你值得信賴 2. 有稍微經營個人品牌，身邊的人稍微知道你是做什麼的，然後根據互動經驗覺得你「溝通能力」不錯，會讓人想合作 3. 你稍微有一點勇氣，能夠接受這種「休息一下，想想看之後要幹嘛」的狀態長達數個月之久，很多人在這狀態會很緊張，急著找新工作 然後一些有趣的事情，可能就會自然發生。當然你需要有一點點積極、願意擁抱未知，大概是這樣 --- > 我其實不清楚到底要做到什麼程度？業界常用的必備工具有沒有掌握？發生問題解決辦法能不能處理？ 不論是工作、接案，基本上就是養成「挑戰能力範圍之外一點點」的習慣 不要超出能力太多，會被壓力擊倒、會開天窗、你誠信會出問題 不要完全做已經熟悉的事情，這樣沒有進步，久了會有點無聊 就做超出能力一點點的事情，常常這樣的話，久了自然會有把握＆經驗 這需要時間累積，沒有捷徑、沒有秘訣 --- > 哥有推薦接案的案源嗎 根據我的經驗，你在台灣註冊任何接案平台，或者去 FB 社團搶案子之類的，案件內容＆報酬都會「有點悲劇」 這沒辦法，平台化的東西，大家就是殺價競爭、紅海市場廝殺，比誰更樂意壓榨自己 你就算用英文搜尋，找國外接案平台，狀況也差不多，沒有好到哪去 所以我不推薦任何案源，我推薦你經營個人品牌。雖然有點丟臉，好像讓親朋好友看到你在老王賣瓜 但是行銷就是這樣，你多少要推銷自己一點，不然看起來一點自信都沒有，誰又能放心付個高價錢給你做案子呢？ 那怎麼經營個人品牌？參考我後面的回答 --- > 希望能分享關於案源品質管控的部分（怎麼避開爛專案）🙏 如果你很外向、具有那種油條的業務性格，那你就多多跟各種客戶談生意，多多談判，累積經驗就行 如果你很內向、不具有那種談判性格，實在很怕踩雷，那我建議你：只跟你喜歡的人合作 在 LINE 上打字、Email 往來的時候，感覺對方連話都講不清楚嗎？那你們實在溝通方式有差，建議婉轉拒絕吧 用 LINE 語音，或者視訊軟體開會，感覺對方有點城府，你有一點怕他嗎？那你們做人處事原則大概很不一樣，建議婉轉拒絕吧 實在很想避開爛專案，那就只跟你覺得「跟這個人當朋友好像也沒問題」的案主合作吧！ 當然工作機會，會減少很多，但是，你跟案主互相折磨、互相為難、互告上法院的機率也會減少很多 --- > 想問有建議其他職業的做法嗎？ 抱歉我比較熟悉寫程式領域 但其他職業的話，我覺得經營個人品牌總是不會錯 我滿建議大家 1. 部落格 2. Podcast 3. YouTube 4. 短影片 選擇一種格式來創作，分享一些東西，目標不用高，就花幾年時間，試著經營出 1,000 粉絲就好 分享什麼？結合你的興趣 or 專業，弄點「好笑的有趣的」或「有知識技術含量的」或「能幫讀者省錢或避免踩雷或有利益可圖的」內容，就這些即可，總是會有讀者，因為看到根本賺到 這過程會學到行銷、推銷、品牌、定位，很多很多商業基本知識，零收入沒關係，就是一種商業練習 千萬不要眼高手低、整天空想、整天焦慮沒完沒了，想要搞很大，過了好幾年還是 100 粉絲都沒有 慢慢來吧，但務必要有點進度、養成進步的習慣 以上，簡單幾點分享，希望對你有幫助
阿川收到網友提問如下： > 您可以分享您的軟體工程師職崖規劃嗎?再次感謝 我個人的職涯規劃其實比較偏激，是同時做「上班＆接案＆創業」這三件事 我簡單說明一下爲什麼我會這樣做，給大家參考 --- 我是 79 年次，2013 年退伍的，大學資管系畢業 出社會第一個月我就發現，我滿不喜歡上班的，但是我沒有能力、也沒有錢創業 於是我設計了一個我稱之為「三把梯子」的方法論，作為長期生涯指引 # 三把梯子理論 第一把梯子是上班：成為資深工程師、跳槽更大公司、賺更多薪水，這樣不斷往上爬 第二把梯子是接案：接親戚朋友介紹的案子、累積個人品牌、得到更多的客源，開公司接案，這樣不斷往上爬 第三把梯子是創業：研發軟體產品，從 side project 開始，從 open source 開始，學習行銷，學賺錢、寫更多產品、開公司創業，這樣不斷往上爬 基本上就是上班族、自由工作者、創業者三種職業生涯 --- 我給自己的三把梯子指引是：先從第一把梯子開始往上爬，稍微爬一段，就往旁邊的第二把梯子踩過去，接著爬 接著在第二把梯子慢慢往上爬，稍微爬一段，準備好了就往第三把梯子爬過去，慢慢往上爬 在這個過程中，只要覺得腳步沒踩穩、會摔死，就往回踩過去，爬前一把梯子 你可能覺得很離譜：想要同時兼顧三件事，不就會變成通通都搞砸嗎？ 其實，你只要... # 做同時對兩三把梯子有幫助的事情 職涯的大方向有了，接著就是付諸行動，要做一些能「同時對兩三把梯子有幫助」的事情 ## 部落格 我在 2013 年想到的事情是「寫部落格」，我非常勤奮地寫了兩三年，很多文章都還找得到 - https://blog.turn.tw/ - https://startup.turn.tw/ - https://dev.turn.tw/ 寫部落格、並且試著得到流量，會同時學到寫作、銷售、溝通能力，對三把梯子都會有幫助 我在寫到多篇文章都有數十萬瀏覽量之後，我就大致知道自己掌握這項技能了 ## 研討會 接著我想到的事情是「參與 conference 分享」 其實這沒有大家以為的那麼難，算是寫作的延伸加強版而已，拿原創的文章去一些小聚、研討會發表 我在成為 PHPConf Taiwan 2015 以及 LaravelConf Taiwan 2018 的講者之後，我就大致知道自己掌握這項技能了了 ## 做專案 再來是「寫 side project」以及做「open source」 一開始可以先做好玩為主，但之後要稍微從一些商業野心出發，才能學習 `monetization` （賺錢）這件事 我做了一些專案，在國內外論壇到處分享，成績馬馬虎虎，但我也學到很多 --- 上面這三件事情，會同時對「前兩把梯子」有巨大幫助，在找工作、或者接案的時候，很多人會更信賴你，對第三把梯子也會有點幫助 當然，像這樣同時爬三把梯子，沒辦法跟「專心爬一把梯子」的人比，這是一定的，而且要付出的時間相當龐大 但是，這讓我獲得足夠的安全感，避免一次做太高風險的事情，而且也有後路可退 # 我目前的三把梯子的進度 第一把：我現在去投履歷、找工作，在各種大小的公司都還是有面試機會，也有很多業界的朋友可以幫忙介紹，要上班沒問題 第二把：在完全不主動去找案子的情況下，很多朋友會幫忙轉介紹案子給我 我也是美國接案平台的簽約工程師 https://www.toptal.com/resume/chuan-hao-you 有時會接一些歐美的案子，所以要接案沒問題 第三把：我大概做了70個左右的 side project 目前正在經營的有這幾個 梗圖工具 https://memes.tw/ 每月60萬不重複使用者 咖啡廳資料 https://cafenomad.tw/ 每月3萬不重複使用者 活動平台 https://yii.tw/ 每月2萬不重複使用者 工程師交流 https://codelove.tw/ 您目前正在看的網站 另外還有 房地產 https://landchart.tw/ 書評網 https://wenwen.life/ 美女圖 https://beautyhunt.tw/ 批踢踢閒逛 https://www.ptt.best/ 這些網站，其中有幾個，是有一些收入的，所以第三把創業的梯子也還可以 目前這三把梯子，其實我都還正在爬，並沒有最後一定會待在哪一把梯子上面 # 結論 這邊簡單分享我替自己設計的職業生涯，「三把梯子」算是一種很偏激的職業生涯 業界像這樣做的工程師應該非常少數，最大缺點就是要花費的時間非常多，優點就是，其實樂趣不少 其實，學無止盡，這就只是同時在「技術」跟「商業」兩方面花時間學習而已 能分享的事情還有很多，大家有興趣就多多按讚吧，也許我再多寫一些這方面的文章！ 也歡迎大家多多發表文章，這個 CodeLove 就是我做來給工程師們互相交流的地方！ 以上簡單分享，希望對你有幫助～！
- 原文出處：https://dev.to/surajondev/top-7-things-that-kill-developer-productivity-ef9 ## 1. 會議  無效的會議是最不必要的因素之一，它會導致開發人員的生產力下降。寫程式需要專注。進入專注模式平均需要大約 30 分鐘。但由於多次會議，這種專注被打破，開發人員必須重新開始。 還有時間消耗，因為有時 10 分鐘的會議會延長到一個小時。此外，某些會議也需要不必要的出席。如果會議不直接涉及開發人員的專業知識，通常根本不需要他們出席。 --- ## 2. 技術債（晚點再修）  技術債務可以簡單地定義為“晚點再修”的心態。 最初，我們嘗試使該功能正常工作，並將優化留到以後進行。這可能在短期內有效，因為它可以加快專案速度，並且您可能會按時完成任務。但一次又一次地這樣做將會留下大量的工作要做。從而使得維護、擴展和改進軟體變得更加困難 技術債務會在很多方面阻礙開發人員的生產力。其中一些是： - 程式碼審查的瓶頸：當技術債務增加時，會導致程式碼審查時間的增加。 - 更多錯誤：由於最初的動機是速度而不是優化，這將導致引入隱藏的和未被注意到的錯誤。 - 程式碼質量下降：只希望「能跑就好」，會導致程式碼質量差、程式碼審查隨意、甚至沒有程式碼註釋、程式碼複雜等等。 上述所有要點都需要額外的時間來解決。從而拉長了專案時間。 --- ## 3. 程式碼審查  程式碼審查需要時間，如果審查過程太慢或過於官僚，可能會延遲新程式碼的整合並減慢整個開發過程。有時開發人員提出 PR，但程式碼審查人員沒有時間審查。從而增加了開發人員處理下一個任務的時間。 對於程式碼審查，開發人員可能必須參加多次會議，從而導致開發人員的工作效率下降。通常，對程式碼的不明確或複雜的反饋可能需要更長的時間才能解決問題，因為需要進一步的對話才能理解。程式碼審查很重要，但以錯誤的方式進行只會導致生產力的降低。 --- ## 4.微管理（缺乏自主權）  微管理是一種主管密切觀察和管理下屬工作的管理方式。當經理試圖控制開發人員的編碼方式時，就會發生這種情況。這可能會導致開發人員對其程式碼、流程、決策和創造力的控制力減弱。 它可能會以多種方式導致開發人員生產力缺乏。其中一些可以是： - 缺乏動力：微管理可以表明組織對開發人員能力的信任度較低。這樣，開發人員很容易感到失去動力。 - 創造力較少：開發軟體是一項創造性的任務，您需要集中精力探索創造性的解決方案。但微管理會導致對程式碼的控制減少，甚至阻礙開發人員的創造力。 - 決策緩慢：開發人員必須從經理那裡得到簡單決策的確認，在此過程中浪費了大量時間。 在所有這些情況下，開發人員的生產力都會下降。 --- ## 5.倦怠  倦怠是開發人員最關心的問題之一。在緊迫的期限內處理複雜且具有挑戰性的專案，以及交付高質量程式碼的持續壓力可能會導致倦怠。它最終會導致開發人員的生產力下降，因為它會降低開發人員的注意力和專注於編碼和建置的能力。 它還會導致開發人員的創造力和解決問題的能力下降。它最終將導致開發週期變慢。 --- ## 6. 糟糕的文件  文件對於開發人員來說至關重要，因為它傳達了有關程式碼、專案和流程的關鍵訊息。糟糕的文件可能會導致開發週期的嚴重延遲，因為開發人員將花費更多時間來嘗試理解程式碼庫、專案和流程。從而導致開發人員的生產力降低。 在開發人員入職時，提供糟糕的文件將導致開發人員花費更多的時間在任務上，例如設置專案、管理環境、理解程式碼和其他相關的事情。如果沒有明確的文件，維護和修改現有程式碼就會變得困難。由於擔心破壞功能，開發人員可能會猶豫重構或進行更改。因此，開發人員的生產力將被浪費在非核心任務上。 --- ## 7. 不切實際的最後期限  截止日期是讓開發人員失去動力的因素之一。當你被要求在短時間進行大量工作時，你會很容易感到沮喪。它會導致倦怠、程式碼質量差、程式碼審查疏忽等，這會導致技術債務的積累。從而導致開發人員的生產率下降。 截止日期很重要，但設定不切實際的截止日期給開發人員施加壓力，會給他們帶來壓力。在壓力下，整體生產力和程式碼質量都會下降。 ## 結論 有些小工具，可以克服這些挑戰，以在開發人員的健康和生產力之間建立平衡。 以下是一些可以幫助您提高生產力的工具： - [FocusGuard](https://chrome.google.com/webstore/detail/focusguard-block-site-foc/ifdepgnnjpnbkcgempionjablajancjc)：它是一個 Chrome 擴展程序，可以通過阻止網站來幫助您建立焦點。 - [Code Time](https://marketplace.visualstudio.com/items?itemName=softwaredotcom.swdc-vscode)：它是一個 VS Code 擴展，用於跟踪您的編碼時間和活動編碼時間。 - [JavaScript Booster](https://marketplace.visualstudio.com/items?itemName=sburg.vscode-javascript-booster)：此 VS Code 擴展可以提供程式碼重建置議。您也可以找到其他編程語言的此類擴展。 - [Hatica](https://www.hatica.io/?utm_source=dev.to&utm_medium=referral&utm_campaign=surajondev)：雖然上述工具僅限於一項任務並且專注於編碼，但 Hatica 負責大部分工作。它通過改進工作流程、辨識瓶頸和跟踪進度來幫助工程團隊提高開發人員的工作效率。通過這樣做，它可以釋放開發人員大量的時間。了解有關此工程管理平台的更多訊息[此處](https://www.hatica.io/blog/engineering-analytics-for-well-being/?utm_source=dev.to&utm_medium=referral&utm_campaign=surajondev)。 我希望這篇文章能夠幫助您了解開發人員生產力下降的原因。感謝您閱讀這篇文章。
最近在幫客戶專案寫 e2e 測試，發現幾個常見錯誤 首先，e2e 跑起來很慢，會拖慢 CI 速度，應該不是多多益善，而是要挑高價值的來寫 很多基本狀況、訊息提示、UI 表現，應該要用 unit test 來處理，vue 與 react 應該都有對應的 `component test` 工具可以寫 --- 再來，e2e 處理的情境要怎麼切分？這是典型的程式邊界（boundary）問題，也是 `抽象化` 問題的一種 網路上四處找範例，沒找到比較好用的設計方法，我試著自己設計 目前思考出幾個參考原則，要同時符合以下條件，才放進 e2e 測試 - 高價值原則：如果用戶處在這個情境，然後測試跑失敗了，老闆會很緊張，工程師就算在週末也需要緊急修理 - 變動頻繁原則：相關程式碼經常變動，所以每次在 CI 都跑測試會很有幫助 - 最後手段原則：這裡提供的安全感，沒辦法用 unit test 或 integration test 取代 --- # Refs - https://filiphric.com/how-to-structure-a-big-project-in-cypress - https://sendgrid.com/blog/ideas-for-configuring-organizing-and-consolidating-your-cypress-tests-frontendtwiliosendgrid/ - https://www.linkedin.com/pulse/organizing-maintaining-your-cypress-test-suite-best-kate-serebryakova/ - https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests
https://www.youtube.com/watch?v=Rr5AqASIyxw ## TL;DR - 在 JSX 使用 0 時，雖然是 falsy 但還是渲染出來 - [官方文件特別提醒要注意](https://react.dev/learn/conditional-rendering#logical-and-operator-:~:text=in%20its%20place.-,Pitfall,-Don%E2%80%99t%20put%20numbers) - [hackmd 版本](https://hackmd.io/@jason60810/BkKJwzk6h) ## Logical AND operator (&&) 在使用 `&&` 時要特別注意數字 0 的使用。 常見情況 : 根據是否是空陣列決定要不要印出陣列。 ### [範例程式碼](https://stackblitz.com/edit/react-uufonv?file=src%2FApp.js) ### 錯誤使用方法 1. 紅色 : 把 0 渲染出來 ### 解決方法 1. 變成布林值 1. 綠色 : 判斷是否大於 0 2. 綠色 : 利用兩個 `!!` 2. 橘色 : 使用 Logical OR operator (||) 
阿川收到網友提問如下： > 阿川您好 我是一位工業設計師，最近想轉職前端工程師，但年齡已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 社團，多觀察為主 以上，簡單幾點分享，希望對你有幫助，祝各位轉職順利！
https://youtu.be/I7dwJxGuGYQ ## TL;DR - 在使用 useContext 時，一定要將其包裝成 custom hook - [好讀版本](https://hackmd.io/@jason60810/rklVqNUh2) - [React 官方文件新增了 TypeScript 使用專文](https://react.dev/learn/typescript?fbclid=IwAR3Pgkr8xpS48Vwa0ADo3oagaAPKX1q05jHhtbXH8ltV8MKwa8FAvePoXPU) - [英文版本](https://jason60810.hashnode.dev/always-use-a-custom-hook-for-context-api-not-usecontext-react-context-api-typescript) ## 資料夾結構 ( 使用 next app route )  ### theme-context.tsx 一定要加上 `use client`，因為 useState 只能在 client component 運作 ， **特別注意，就算這裡加了`use client`，所有的子層還是 server component (預設)**  ### layout.tsx 加上 provider 之後，下面所有的子層都可以拿到值，不用用 prop 一個一個傳下去  ### page.tsx  ### logo.tsx 1. 因為 useContext 要在 client component 運作，所以要加上 `use client`。 2. 當使用 useContext 時，一定要引入 ThemeContext，用起來很麻煩 3. 因為 ThemeContext 預設是 null，所以當不是在 provider 裡使用 `useContext` 時 ( Logo component )，會發生錯誤，因此需要先確認有 context  舉例:不是在 provider 裡使用 `useContext`  ### 創建 custom hook  ### 使用 custom hook 現在引入 ThemeContext 和處理錯誤的問題，已經抽離到 custom hook 中  ### 加上型別 1. React.ReactNode，可以接受 JavaScript primitives ，如果只想要是 jsx 可以使用 React.ReactElement ( [react 官方文件](https://react.dev/learn/typescript#typing-children) ) 2. `type Theme` 可以讓 `useState` 在 get 和 set 時，可以使用正確的型別，例如:當想要 `setTheme('blue')` 時，會報錯，因為 `type Theme` 只有 'dark' 和 'light' 3. 在給予 createContext 型別時，可以利用 ts 的 union 讓 createContext 知道可能有 null 這個型別 ( [react 官方文件](https://react.dev/learn/typescript#typing-usecontext) ) 
大家好，我是站長阿川 我留意到 LINE 群組的討論非常踴躍 很多迷惘、想轉職的新手，各種發問，都有業界工程師幫忙回答，非常熱心！ 各位很多的回答「非常詳細」，完整到我覺得：只有群組內的新手看到，也太可惜！ 應該讓網路上更多人都能看到，這樣更造福眾生、未來有人 google 搜尋也能夠找到！ 繁體中文社群，需要知識不斷累積。如果一直在 FB 等等聊天室討論，然後被洗掉，有點可惜！ 這也是我建立 CodeLove 網站的初衷！所以我設計了一個新計畫，跟大家分享一下！ # CodeLove 前輩分享寫作計畫：VIP 審核限定 我鼓勵大家，在回答新手之餘，如果覺得 LINE 訊息文字篇幅不夠，或是 LINE 程式碼排版不易 請直接在 CodeLove 寫一篇完整文章，然後再貼到 LINE 群組內！ 舉例來說，我自己就有這樣回答 LINE 群組新手的習慣： [轉職軟體工程師的方法很多，到底該如何選擇：實體補習班、線上補習班、不花錢自學？](https://codelove.tw/@howtomakeaturn/post/NxN2Kx) [回答網友提問：如果前端要銜接後端的話，是不是學 node.js 比較快？](https://codelove.tw/@howtomakeaturn/post/2anP0x) [回應網友提問：我是新手前端，公司叫我學一點 php + laravel 串 API，該從哪邊學起呢？](https://codelove.tw/@howtomakeaturn/post/Zq4Ona) # 如何成為這個計畫的 VIP？ 原則上只接受「業界工程師」加入，也就是有工作經驗者加入！ 就算只有一年工作經驗，也是正在轉職的新手的前輩，所以也歡迎！ 越資深的話越好，因為您有大量的知識＆經驗可以分享！真的是大前輩！ **請在 CodeLove 網站上，任意發表一篇技術文章 or 工作心得，完成之後，點擊下方 LINE 群組加入：** https://line.me/ti/g2/9V19e5igoaUts-hrn1Vr3nNHMcGLLa1hJiaFRg 經過我審核之後，您就加入這個 VIP 群組了！ （例外情況：您是學生，但明顯有極大分享熱情＆知識，也會允許加入） # 身為這個群組的 VIP，可以幹嘛？ 首先，我希望您寶貴的文章，能被儘量多的讀者看到！ 您只要負責寫作就好，我會幫您「製造精美封面圖片」以及「行銷宣傳您的文章」！ 凡是 VIP 前輩發文，我都會在有超過三百人的群組「愛寫扣論壇：發問&交流&討論群」轉貼，並且「設定為公告置頂至少24小時」！ 再來，VIP 群組內都是「樂於分享、經驗豐富、寫作能力出色」的業界人士，大家可以在小群組內交流，我認為互相交換情報，也很有價值！ 最後，如果我覺得您的文章實在應該被「成千上萬的更多讀者看到」，我會直接到各大論壇，到處轉貼宣傳您的文章，類似下面這樣： - https://www.dcard.tw/f/softwareengineer/p/252600314 - https://www.dcard.tw/f/f2e/p/252598230 - https://forum.gamer.com.tw/C.php?bsn=60076&snA=7835159 - https://forum.gamer.com.tw/C.php?bsn=60292&snA=8421 我會確保您的文章被數千、數萬人閱讀！身為寫作者，通常文章四處發表，會到處被不同工程師嘴砲、開嗆，沒關係，這很正常，我會擋在砲火最前面！您不用被這些負面訊息轟炸，我只會回報有意義的正面留言給您！ 如果有很棒的留言或 feedback，我會貼回 VIP 群組內通知您！ # 我想加入，但我沒什麼寫作靈感，怎麼辦？ 首先，如果您有想發表的技術文章，當然可以直接當成寫技術部落格，寫一篇發表！ 再來，您可以在 LINE 群組，看看新手們都在問些什麼，然後就當作在回答他們，直接公開寫一篇完整回答！ 最後，也可以是您近期的一些技術筆記、工作隨筆，稍微整理之後發表，這種筆記也常常對後人很有價值！ # 結論 我真的覺得繁體中文世界，需要有一個優質的討論區、寫作園區，知識才能有效累積，這個國家的軟體產業才能進步、發達 另外，這個 CodeLove 論壇是有 [文章 API](https://codelove.tw/@howtomakeaturn/post/jqeDka) 功能的 您可以在這邊大量寫作，之後呼叫 API 串接到自己的部落格，markdown 格式與 html 格式的轉換我都已經幫您做好了 以上，各位熱心的工程師，誠摯歡迎您加入「CodeLove 前輩分享寫作計畫」！一起造福眾生吧！ https://line.me/ti/g2/9V19e5igoaUts-hrn1Vr3nNHMcGLLa1hJiaFRg 有問題歡迎直接留言與我討論！
## 課程目標 - 能夠從 Github 抓專案下來 ## 課程內容 我們在上一課發佈專案到 Github 了 這次來學習把專案從 Github 抓下來吧！ 首先來把電腦上的專案刪掉，模擬我們今天拿到一台新電腦的情境 在主視窗點選 `Current Repository` 會秀出專案列表 對著我們的專案 `my-first-repo` 按右鍵，然後選 `Remove` 刪除，確認視窗繼續按 `Remove` 會發現 Github Desktop 變回初始畫面了！ --- 但目前只是 Github Desktop 停止追蹤專案而已，那個資料夾其實還在電腦上喔 請在電腦上，直接前往那個資料夾，會發現檔案都還在 請把 `my-first-repo` 整個資料夾刪掉，這樣才是真的模擬拿到新電腦 --- 現在來試著把專案從 github 抓下來吧！ 點擊 `Clone a Repository from the Internet` 因為已經登入 github 了，應該會顯示專案列表 找到上次發佈的 `my-first-repo` 專案 （如果專案沒出現，畫面上有一個重新整理的按鈕，按一下） 然後 `Clone` 按鈕按下去 成功囉！專案回來囉！ `History` 分頁按下去，看看是不是跟之前都一模一樣？ 軟體工程師在跨裝置工作（使用多台電腦）、或是多位工程師合作時，就是這樣同步專案內容的！ ## 課後作業 接續前一課的作業，專案已經傳到 github 了 現在來模擬你拿到新電腦，第一次從 github 抓專案的情境 請把原本電腦上的那個專案資料夾，整個刪掉 這時去看 Github Desktop，應該會顯示「Can't find」開頭的提示 請將 Github Desktop 視窗截圖，這是本次作業的第一張截圖 截圖完畢之後，點擊畫面上的 `Remove` 將這個專案刪掉 --- 現在電腦上已經沒有專案了，就當作你今天拿到一台新電腦，準備開始工作，要把 github 上的專案抓下來 請點擊 `Add` 然後選 `Clone Repository...` 接著找到你在 github 上的專案 把剛剛那個專案整個抓下來之後，你應該會發現，剛剛整個刪掉的專案資料夾，現在內容又通通出現囉！ 請將 Github Desktop 視窗截圖，這是本次作業的第二張截圖 --- 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 請把第一張、第二張截圖，分別貼到留言區
## 課程目標 - 學會重置指令 ## 課程內容 來學一個強大的指令：重置 上一課的取消功能，是針對修改到一半的檔案 這時很自然會浮現一個問題：如果是之前已經提交過的內容，有辦法取消嗎？ 點開 `History` 分頁，假如我們今天對「上上次的提交內容」不滿，也就是 `add another work` 那筆 commit 不滿意，怎麼辦？ 其實很簡單！ 請把滑鼠游標移到 commit 上面，點擊右鍵，選擇 `Revert Changes in Commit` 你會發現 `History` 多了一筆 commit！ 這筆 commit 內容跟原本的 commit 內容完全相反，也就是會抵銷掉那筆 commit！ 打開資料夾看一下，會發現 `my-document-3.txt` 檔案整個不見了！ 這就是 git 強大的地方：不只是正在修改的檔案內容，連之前修改的內容，都可以追蹤、回溯、管理！ --- 看到這邊你可能會心想：為什麼要多一筆 commit？ 怎麼不把那筆 commit 直接刪除掉就好？ 其實，這是因為 git 通常是「團隊在使用」的工具 已經送出去的 commit，通常已經同步到很多人的電腦上了 如果這時工程師 A 刪了這筆 commit，工程師 B 刪了那筆 commit，那最後同步起來，大家電腦上的 commit 歷史記錄，到底長怎樣？很亂吧？ 所以，git 就一律設計成：想要回溯，就也是加一筆 commit！只是會自動進行相反的變化！ 這樣大家電腦上的 commit 歷史記錄，同步起來，就單純很多了！commit 數量永遠都是加法，不斷加上去而已！ 很聰明的設計吧！ ## 課後作業 這次來模擬實際工作的時候，你突然對之前的 commit 內容不滿意，想要把檔案內容還原的過程 繼續修改我們的履歷表專案吧！ 目前裡面有 `me.txt` `about.txt` `background.txt` `goals.txt` 四個檔案 你突然又有點反悔，覺得 `about.txt` 跟 `background.txt` 很多餘，想要把內容移回 `me.txt` 裡面 開發專案時，像這樣反反覆覆其實很正常，git 就是為了處理這種情境而生的 請切換到 `History` 分頁，找到之前把 `me.txt` 檔案改寫的那個 commit 然後使用 `Revert Changes in Commit` 功能來還原 commit 內容 還原之後，你可以看一下資料夾內容，應該會發現變回之前的樣子了！ 然後在 `History` 分頁應該會看到，多了一筆 commit，是用來記錄那筆還原的 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 請直接截圖 Github Desktop 視窗的內容，上傳到留言區
## 課程目標 - 學會簡易的檔案變化操作 ## 課程內容 來學一點簡單的檔案變化操作吧！ 打開 `my-document-1.txt` 然後多加下面這行字 ``` 是一段亂打的字 ``` 你會在 Github Desktop 再次看到 `my-document-1.txt` 檔案出現了，然後內容變化會在右側出現 假設我們今天對這次的變化內容不滿意，想要整個取消，該怎麼用 git 做到呢？ 請把滑鼠游標移到檔案上面，點擊右鍵，選擇 `Discard Changes...` 會跳出確認視窗，跟你確認真的要捨棄這些變化嗎？點擊 `Discard Changes` 會發現檔案消失在 `Changes` 分頁囉！ 代表檔案內容又變回去了，所以目前沒有任何變化～很酷吧！ 軟體工程師在工作時，常常會一口氣修改很多檔案，然後常常改到一半又對某些修改反悔，這時就可以這樣快速取消變化！ ## 課後作業 這次來模擬實際工作的時候，檔案改到一半，反悔了，然後取消的過程 繼續修改我們的履歷表專案吧！ 首先，你想補充更多學歷資訊 請先在 `background.txt` 加入以下資訊 ``` - 國小：開心國小 - 國中：快樂國中 ``` 你應該會在 `Changes` 分頁看到變化的部份出現 請將 Github Desktop 視窗截圖，這是本次作業的第一張截圖 --- 想了一下，你突然又覺得，國中國小學歷，應該沒人關心，還是別放進去好了 請使用 `Discard Changes...` 功能把 `background.txt` 檔案變回原樣 這時再看 `Changes` 分頁，應該又乾乾淨淨了，裡面沒有東西 請將 Github Desktop 視窗截圖，這是本次作業的第二張截圖 --- 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 請把第一張、第二張截圖，分別貼到留言區
聽過強大的 git 工具嗎？它是軟體工程師，用來管理程式碼版本的工具 就跟文書軟體的「上一步、下一步」很像，git 其實就是追蹤檔案「歷史變化紀錄」的工具 很多人都想學 git，但是剛開始接觸 git 指令與觀念，又覺得太複雜、被嚇到 於是，就有人開發了簡單、好用的工具啦！叫做 Github Desktop 使用 Github Desktop 可以享受到 git 的主要優點與功能 不過，很多進階的 git 指令無法用 Github Desktop 做到 可是沒關係，Github Desktop 依然是新手入門 git 很好的開始！ 我設計了一系列的作業讓你練習 Github Desktop 的使用！ 非常有趣、好玩，保證你會學到很多東西 話不多說，讓我們馬上開始玩玩看吧！
https://www.youtube.com/watch?v=9mOpk6qBLL0 雖然說寫程式 不一定會用到數學 但是多多少少你躲不掉 數學建立的基礎概念以及邏輯 尤其是越來越後面接近演算法的時候 你會發現數學根本太棒了 這個影片簡單快速的介紹了資料結構 以及其他的一些概念 可以不用有壓力的看過去
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆剛轉職的新手在討論： 公司有實施 WFH 在家工作制度，但沒人可以詢問、經常怕自己漏看訊息、整天感覺更焦慮了，怎麼辦？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情，跟大家分享 --- 首先，我認為 WFH 是一種「團隊技能」，也就是説：這不是一個人就能做好的事情，需要整個團隊的合作 再來，因為是技能，這不是每個人一入職就會的東西，需要經過訓練 總體來說，我認為要習慣「新的四種溝通方式」，分別說明如下 # 批次溝通 在辦公室大家可以隨時找同事討論、發問，也可以臨時團隊開會之類的。 遠端工作很難這樣做。因為人與人溝通的頻率被迫降低了，所以每次溝通的內容量要提昇。 建議養成批次溝通的習慣。也就是一次詢問多個問題、一次安排多個工作事項。 舉例來說，大家早上團隊視訊/語音開會的時候，不要只是每個人安排一天的工作量，最好把一整週的工作事項都先預排好。 這樣一來，當你手上的任務卡住，需要詢問別人問題、等待答覆、等待別人工作先做完時，可以先改做其他待辦任務。 這會讓負責安排工作任務的主管，工作難度提高不少。但習慣一下會發現效果很不錯。 發問的時候也是一樣。可以拿筆記本、或是在電腦開個檔案，整個早上陸續遇到、想到的問題，都記錄下來。 下次終於有機會跟同事通話時，一口氣問清楚。 就算只是用聊天室也一樣。 我常常一口氣丟出好幾個不同事項的不同問題。反正同事有空再逐一回答即可。 # 過度溝通 遠端工作絕對要避免這個狀況：因為溝通誤會，導致做了整天的白工。 絕對不可讓這種情況發生。平常在辦公室，隨時都能知道同事在幹嘛、有疑問也可隨時跟主管確認。在家工作可不行。 所以要養成過度溝通的習慣。我自己習慣是剛剛視訊時已經講過的事情，結束前我會再統整一遍、然後每件事描述確認一次。 結束之後，還會把我剛剛確認的事情打成幾個待辦，貼到聊天室讓對方再看一次。等於每件事我都跟對方確認2-3次。 我甚至會把同樣幾件事情，換個方式、換個角度再重新描述幾次，讓相關人都同意，我才放心沒有做錯方向。 有留紀錄的話，事後出問題也比較容易討論責任歸屬。 總之，在家默默工作幾天，然後才發現通通在做白工，是絕對不可以發生的。 如果你發現在家工作之後，自己會一直跟同事確認事情，或是同事會多次重複確認同樣的事情，好像大家變得有點神經質？ 別擔心，這不但是很正常的現象，還是很鼓勵的現象。 # 被動溝通 拍同事的肩膀問問題、叫他過來開會、打電話給他…等等，屬於主動式溝通：以發問的人優先，被問的人配合發問的人的時間。 貼便條紙給同事、張貼事項在公告欄…等等，屬於被動式溝通：以被問的人優先，發問的人配合被問的人的時間。 被動式溝通以被問的人、接收訊息的人為主，有空時才答覆、做出反應。 遠程工作的團隊一定要習慣被動式溝通，否則遠程工作就沒有意義，也沒有效率，會變成很痛苦的事情。 網路時代讓被動式溝通輕鬆許多，只要採取多層次溝通就行了。 # 多層次溝通 多層次溝通指的是依照主動/被動程度的不同，分成至少3-4層溝通工具。舉例來說： 即時溝通：見面、手機/Skype/Hangouts/Zoom 通話 通訊軟體：Skype、Line、Facebook Messenger 工作聊天室：Slack 任務管理軟體：Bitbucket/Github、Trello 即時溝通是最主動的一種，碰面開會、打電話等等都算。在很多情況下，還是需要用這種方式討論、腦力激盪。最好每天約個固定時間線上通話一下。 通訊軟體則是次之的溝通方式，但因為訊息通知會一直跳出來，還是有點干擾。 工作聊天室是最常發生溝通的地方。這類工具的特色在於，忙著工作的人，可以直接把聊天室關掉，就不會被打擾。有空時再打開來看看有什麼需要回答的、討論的。 任務管理軟體是大家一起紀錄工作待辦事項的地方。需要日後方便翻閱的東西都記在這裡。 其它工具軟體像是 Google Docs、Google Sheets、hackmd 也都非常好用。 --- 以上是四種 WFH 個溝通方式，另外有兩點補充 # 被動式溝通優先，非必要不使用主動式溝通 上面提到的多層次溝通模型，越上面是越主動，越下面是越被動的溝通方式。團隊成員要慢慢習慣，非必要別使用主動式溝通。沒那麼急著得到答覆、急著需要處理的事情，就盡量用被動的手段溝通。 話雖如此，每天慣例性地在固定時段通話一次，可以大幅增加團隊的安全感。 # 每次開會都做線上筆記，所有檔案都對所有人公開 因為大家沒待在一起，開會完忘記會議細節的話，會需要一直詢問同事，很浪費時間也很煩。 所以開會時建議使用 Google 文件、hackmd 或是其他可以共同編輯的軟體，開會的時候一邊做線上筆記。 然後這些文件最好公開給整個團隊的人看到，讓全部資訊同步到全部人腦中。 這些技巧熟練之後，團隊成員不但可以專心工作，溝通能力也會全部上升。 像是跟客戶、合作廠商溝通這種本來就需要遠端溝通的任務，remote 工作者也比一般的工作者更知道怎麼溝通、避免溝通誤會。 # 結論 這些工作方式有點違反一般的工作直覺，所以容易被忽略。 但只要習慣一下，一定會發現遠端工作的好處，工作效率甚至比在辦公室更高。
在我們新手寫程式 LINE 群組，有幾個業界工程師＆想要轉職的新手在討論： 非本科轉職，到底要學什麼語言？ 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，那你可能要同時請他推薦職缺了！因為幾乎沒有願意給你機會的職缺！ 以上，簡單分享，希望對你有幫助！ 可以留言：你想看的程式語言，我找時間做一份更新、涵蓋更多語言的！
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆新手在討論： 如果前端要銜接後端的話，是不是學 node.js 比較快？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情 --- 首先，我很推薦新手前端也去學一點後端，這樣對整體概念會更清楚 這位網友提到的 node.js 很不錯，但是我更推薦去學 php，簡單幾個原因說明如下 # 無框架開發 常見的後端語言，在寫網站時，都需要套件＆框架才能開發 - python 需要 django - ruby 需要 rails - java 需要 spring - node 需要 express 我建議你直接寫 php 做好玩的小網站，不要用框架 php 雖然現在都用 laravel 框架，但古早時代大家都寫純 php 如果現在只是自己做個小專案，當然寫純 php 也是夠用的 學框架沒什麼不好，但是，在新手一開始的階段，我更推薦從單純的東西開始學起 一來上手很快，二來等於是紮穩馬步，三來之後學框架可以去思考：如何用純 php 語言寫出框架元件 如果自己想補充後端知識，就試試純 php 吧！先別學 laravel，晚點再去學就好 # 後端先避免非同步程式設計 這件事比較 tricky，javascript 語言本身支援非同步，這在前端 UI 處理很好用 也就是常用的 async/await，`.then().then().then()` 或者到處傳 callback function 那些的 但是！我認為在寫後端的時候，這個語言特色會讓後端開發時，顯得有點囉唆 以後端讀取檔案內容來說，絕大多數情況下，你就是要現在就讀取好檔案、讀取完才讓程式接著繼續跑，才有意義 幾乎不存在「非同步去讀取檔案，不等結果，先直接去處理別的任務」這種情況 於是 node 後端程式碼就需要去傳 callback function 或者 async/await 我認為這有點囉唆，這些情境實在沒必要用「非同步程式設計」處理！ node 社群自己也知道，所以除了 `fs.readFile` 之外，還有提供 `fs.readFileSync` 函式 作為一個教育者，我很不喜歡跟新手解釋，為甚麼會有這兩種函式，差異在哪 我認為新手後端，多去學非同步程式設計的觀念與技巧，是徒增挫折 用 python/php/ruby/java 寫後端，都不會遇到這個困擾 新手後端就學好 http 協定，GET 跟 POST 參數是怎麼傳遞的，怎麼使用 session，怎麼連接資料庫就好了 不要多被一個 asynchronous programming 困擾 # 多學一個程式語言 本身是前端工程師，再去學後端想用 node 繼續寫 javascript 當然很合理 不過，長遠來說，多學幾種程式語言，對職業生涯比較健康 首先，你會更有自信一點，並且，能夠開始比較各種程式語言的差異與哲學 很多在 A 語言理所當然的事情，在 B 語言是很罕見的 很多在 A 語言社群大家都說「對」的事情，在 B 語言社群大家都說「錯」 長遠職業生涯來說，你需要至少寫過多種程式語言，才會發現大多數事情都只是「不同社群」的「主觀偏好」 你會發現網路上多數講的斬釘截鐵的對錯觀念，都只是一種偏執。你的觀點會更全面 # 結論 以這位網友的狀況來說，本身是前端，其實，學 nodejs 或 php 都不錯啦 我個人是偏好 php > nodejs 一點，這樣 以上，簡單分享，希望對類似狀況的朋友有幫助！
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆剛轉職的新手在討論： 我是新手前端，公司叫我學一點 php + laravel 串 API，該從哪邊學起呢？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情 --- 我猜你面臨的情況，老闆不是真的叫你從無到有寫後端，應該是去硬改現成的後端專案 因為是公司馬上需要的，先求速成為主，背後細節就先別管了 就分幾個步驟來做吧 # Step 1 laravel 官網 `Installation` 章節讀一讀，然後看你用什麼作業系統，網路上 laravel 安裝教學找幾份試試看 先想辦法把環境跑起來，讓目前專案可以在電腦上跑 然後找一款有 GUI（圖形化介面）的資料庫管理軟體，在 UI 上點一點，準備好資料庫 # Step 2 `Routing` `Controllers` `Requests` `Responses` 這幾個章節讀一讀 至少稍微看懂，後端是哪些地方在接收參數、回應參數 # Step 3 把 `Eloquent ORM` 章節讀一讀，這個類別提供很多神奇的方法，很輕易就能做到 CRUD 至少稍微看懂，後端是哪些地方在跟資料庫互動，自己有辦法新增資料、更新資料、刪除資料這樣 --- 除此之外，上網找幾份 laravel 的簡易 CRUD 範例教學，不太懂背後原理沒關係，按照指示，做個部落格之類的 然後就去硬改公司現成的後端專案，頂著用，不然短期內也沒辦法真的學精 laravel，就先這樣吧！先能滿足公司需求就好！ 其實，以上所說，真的是很混的學習方法：ORM 背後的觀念、資料庫的 SQL 觀念，幾乎都沒學到 長遠來說，如果是真的要學 php + laravel 後端，我都是建議先從「純 php + mysql」開始學起 也就是我鼓勵新手用純 php 寫一個部落格網站，寫純 SQL 去連接資料庫，先搞懂這種最純粹的寫法 然後再開始學 laravel 以及 ORM 等等好用套件工具 不然的話，我知道很多人直接從 laravel 開始寫起，半知半解，工作很久了，卻連哪些功能是 php 提供的，哪些是 laravel 提供的都分不出來 然後在需要換框架 比如 CodeIgniter 或者 Yii 的時候，很多觀念無法融會貫通，長遠來說，根本事半功倍 --- 話說回來，如果老闆不是叫你硬改現成的後端專案，而是叫你從無到有寫後端 那這工作內容實在不太合理，除非你一開始應徵的就是「全端工程師」的職缺＆薪資 以上，簡單幾個方向分享，希望對你有點幫助！
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
