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