---
# System prepended metadata

title: '2022-09-29'

---

# 2022-09-29
## Leon's Note
### Interesting Points
- 團隊 mob 時，4-7 mins 就換手當 driver，可以促使所有人都專注，但是十分累人，最好半小時休息一下
- 寫 code（包含 unit test）的人，要時刻想著未來的自己以及其他人如何能更容易地把 code 改善
- 在新橋造好之前，別拆了舊的橋
- 不要給自動化測試超能力（e.g. 看到肉眼看不到的屬性），手工測試怎麼測，自動化測試就怎麼測
- 寫 cucumber 時首要考慮可讀性，怎麼合理怎麼寫，儘管可能有重複的 code，但因為 step define 一般是很簡單的一兩行，所以問題並不大，最重要的是在**可讀性**絕不能讓步
- comment 是一種除臭劑，但也並非完全不能用，例如較複雜的 E2E 封裝邏輯就可以註解一下即可，不須特意重構
- Terry 並不推薦 clean architecture & SOLID 思維，作為起步點是不錯，但卻有諸多侷限性
    - 《Clean Code》確實是一本好書，但其它系列就逐漸走下坡了，到了《Clean Architecture》甚至有點不知所云
- batch V.S. 1 peice flow: 從摺信實驗中發現兩相比較的結果，竟然是 1pf 效率勝過 batch，理由是 batch 會有許多對最後產出無用的「存取庫存」動作，而 1pf 每一步都是切實需要的，毫無浪費
    - 這是直覺的欺騙性，人類直覺覺得同類型工作分批做，成本肯定會比較低，但並不總是這樣
    - 1pf 雖然感覺慢，但不一定真的慢
- CI 中的 "C" 表「持續」，也是 CI 觀念中最重要的實踐
- 人們計畫很多時候是為了解依賴，以讓個體能夠獨立工作一段時間而不須被打擾；但軟體開發實際上不需解依賴，需要的是持續溝通
    - 對於「獨立工作不被打擾」的追求，是基於對「心流（flow）」的嚮往，但必須要知道的是 flow 對於軟體開發是有害的
    - manager 要擔任「使能者」，移除溝通限制，讓必須要有的溝通發生
- 不用預先花很多時間詳盡計畫，而是 conflict 出現時，teams 再在當下討論，細節集會浮現
- monorepo 的觀念：拆散 repo 對於管理和共有 ownership 就是一種挑戰
- yak shaving 有時也是必要的，但做之前，必須思考是否真為必要
- 有公有地，就有公地悲劇
    - reference: 《Thinking in System》
- problem domain (business) 是提供靈感的來源，例如 refactor 時浮現的設計需求就會參考之

### Refactoring
- 重構不是一個單向過程，假設也可能有誤，可疑的 code smell 也不一定真的有問題，做錯了就還原即可
- 軟體開發產業裡面重要的兩種人
    - Kent Beck 型人：產生諸多重要思維與實踐 → 發明
    - Uncle Bob 型人：整理並轉化成為世俗能理解的內容 → 推廣
- 高內聚的重要性大於低耦合，有時為了解耦合反而會造成更複雜的環境
    - 但低耦合也並非完全不需要，在進行 type 2 重構時，就可能會發生需要先解耦合才能讓未來改動更容易的情況
    - SOLID 講求的是低耦合，但過分追求低耦合就會造就難用又難以維護的代碼
- "no duplication" aka "DRY" aka "once and only once" 是軟體重構最重要的根本

### Teams
- component team V.S. feature team
![](https://i.imgur.com/qFoHXi1.png)
![](https://i.imgur.com/qK1gz3t.png)
    - component team: 依某種標準分出來的 team
        - 分 component team 沒太多原因，就是直覺（快思），然而通才比專才更有用處
        - 應對現代社會複雜議題，要多使用慢想
    - feature team: 以 user 價值為中心
        - 作為管理者，不會輕易拆散 feature team，feature team 的團隊生命週期相對長
- 當一個 team 達到內部語言、外部語言一致的時候，那就是 feature team
    - common language 來自於 solution domain 以及 biz domain 的交集處
- code review 不要太 focus 在 style 上，而是應多花費心力關注 intent
    - 因此建立 convention 即可讓大家不再費心於 style 部分
- item 塞太緊，就會對各種打擾很敏感（因為覺得時間不夠用）
- bug 是沒有在排什麼優先級的，來了就是請 bug 主人 stop & fix
    - i.e. auto no mation 的精神
    - 但如果沒辦法立即找到主的 bug，依然是最優先級，但可能會需要 PO 稍微安排人力處理
    - item 拿太滿也會難以騰出手妥善地修復 bug，SP1 拿 item 最好是取前三次 sprint 的最小值
- PO 與 teams 應當充滿**信任**，因為彼此是長期合作的關係，在頻繁變動 sprint 任務的情況下（e.g. 插件）的情況下，信任將蕩然無存
    - PO 應是保護 teams 不受外部政治勢力的影響，而不是主動帶來政治壓力

## Alex's Note
- Timebox :  
	- 需要止損  
- 不需要Pre-Task. Photo Type，按照原有流程才能得到有意義的反饋，  
- 送出去才有辦法度量，例如AB test，  
- 可觀察,3V,的PBI，從外部可度量，如果還沒有可度量的方式，要優先建立．所以如果以pull的方式開發，那就就會從上到下。  
- Mob ，其實是可以Remote 有一些可以Tool可以達到  
	- Role  
		- Diver  
		- Navigator  
		- Observer  
	- Time Driven  
		- Time : 4- 7 分鐘，要非常專注，因為再下來就換他了，所以四十分鐘可能會休息  
- Code Review(比較有責備的意味) VS Code Appreciation(凸顯可以學習的部分)  
	- ![Imgur](https://i.imgur.com/rO2uHEc.png)
		- 下面的Case變量不凸顯，要使用Data Table表示，閱讀會比較清楚  
		- 還沒有需要驗證的部分可以不用急著用表來實現  
		- 以DOM的角度，要驗證是否看得到，Cypress Get不會驗證，Cypress find 會驗證．  
		- 不要拆橋，Don't burn the old bridge ，新的功能還沒有完成前，舊的要保留不要拆掉  
	- ![Imgur](https://i.imgur.com/3BRtKoK.png)
		- 使用全局變數會不清楚 Arrange / Assert 彼此的關聯  
	- ![Imgur](https://i.imgur.com/Bq9xPb4.png)
		- data-testid 是為了精確找到地方，理念是盡量不使用，原因是 E2E與UT都是模擬使用者行為，所以自動測試應該模擬手工測試，不會用testid，而是盡量模擬以手工使用的角度，來寫這樣子的測試．  
		- comment ：就是空氣芳香劑，只是用更強壯的味道蓋過  
		- 為了表現出，這段程式碼在幹嘛，用抽方法的方式可能沒地方改．新增這個方法到lib可能會比較好．  
	- ![Imgur](https://i.imgur.com/Bhk9XZ3.png)
		- Biz Rule，用Example 數據驅動測試．  
		- ![Imgur](https://i.imgur.com/oh6uec3.png)
		- 只是代表一個Case.並不是Biz Rule．  
		- ![Imgur](https://i.imgur.com/SJfZljH.png)
	- 在寫cucumber test  
		- 要先優化可讀性，不能在可讀性退讓，共識不對就沒有意義了，而不是追求可重用性  
		- Step definition通常不會做具體的事情，而是封裝到Command, Traceability(DSL)，或是用PageObject，模擬User可以操作的行為(PageObject)，Page Object沒有數據只有狀態．  
	- ![Imgur](https://i.imgur.com/vltrbaX.png)
		- Feature Envy：既然都是WikidataService執行，為什麼不要WikidataService做就好  
		- Duplicate：getWikidataLocation與getWikidataHuman description 很類似  
		- wikidataId沒有這個類別，就會變成放在其他地方，其他地方就會變得複雜  
	- Team與Team做事的不同  
		- TW都沒有寫進資料庫，其他地方第一時間寫進資料庫  
	- Clean Architecture 不是好的方式  
		- 原創  
			- Kent back : 發明了很多好方法  
		- 打包  
			- Uncle Bob : 整理很多好方法 , SOLID 是一個好的起步點，但有局限性．  
- 豐田製造系統  
	- 一次做一個汽車  
	- 寄信Case  
		- 步驟  
			- 折起來  
			- 塞進信封  
			- 封口  
			- 貼上郵票  
		- 方法  
			- 批次  
				- 一次一個步驟全部  
			- 一次一個  
		- 預測快多少  
		- ![Imgur](https://i.imgur.com/od6YqVL.png)
		- 實際  
			- ![Imgur](https://i.imgur.com/JdOYw6q.png)
		- 為什麼會這樣子  
			- 放進倉庫沒有貢獻，造成累積．  
			- 一步做完沒有浪費  
			- 直覺不見得對  
			- 軟體開發，一次完成端到端，是感覺慢，不一定真的慢．  
			- 一個full cycle feedback，才會提供全局經驗，如果Batch Model，可能是區域經驗．  
			- 整個火箭組裝的時間會變成，因為太多test.中間層次拿掉，增量沒有那麼大所以不會影響太多  
		- CI : 持續集成，代碼要有用，  
		- ![Imgur](https://i.imgur.com/G1A6oCW.png)
			- 口頭 會討論，程式 還會討論  
			- 構通計劃 ：解依賴，可以分頭行事，就不是持續集成  
			- ![Imgur](https://i.imgur.com/ojGAeMr.png)
				- 用講的  
				- 用代碼溝通  
				- 管理階層 要 想辦法把 把約束拿掉  
				- 平行工作室ＯＫ，但不是獨立不溝通的溝通．  
		- ![Imgur](https://i.imgur.com/cddtDRC.png)
			- 所有的代碼都是共有的，每個人都可以改別人的代碼．  
			- 用Code來溝通  
			- 微服務各自有各自個子Repo，但大公司都是用Monorepo  
		- 公地悲劇  
			- ![Imgur](https://i.imgur.com/8RabCk7.png)
			- 教育規勸  
			- 私有化  
			- 靠系統化規範  
- 中午問題討論  
	- ![Imgur](https://i.imgur.com/bti5SJO.png)
		- 就算以How出發，還是要轉成What  
		- UX 會在how 階段 Join，太早其實會造成不同的語言．  
	- ![Imgur](https://i.imgur.com/fvIhjUX.png)
		- 放在component team也不太適合  
		- 通用技能性的使用不應該侷限在特定團隊，盡量讓每個團隊了解再一起．  
	- ![Imgur](https://i.imgur.com/n9XGGEb.png)
		- Task 拆分沒有固定格式  
- Yak 氂牛 Yak shaving ，為了達成目的，去繞了很多很多路，開發環境就真的需要Yak shaving，不然其他東西就不能往下走．  
- Less Team  
	- ![Imgur](https://i.imgur.com/pDWLdAh.png)
	- ![Imgur](https://i.imgur.com/Ax895hZ.png)
		-  
		- 當有業務需求進來，A1B1, B2C1, A2C2,  
		- ![Imgur](https://i.imgur.com/9CKbewg.png)
		- Ｃ團隊因為比較獨立，就沒有集成業務需求 因為要找Ａ與Ｂ，為了保護成面，就會做很多技術儲備的事情  
		- ![Imgur](https://i.imgur.com/3ytx2dM.png)
		- 因為Ｂ和Ｃ對接不上，所以開始找Ｃ，然後B2C1 就會有問題  
		- ![Imgur](https://i.imgur.com/OBqchY9.png)
		- 然後就會有一個Undone的Backlog.  
		- ![Imgur](https://i.imgur.com/70aSq1S.png)
		- 漸漸的Dependency就會發生在需求端  
		- A會慢慢產生防護層，越來越自閉，而且質量越來越往下滑．  
		- 而且A只能講Ａ自己的語言，都是只剩下技術層，會變成BA需要來做橋接．  
		- ![Imgur](https://i.imgur.com/9YyfjNd.png)
		- 依賴發生在同一個Sprint, 衝突發生，就產生增加溝通的機會，當下開一個小會議就解了，不用預先花很多時間做這些事情，就可以不斷的集成，  
		- ![Imgur](https://i.imgur.com/96R1jUa.png)
		- 讓不同人帶來不同的理念，新技術，對整個團隊就會提升  
		- ![Imgur](https://i.imgur.com/rLNMR7W.png) 
		- 如果有不熟的領域，就用 Take Small Bite or 去問  
		- ![Imgur](https://i.imgur.com/TFbhnOT.png)
		- 每個Team都熟業務領域，並且所有的腳色功能都了解．  
		- 什麼時候團隊是Feature Team？  
			- 解決以用戶問題為中心的團隊．用Biz language 做溝通．  
		- Feature Team不是一個人在完所有的工作  
		- 傳統的團隊是Specialist，Feature Team強調的是General Specialist  
		- Feature team 最重要的技能是 multipule learning  
		- 存在週期：不限，不會有意義的拆開這個團隊來做優化  
		- 局限與極限 of Feature Team，Product focus 應該從產品來看整個開發．  
		- 部門已經是component ，先在內部Feature在往外做  
		- 目標提供環境，幫助團隊學習．  
		- 部門用componet就很直覺，是一種快思無法解決比較複雜的問題  
		-  
- 問答  
	- ![Imgur](https://i.imgur.com/dndZv7n.png)
	- 能夠完成會變小 ，每次的Sprint 都會變小，前一次的Bug 會 會影響了下次的開發  
		- 少產生一點Bug  
		- 改前面的Bug  
		- Stop & Fix  
	- Bug 沒有優先級，要馬上改掉，不需要任何人的同意．老Bug 要預留團隊Resource．  
	- Current Arcitecure workshop  
		- Sprint - > Sprint -> Domain Model.  
		- 使用 N+1 視圖  
		- 找到的問題，或是架構問題，等同於Bug and PROD issue  
		-  
	-  