在 dev.to 看到這篇文章，How to learn in public - dev.to，覺得很讚，來寫一下筆記。

一、什麼是在公開場合學習？

公開場合是指在網路上分享學習成果。

二、什麼原因會導致猶豫是否要在公開場合學習

• 我不是專家
• 太可怕
• 我還沒準備好分享我的作品
• 我不想被公審
• 技術人員不需要成為內容創作者

事實上，在公開場合學習的心態

1. 你不需要成為專家

在公開場合學習專業知識與完美無關，重點是達到一種誠實與開放的方式，紀錄從初學到高級者的過程，即使你不是專家，在公開場合學習仍然可以幫助到那些找到你內容的人。
很多時候，吸收你的內容的人，與你處於類似的階段，對他們的學習來說是耳目一新的。有時專家很難向初學者解釋概念，因為他們離初學者階段太遠了。

2. 錯了沒有關係

錯誤發生了，那又怎樣，這是學習的一部分。從你的內容中學習的人，更在乎它的真實性而不是完美性。甚至給予他們一種空間，讓他們犯錯感到自在。

3. 您的回覆是我進步的最大動力

酸民確實存在，即使是最受歡迎和最後尊敬的創作者也會有很多酸民。然而，大多數人，都會樂見於你的成長。老實說，社群的回饋比酸民的言論更多。此外，支持者有時候會鼓勵你在休息的時候持續學習往前，但不意外你應該忽略你的感受與心理健康。與促進你成長的人結識，遠離酸民，適當的休息。

4. 完美是進步的敵人

你可能會想要等到所有東西都很完美後，再分享它，這是完全沒有問題的。但這剝奪了一些你在公開場合學習的一些好處，以下有三種不同的情境：

情境 1： 你在公開場合學習，人們對你正在建構的東西感到興奮

他們觀察你的過程，隨著你的進步，他們感覺到你知識淵博，因為有證據證明你隨著時間的推移正在進步。你的網路擴大了，獲得了更多的工作機會，人們會協助你往正確的方向前進，這會點燃你繼續學習與建設的動力。且你紀錄了隨時間推移的進步，所以你可以回顧已經走了多遠。

情境 2： 你正在等待分享你的成果，但這需要很長的時間才能最終完成目標。到時候你宣布你的成果發佈，人們沒有預料到它的發佈，所以獲得的反響較小

情境 3：你正在等待分享你的成果，因為失去動力而放棄了專案，這個專案一無所獲，即使是一個很好的點子

當你在公開場合學習時，人們會投入到你的旅程中，記錄這段旅程可以讓你回顧自己的成長。

5. 建立自己的品牌，有助於你掌握自己的職業生涯

很多成功的軟體工程師，他們不使用社交媒體，也不在公開場合學習，這沒有問題。
然而如果一直在等待別人推薦你，很難控制你的職涯方向。通過在公開場合學習來建立自己的品牌，是一種自我推廣的形式。如果你對自我推銷感到畏縮，那「成為一名優秀的工程師」有什麼意義？

三、如何在公開場合學習

1. 設定 SMART 指標

具體、可衡量、可實現、相關、時效性的，如：

• 具體：我想學習 SEO 來為我的團隊貢獻。
• 可衡量：當我完成 SEO 課程，或閱讀完相關概念時，我將寫成文章來整理我所學習的知識。
• 可實現：我已經對 SSR 的概念有些了解，且對我來說使用前端工具來增強 SEO 是很好上手的。
• 相關：雖然我是一名中級工程師，但我不能就 SEO 的決策向我的初級同事提供建議，而且我對選擇這些任務感到更加猶豫。
• 有時限：我希望有信心在接下來的六個月內學習如何提高網頁 SEO，以便及時進行審查。

2. 確定您喜歡使用的平臺

有一個迷思，當你決定開始在公開場合學習後，你需要在推特、開源專案、Podcast、conference 上發言，但完整達到且持續進行是不可能的，因為沒有那麼多時間。建議先從一個平台開始，選擇讓你最舒服的平台。例如：我一直喜歡用寫作來表達自己，所以決定通過 Twitter 在公開場合學習，最後會演變成部落格文章。當我想挑戰自己的時候，嘗試在直播中分享，然後我就可以在 conference 中更有自信來表達，這是一個漸進的過程。

如果不確定有哪些媒體可以在公開場合學習，這裡有一些：

• 部落格：請利用流行的開發人員部落格平台，如（Aviyel, Dev.to, Handnode），來談論你正在學習的內容。
• 開源專案：如果不想發言或創建內容，可以透過開源程式碼，供其他人查看和協作。
• 直播：在直播中 live coding，並與觀眾互動。他們可能會告訴其他人你的專案，或是要求要自己貢獻。請注意你不可能永遠在直播當中提供解決方案，這沒有關係。邊學習邊直播是一個額外的技能，會隨著時間的推移而進步。
• 在聚會或 conference 中公開演講：不要害怕，人們參加聚會和會議來提高靈感，他們並不是在尋找博士級別的講座，上台分享你正在學習的東西，你為什麼學習他、你面臨的問題，以及你的發現。
• TikTok, Youtube

3. 選擇可管理的節奏

每個人每天只有 24 小時，要工作、社交、學習、家庭生活，現在又多了「在公開場合學習」，檢查一下每週例行公事，選擇一個專門的時間在公開場合學習，有些人在工作日利用禮拜五來學習，可以嘗試與主管討論。

4. 開始發佈

人們總是想準備好再上場，例如擁有完美的相機、或需要先建立自己的部落格平台，但即使一切都沒有準備到位，也要開始。因為隨著時間的推移，一切都會越來越好，這是過程。

5. 觀察與吸收其他人分享的資訊

如果不確定如何正確的在公開場合學習，可以觀察其他人，不需要完整複製他們的方式，但可以當作靈感，學習如何優雅的犯錯，與受眾互動並格式化自己的內容。

6. 想辦法集中管理且追蹤你的內容

隨著時間推移，你創作了大量的內容，但他可能存在於各種平台。收集你的內容，像當前或未來的老闆 Demo 作品，作為知識與影響力的證據，作者使用 Polywork 來追蹤自己所有部落格文章、演講、影片，可以自己選擇。

7. 偶爾反思自己的進步

健身的人經常紀錄自己的體態，來記錄他們的進步。但若沒有紀錄，健身一年，也可能會覺得 0 進步。這時照片與鍛鍊日記這種可以回顧的紀錄，就是一個很好的方式讓你意識到自己的成長與過程。在公開場合學習也是如此。有時可能會覺得挫折、撞牆，可以試試回顧、反思自己的成長過程。

8. 慶祝

完成了一個目標，適當的放鬆，沈浸在自己的偉大中，去吃一頓大餐或給自己買個禮物。我們經常忽略自己的成就，就迅速的往下個目標前進，但你應該享受你的成果。

9. 重複

你實現了你的目標，但不必止步於此，在慶祝與放鬆後，評估是否適合開始制定新計畫，並持續自我提升。

四、總結

在公開場合學習有多項好處：

1. 誠實且公開的面對自己的成果與過程中的不完美
2. 紀錄自己的成長
3. 建立自己的品牌，促進自我推廣
4. 與社群互動，獲得動力

課程網址

心得

此課程讓我對敏捷式開發有更深入的了解，不是只停留在敏捷的大原則，而是從開發面切入講解，理論面偏重，個人認為較適合已經有 CI/CD 基本操作經驗者修課。

在現代敏捷式開發架構中，「自動化」變得非常重要，在開發過程中，為了降低產品上線的時間成本，大致上會有以下的流程：

一、開發流程

1. 使用版本控制 + 自動化持續地整合

1

持續整合意思是高頻率的把開發中的程式碼合到主線上，並到正式環境上建置，出現問題時可以立即發現並修正。

2. 自動化測試

在正式環境建置之後，代表程式碼可以被編譯，但功能使用上還是可能會出現錯誤，所以需要撰寫自動化測試來測試功能，好處多多，可以在將來放心的重構程式碼，達到一樣的功能規格。

3. 自動化佈署

1

相對傳統部署（單一環境、直接覆蓋新版本、出錯回復慢、服務易中斷）藍綠部署 + 金絲雀部署 + 自動化部署，將微服務切成好幾個 server、透過 load-balancer 將使用者分配到不同的群組，使得部署可以逐步進行，先部署到一部分的使用者，若無問題，逐步直至到全部的使用者，若有問題，則會自動 roll back，停止部署，更換舊版本。

4. 自動化監測

1

在 CI/CD 的過程中，難免會有錯誤的發生，所以自動化監測可以幫助「即時」處理錯誤，並通知開發人員處理。

​

二、敏捷開發的好處

• 最低化的使用者體驗影響
• 降低總開發時間
• 降低建置、部署的時間成本
• 允許大膽重構程式碼，提高編譯效率

三、敏捷開發的缺點

• 環境較多，需要的主機也較多，導致成本高
• 初期需要花大量時間架構自動化流程

筆記

一、過度設計(over design)

1. 什麼是過度設計(over design)

提供的功能比需求多太多，很多甚至用不到

例子：瑞士刀、手機預設 APP

2. 過度設計造成的問題

浪費時間、增加複雜度、降低可維護性、可讀性

3. 情境解說

常見情況有「我想這個以後會用得到」。

保持 KISS 原則：Keep It Sample and Stupid

使一般人都可以看得懂

二、結隊編程(Pair Programming) – 多一雙手會更快

結隊編程：兩人一起共同寫扣，一人口頭敘述，一人寫 code，從而互相學習，從討論中提高效率

好處：知識傳播、互相監督

三、持續整合(CI) - 每個人都伸手來摸你的Code，誰來整合

持續整合，其實就是大家在利用版本控制遠端開發的時候，經常性的將本地端的 code 合併到遠端的 master 內，藉此降低衝突的發生，也可以持續的測試在正式環境是否一切正常。

持續整合的工具 Jankins

• 可以有多種方法可以觸發自動建置，例如：每天早上、每次提交時…等等

透過自動化整合的工具，可以持續交付、建置程式碼到環境上（包含開發、測試、客戶測試、正式），最好的實踐就是每天整合，需要把測試的功能也整合到 CI 的工具上，有發生問題的時候應該設定通知給開發團隊，且應該把修復 CI 作為優先處理。

四、自動化測試(Automation Test) - 不做自動化，就等肝硬化

1. 單元測試

• 可以在開發早期就發現問題

• 符合 FIRST 原則

  • Fast
  • Independent
  • Repeatable
  • Self-Validating
  • Timely(TDD 概念)
    測試要能快速、獨立而不會互相影響、可以重複執行、並自我驗證，說明哪個測試成功了、即時性的，最好是在寫 code 之前就寫測試

• 3A 原則

  • arrange 目標物件、參數、預期結果
  • act 驗證邏輯
  • assert 驗證結果是否符合預期

2. 整合測試（單元合在一起

把多個程式模組合一起進行驗證，例如：資料庫測試、API 接口測試、傳輸協定的驗證。

3. E to E 測試（從頭到尾）

以使用者行為進行測試，又屬於「黑箱測試」。

測試經常會被工程師以各種理由逃避，例如

1. 開發時間不夠
2. 不會寫測試
3. 維護測試很花時間
4. 跑測試也很花時間

測試帶來的好處

1. 可以專心在開發
2. 可以放心大膽重構程式碼，提高質量
3. 遇到 bug 就把測試補上，避免重複的問題
4. 大量降低建置的時間成本

測試的進階實踐 TDD (Test-Driven Development) 測試驅動開發

• 測試先寫，再寫 code
• 先釐清需求，列出實例化需求
• TDD 的循環：綠燈、紅燈、重構
• 排列需求逐步增加產品代碼
• 即時重構
• 測試全通過 -> 產品完成

自動化測試總結

可以將測試整合在 CI 裡面，通過自動化建置後，進行自動化測試，若產生錯誤，一樣會通知開發人員。

大量的單元測試 + 適當的整合測試 + 少量的 End-to-End 測試 ＝ 幫助維持開發速度。

五、重構(Refactor) – 改善既有的程式碼

所謂重構，就是在不改變程式碼外在行為（例如：元件結合、API 接口）的情況下，改變內部行為。

重構的好處

1. 幫助找到 bug，重構需要提高對程式碼的理解，也可以幫助你更好的找到程式漏洞。
2. 提高編程速度: 有良好的設計添加新功能才更容易、理解度高的程式碼也更好維護。

什麼時候該重構

1. 三次法則：功能經常重複使用，達三次以上的時候
2. 添加功能時：
   • 理解架構
   • 調整架構
   • 下次更容易
3. 修補錯誤時：修改掉原本的問題

程式碼的壞味道

1. 重複的程式碼：當要修改一個功能的時候，需要去修改很多地方，就代表這個程式碼需要被重構，或打包來重複使用。
2. 過長函式（不容易理解）
3. 過長參數列

重構後的程式碼必須要經過測試（單元測試、整合測試、End to End 測試）

六、持續交付(CD) – 系統維護中，請稍候

• Continuous delivery 持續交付
• Continuous deploy 持續部署

符合敏捷原則，在 CI 與自動化測試的輔助下進行。，持續地交付產品給客戶。

良好的 CD 流程

1. 傳統部署

1
2
3
4
5

- 環境單一，直接覆蓋新版本
- 簡單成本低
- 服務會中斷
- 出錯時回覆問題也慢
- 適合用在測試環境上

2. 傳統部署 + feature toggle

1
2
3
4
5

 - 環境單一，直接覆蓋新版本
- 簡單成本低
- 服務會中斷
- 切換 toggle 來開放新功能
- 出現問題時把 toggle 切換

3. 金絲雀部署

1
2
3
4
5

以前礦工在挖掘時，不是到礦道內是否有毒，所以利用金絲雀來做測試，因為金絲雀對有毒氣體非常敏感。
- 多個環境，慢慢覆蓋新版本
- 容錯率高，發生問題立刻回覆
- 使用者體驗影響較小
- 若沒自動化流程過程繁瑣

4. 藍綠部署

1
2
3
4
5
6
7

- 兩個環境群組(線上、現下) ，線下覆蓋新版本再交換
- 需要有 load-balance 環境
- 需要有 state server
- 不影響使用者
- 發生問題，切回舊版本，容錯率低
- 出錯版本對使用者時間短
- 錯誤版本可以線下修改

5. 藍綠部署 + 金絲雀 + 自動化

1
2
3
4
5

- 自動化部署，一段時間後逐漸增量
（切成四個 server，逐一上服務，沒出現錯誤就繼續執行）
- 超高容錯，發生問題就切回舊版
- 使用者影響最小化（四個 server 逐步部署）
- 需要良好的監控服務（例如：重啟 container、有 bug 通知開發人員...等）

完整的 CI/CD 流程

正式環境 / UAT 環境

↑

版本控制 -> CI 伺服器 -> 自動化測試 -> 發布版本控制 ->

↑

開發環境 / PC / Local

課程重點

• 使用 Jenkins 等工具來運行 CI/CD
• 版本控制是必須的
• 自動化建置
• 自動化測試
• 自動化部署
• 自動化監控