第 130 期 - 沒有時光機沒關係，我們有 Git

Created on 2022-04-26

本週專欄

Git | 我以為的 Git Rebase 與和 Git Merge 做合併分支的差異

Hi！大家好，我是神 Q 超人！用 Git 做版本控管應該是大部分工程師每天都會碰到的工作流程之一，但我在使用上不外乎就是 push、pull、merge、checkout 或 log 等幾個指令，更深入一點就一問三不知了 😂，而在這個狀況下的我，就在和朋友聊天的時候遇到了這個問題：

「欸，你知道 Git 的 merge 和 rebase 有什麼不同嗎？」

聽完後我直接困惑，對我來說 rebase 就是用來整理 commit 的工具，居然還可以和 merge 做比較？如果你和我有相同的疑惑，或是早就知道，然後只想複習的話，都接著看下去吧！ 🙌

前端開發

Writing Strong Front-end Test Element Locators

自動化測試可以寫下程式碼，讓程式碼代替人類的行為，操作你的網頁或是一個 Component，並且為所有行為下斷言，確保所有事情都如同你預期的那樣運作。文章中介紹了許多在寫測試案例時的知識，非常值得一讀！

CSS Tips

作者介紹滿多只用 CSS 就能達成的網頁效果，其中包含 Typing Effect、Modals 和 Dynamic Tooltips 等等，幾乎所有例子都有附上 CodePen 的程式碼頁面。

How to escape from memory leaks in JavaScript

Memory Leak 可能會造成 JavaScript 的應用程師效能低落，但在開發的時候又常常會忽略記憶體管理，這篇文章內容主要是在探討記憶體管理、Memory Leak 的類型和如何使用 Chrome 的 Devtools 尋找問題！

後端開發

10 Microservice Best Practices: The 80/20 Way

微服務架構帶來高彈性與服務開發之間的解耦合，然後他也帶來一些挑戰，例如效率，一致性，安全…等，所以這篇文章為大家帶來 10 個 Microservice 的最佳守則，以下僅列出各個主題，文章內對於每個主題都有詳細的說明與參照

使用 Domain-Driven Design(DDD) 來改善生產力
使用 Single Responsibility Principle (SRP) 做出快速回應
通過獨立的微服務實現微服務自我治理
擁抱平行化地異步溝通方式
透過容器化微服務來改善效率
通過微前端來增加原生 UI 的能力
透過安全的微服務來保護重要資料
使用不可變的 API 來簡化平行化程式
透過 DevOps 文化來提升交付速度

[🤑 Medium 付費文章] 23 Basic Principles in Software Architecture

此篇文章介紹了 23 種軟體架構的基礎原則，例如：Dependency Inversion, Separation of Concerns, Inversion of Control, Dependency Injection…等，有些附有程式碼說明，自己覺得把這些原則都理解之後，應該可以對於設計服務，撰寫程式時避開不少冤枉路，減少技術債的產生

Comments: How Google Developers write their comments

寫程式需要寫 Comment 這件事情從一開始學程式就一直被教導著，不過大家知道 Comment 其實有不少種類型嗎？！例如有關於法律上的，提供資訊的，說明意圖，用來澄清，警告以及 TODO，這篇文章嘗試解釋這些不同的 Comment 類型；而在回文有不少人覺得其實將變數命名妥當，程式撰寫完善就可以讓 Comment 寫的更少，甚至不需要，大家也是這樣覺得嗎？！

Cloud

AWS CSA Associate 學習筆記 - S3(Simple Storage Service)

大家都用過 S3，但 S3 還分成很多 storage class，想要存取速度快又要跨區存取，那就貴，但如果只是拿來封存一些可能一輩子開不了幾次的檔案，也不要求需要時馬上拿到，那就可以用很便宜的價格存很多東西

三十天考過AWS CCP證照，真 awesome 系列

如果想有系統的學習 AWS，而不是東學西學的話，我覺得這系列寫得還蠻好的。就算沒有打算考 AWS 的 CCP(Certified Cloud Practitioner) 還是可以來看

AWS vs Azure vs GCP: Comparing The Big 3 Cloud Platforms

AWS、Azure 跟 GCP 是現在最大的三個雲端平台，也有各自的優缺點，所以在做選擇的時候記得先做一番比較，否則就可能會發生像我之前用 GCP，結果發現他們沒有像 AWS SES 一樣用來寄信的服務XD，只好再把架構搬到 AWS 上

DevOps

作者原本使用 helmfile 來管理 Kubernetes 的部署，也很喜歡裡面的諸多的功能，不過作者依舊尋找更好的工具。作者認為 helmwave 除了常見的 everything as code 的功能外，還有循序部署、即時追蹤 Kubernetes resources、不需要額外的工具就可以直接使用 helmwave，很多測試工具如 kube-linter、Kubeval、Pluto 都可以整合，還有一個特色就是使用體驗跟 docker-compose 很像。

Stop Using Branches for Deploying to Different GitOps Environments

此推薦文章和下篇是同一系列，作者講述很多組織在使用 GitOps 如何在同一個 release 前進到下一個環境是大家一直探討的，因為答案有很多種，所以作者就索性說明哪些我們應該避免：

依環境分 git branches 只適用於 legacy applications（這裡指的是傳統 git-flow），採用 trunk-based 並且用依環境用 feature flag 來控制，application code 和 configuration code 也建議放在不同 repository
前進到下個環境從來不是只有 git merge 這麼簡單，兩次的 merge 都修改同一個地方時有可能會被忽略而 merge 進去了，hotfix 時的 cherry-picks 也得小心使用
依照環境分 branches 不太適合 Helm/Kustomize，因為它們並不會知道 git branches、git merge 或 pull request，因為他們都是靠檔案做環境分類

How to Model Your Gitops Environments and Promote Releases between Them

接續上篇，作者持續探討 GitOps 如何順利地 release 在各個環境中：

要先了解你維護的服務
五個範例來解釋每次的變更對環境的互動
如何初始化新的部署
對照不同環境的設定
要如何 release 在不同的 GitOps 環境
更改設定就要改全部的環境
環境依照資料夾來分的好處
如何在 GitOps 環境中使用 Helm
大型組織可以考慮依環境分 repository
環境分類請愛用資料夾，而非 branches

StarBugs Weekly

StarBugs Weekly 由一群不寫文章就會想要亂花錢，但是又沒有那麼多錢，只好繼續寫文章的開發者所創立。
內容包含 Web 前端、中端、後端、DevOps、產品開發、精實創業，一切跟產品有關的知識，都是我們的守備範圍！

Writers:

@HannahLin - 從台灣到矽谷，熱愛前端的工程師女孩。
@KyleMo - 雜食性軟體工程師，喜歡的技術我都想學。
@Airwaves - Hi~我是 Airwaves，熱愛研究如何造輪子的前端工程師。
@Jenny - 我不寫 CSS。
@Andy - 目標成為用嘴巴工作的工程師，專長為網頁開發以及 K8s。

Maintainers:

@GQSM - Hi！我是神 Q 超人，一個先衝再說的男人。
@LarryLu - 我是 Larry，傳說中的 0.1 倍工程師！
@LukaTW - 一名全身都是死角的工程師。
@smalltown - 熱愛鑽研各種可以提升雲端服務品質及增進團隊開發效率的開源技術。
@RicoChen - 熱愛許多技術且努力看透技術的本質，如果有什麼好玩的技術，還請各位歡迎直接找我聊聊。

Feedback

本週呈現主題方式做了一些改變，希望讓讀者能夠更快速精準的找到自己要的資訊。也加入社群活動這個區塊，每週更新社群活動的資訊。如果有任何建議，歡迎私訊星巴哥技術週刊 FB 粉絲專頁與我們聯繫。