2023 年參與技術研討會心得

發表於 2023-10-06 Disqus：

因疫情穩定，今年有較多線下研討會陸續開放，因此我也有機會可以參與社群討論。

今天這篇文章主要只是想聊聊我自己主觀的一些想法。

如同往年，都用騙吃騙喝的參與法－－投稿講師，然後再刷臉進場。除了 DevOps Meetup 外，其他三場都是投稿：

首先還是要先來感謝一下：

感謝 DevOps Taiwan 給我機會亂入分享主幹開發流程。
感謝 LaravelConf Taiwan 給我一個舞台去還一個多年沒還的債（？），原本 2019 年答應要做 Feature Flags 工作坊，欠到今年總算完成（？？？）。
感謝 DDD TW 願意讓我分享學習與實行 DDD 的過程。
感謝 DevOpsDays Taipei 給我一個更大的舞台分享主幹開發流程。

額外一提的是，我在 2019 年也曾上過 DevOpsDays Taipei 的講台，當年是分享功能標誌（Feature Flags），不過當時剛好病號，簡報沒有處理得非常好，從會眾的評價也能看得出不是很好。然而今年在 DDD TW Conf 與 DevOpsDays Taipei 兩個場的會眾評價就結果上來看是有進步的，對我來說也是一種鼓勵，期許自己明年能夠再做出更好的分享。

這些主題中，除了 DDD 以外，其他都是我長期研究並嘗試實作很久的主幹開發或相關的主題。但實質上，拋開名詞定義的限制，我們可以發現這些主題都有關聯。

其中主幹開發與功能標誌兩者的關係是：

主幹開發阻擋使用長期分支的替代方案是改用虛擬分支（Branch by Abstraction，這是我目前覺得最接近它實質意義的翻譯，但跟原文有點落差），並可以透過功能標誌實現。

而功能標誌跟 DDD 的關係是：

功能標誌的功能需要被很好地抽象化，才有辦法輕鬆做成標誌，因此需要透過 DDD 來找出功能的邊界，才能做好抽象化。

例如：原本的登入功能沒有第三方登入的選項，而新的業務需求是加入第三方登入的選項，這時「有第三方登入」與「沒有第三方登入」的這兩件事，就可能會是兩種實作，並依賴相同的抽象類，後續再交由系統看功能標誌的設定來決定使用哪一種實作。

功能的邊界不一定是業務流程上的，也有可能是技術細節，例如：AWS 服務原本都是使用 AWS 所提供的 SDK 處理，但為了想要有更多底層的可控性，因此想改寫成 HTTP 呼叫，這就不一定能透過 DDD 找到功能的邊界。

最後，主幹開發跟 DDD 的關係則是：

主幹開發每個提交要盡可能達到原子性，盡可能不與其他提交產生關聯，而業務需求上的「原子性」，則可以透過 DDD 找出邊界，進而讓不同領域的功能提交不會互相影響。

例如：最近實作的「MFA」（Multi-Factor Authentication，多因子驗證）以及「忘記密碼」的功能。MFA 是在完成帳號密碼驗證後，所做的第二道因子驗證；忘記密碼則是還沒進行驗證時，可以採取的例外流程。單純從流程上來看，這兩個功能是在不同階段發生的，互相沒有因果關係；再以整個身分驗證領域來說，這兩個可能是裡面的兩個獨立的子領域。理想上，兩個領域的功能提交，是不會互相影響的。

當然不免俗的，規劃階段可能還是會考慮到兩個功能的「整合」，例如：忘記密碼透過 Email 發送一次性密碼，並完成驗證的時候，同時就證明使用者持有該 Email 的所有權，因此可能就有機會可以做 MFA 的裝置綁定。但這些整合是在兩個功能完成後，或是其中一個功能完成上線後，才會開始考慮規劃的。

這些做法都是主幹開發所能支持的流程－－多人並行開發（Concurrent Development），但前提都是功能切分清楚，並能夠透過功能標誌有效管理與發布。

結論

寫了這麼多廢話，其實只是想分享：主幹開發是一個方法論，只是在實行過程會發現團隊缺乏很多基礎技能。團隊會在這個過程中逐一發現，並持續學習，直到技能建立起來後，就能夠達成主幹開發的做法。而這些技能，也不是專為主幹開發而存在的，因此團隊學完技能後，也都能馬上應用在平日開發中的。