BDD（17）Given-When-Then怎麼寫？

• 用「capture and replay」的方式產生自動化驗收測試
  • 沒有先撰寫一個失敗的驗收測試案例
    • 唔算係BDD
  • 依賴於使用者介面，導致很高的維護成本

如何讀懂別人的程式？

• 睇明人地寫嘅 code 算係一種 reverse engineering
• A Pattern Language for Reverse Engineering
  1. First Contact
     • Read All the Code in One Hour
     • Skim the Documentation
     • Interview During Demo
       • 找懂系統的人來demo，然後在過程中問他問題
     • Confer with Colleagues
  2. Initial Understanding
     • Speculate about Domain Objects
       • 自己建立一個class model 去代表所要解決的問題領域
       • 透過閱讀程式碼來修正這個模型一直到你覺得模型穩定為止。
     • Analyze the Persistent Data
       • 檢查資料庫中的實體（entities）並判斷他們是否代表有價值的物件
       • 可以透過資料庫的實體建立class model藉此理解系統。
     • Inspect the Largest Entities
       • 在幾百萬行的程式碼中很難看出重要的功能位於何處
         • 可以先透過度量工具掃描原始碼，從繼承階層、模組、類別、函數這些對象中找出較大或異常者
         • 從原始碼中判斷這些找出來的實體是否有實作特別重要的功能
  3. Detailed Model Capture：詳細模型擷取階段，包含三個模式，
     • Derive the “true” Public Interface
     • Step Through the Execution
     • Reconstruct the Iterations
  4. Prepare Reengineering：準備逆向工程階段，包含三個模式，
     • Write the Tests（寫測試）
     • Refactor to Understand（透過重構了解系統）
     • Build a Prototype（建立一個雛型）

Composition vs. Delegation

• They are talking different problem
  • Composition is about relationship between objects, which usually compare with inheritance
    • Composition is an “has-a” relationship
      • Composition implies that the child cannot exist without the context of the parent.
  • Delegation is about implementation detail
    • A public class does not contain implementation details, it is defer to other object.

No more flaky tests on the Go team

• Fix the mind set of engineers
• Stop calling your build flaky
  • Fix all random success tests
• Acceptance test builds can never be red
  • Quarantine the flaky test from acceptance test builds
    • When you cannot fix them immediately
• Budget time in the release plan to fix tests
• Refactor to make sure that no duplication is tolerated
  • Test code also need to have good quality
    • bad examples
      • random waits, duplication, massive inheritance hierarchies, weird object mothers, fixture objects that are highly complicated to construct
• Understand the nature of flakiness
  • Most flakiness is due to our own mistakes

是什麼讓軟體架構師成功？

• 文中採取《Software Architecture in Practice》一書的說法
• 軟體架構的定義
  • 軟體架構是理解系統所需的結構，每個結構包含了元件、元件之間的關係，以及元件與關係的屬性
• 軟體架構師的三種角色
  • Initial designer
    • 設計重點
      • 如何滿足重要的功能與非功能需求
      • 確保系統架構的概念完整性（conceptual integrity）
      • 架構最好可以和開發團隊的技能與經驗互相匹配，可以用增量方式開發，並且支持持續整合和持續交付
    • 可能會參與實作，但其實作的主要目的在於製作雛型與驗證架構的可行性
  • Extender
    • 了解現有系統並且尋求擴充與整合方案
    • 架構師需要實際動手操作系統程式碼以便或得第一手資訊
    • 假使增加的新功能不在Initial designer的規劃中
      • Extender便可能需要犧牲原本系統架構的概念完整性以達到擴充新功能的目的
  • Sustainer
    • 責任係避免改變系統的前提之下，儘量將其的價值發揮到最大
    • 最重要的能力是溝通
      • 說服有關人等系統依然可以提供價值
      • 說明要以何種方式持續利用系統的剩餘價值
      • 如何以最小的代價繼續壓榨系統
• 失敗模式
  • Wrap-around
    • Sustainer -> Initial designer
      • 最懂舊系統唔代表識新系統，有可能無法勝任
  • Rising star
    • Extender -> Initial designer
    • 可能沒有受過正規的分析與設計訓練
      • 所設計出來的架構可以符合團隊的技能，但卻可能無法滿足重要的功能與非功能需求
  • Overprotective parent
    • Initial designer -> Extender
    • 不甘心原本設計的架構為了滿足新功能而必須在概念完整性上有所妥協
      • 所以採取昂貴、大規模修改的方式來擴充功能，因此導致系統無法快速交付新功能而被競爭者追過去

用戶故事中的霸主

• 如何切出大小適中的用戶故事？
• 《User Story Mapping》這本書的觀點
  • 由大至小
    • 商業
      • 從企業的角度來看，可以幫助企業達到某些商業上的成果
    • 用戶與客戶
      • 滿足用戶或是顧客的需要
    • 開發團隊
      • 開發團隊能夠在幾天內做完。
  • 管是叫epic或是feature，它們都是一種user story

Don’t fail fast - fail mindfully

• Business make of people, closing business have negative impact and consequences on people and society

5 Questions Every Unit Test Must Answer

• Features provided by unit tests
  • Design aid
  • Feature documentation (for developers)
  • Test your developer understanding
    • Does the developer understand the problem enough to articulate in code all critical component requirements?
  • Quality Assurance
    • Prevent missing features that need testing after change, add, or remove features
  • Continuous Delivery Aid
    • Prevent broken builds from being deployed to production
• A failing test should read like a high-quality bug report
  • What were you testing?
  • What should it do?
  • What was the output (actual behavior)?
  • What was the expected output (expected behavior)?
  • How can the test be reproduced?

Contract Test

• Context
  • 好多時我地會係test create一個test double 去取代 external service
• Problem
  • 由於external service 係第二條team maintain，test double 同 external service 可能會唔sync
• Solution: Contract test
  • 寫test case，用 test double 同 external service 各行一次，再對比結果
  • 唔洗成日行，一日一次己經好夠
  • Contract test 炒左唔一定代表個repo有問題
    • 但都有可能代表production 有 issue，要做urgent fix
  • 可以 copy 份 test 俾 external team，加入佢地嘅CI pipeline，咁佢地 release之前已經可以知道對client黎講，有冇breaking change

增加敏捷性的一種方法

• defer commitment
  • 把做決定的時間點推遲到不做決定的成本大於做決定的成本的那一刻
  • 要有足夠嘅information先做到，就要靠「增進上下游之間的關係增加敏捷性。」
    • 了解user 需要咩feature，了解 UAT 嘅要求