# 2022-09-30
## Leon's Note
### Interesting Points
- why integration testing? 自動化整合測試，背後隱含的就是事前不想即時整合，如果整合是持續發生的，那應該選擇的是 E2E test 才對
- 只有依賴 3rd party 的部分才需要 mock，不要 mock 自己的代碼
- commit 次數可以作為一種 CI 程度的量測指標，在支持 CI/CD 的環境中 commit 應該多不應少
- 在邊界上減少知道遠方系統的資訊（e.g. wikidata 結構）以減少耦合
- 測試是用來保護、保存已知知識
- 人力測試的價值不是基本的品管檢查，而是發掘出開發者（產品的父母）難以發現的 bug
- story V.S. feature
- story: 做計畫的單位
- 基本上沒人關心過去的 story 是什麼
- feature: 長期維護的功能，由 behavior 和 structure 構成，在每個時間點都是一個切面（space of maintenance），會因為實現新的 item（飛彈）而被炸出坑洞
- 如果有個做法能解決問題，但會離我們的願景更遠，**那就不要選擇它**
- take risk，敢去做不熟悉的事，就是學習
- 執著於對錯（e.g. 就是要遵循 clean architecture），就可能會失去學習一些事物的機會
- 用「機會點」的思維來看待每個發生的事件，例如，代碼發生衝突就是一個機會點讓彼此的設計更趨一致
- 若只把自己的技術集中在某一領域，很快就會被 AI 打敗了
- 工匠精神的 bar，只有自己能堅持以及放棄，不要放掉那條 bar
- The Law of Leaky Abstractions (抽象漏洞定律): 愈來愈多抽象簡便的工具，讓人們離實際原理愈來愈遠（因為只須懂抽象，不須知道具體如何實踐），導致學習軟體其實是愈來愈難的，因為使用技術的人對抽象背後的實踐不夠理解，就無法正確運用技術
- PO 與 teams 的觀點檢視，可以幾個 sprint 來發生一次
- 把學到的東西，馬上全部實踐在生活、組織中，並非上完課後的首要任務；真正最重要的首要任務，是想辦法保存、保護不穩定的新知識
- 原本的環境可能會有各種外力摧毀這些新知
- 上完課回到組織，要先感謝其他夥伴 support 了自己這段時間能夠出來學習，自己與團隊已經有了一個星期的落差，強推新知是不適宜的
- 撰寫 unit test 時要注意是否僅是 mapping 了 prod code 的結構？如果是這種狀況，這種 unit test 就只在創作出來的當下有用，當未來 prod code 因重構而改變結構時，這種 unit test 就不 work 了且反而變成負擔
- 是否為整合測試並不要緊，重點是，關注在 behavior 上！
- Terry: unit test 就是一個小的測試
- unit test 也可以以小型的 E2E 測試的樣貌呈現

### sprint
- 先上線、後 review，delivery 和 sprint 沒有絕對掛勾，因為 intergation & delivery 都是持續發生的
- 因為 review 不是為了檢查，只是為了取得 feedback
- sprint 不是交付的週期，若被作為交付週期，最後就會變成在 sprint 尾聲趕工
- 時間壓力下除了品質下降，人們也會因為 panic 而傾向走老路，選擇用自己習慣舒適的方式工作，而非正確的方式
- 因此為了維護正確的做事方式，在推廣新的實踐時，務必注意是否施加過多壓力
- sprint 的結尾不應有什麼差異，整個 sprint 應該是穩定輸出的，除非有做額外改善才可能加速
- velocity 反映的是個事實，不要想直接對它做什麼手腳或是以它作為績效指標

### 信賴
- LeSS / Scrum 中，各角色的合作都是長期的而非短期過客，因此互信互賴，非常重要
- 建立信賴的方法，就是各角色**真心誠意**地做事
- 永遠基於一個假設：每個人都是在做重要的事，沒有人在刻意浪費時間偷懶，有這樣的相信，就能理解「幫助其他人是重要」這個觀點
- 信心很重要，彼此相信做的決定是最好的決定，就像醫病關係
- 但也要理解，有策略地給予他人信任感的重要性，因為病人往往只知道自己遇到了什麼問題但不懂 HOW

### DoD
- 建立共識是為了透明度，例如 DoD
- 各團隊中所能達到最差的水平，就是我們當前的整體狀態
- PO 本身就要維護 DoD，不能自己在品質上讓步

### PO
- PO 要在 review 時把外部訊息帶給 team
- Don't be nice as a PO，沒 done 就是沒 done，一切以 DoD 為準
- 但沒 done 其實是很正常的事，下個 sprint 再做完就好了

### Clean Code
- 能不寫 else 就別寫，最好 if 完就 return
- return 是個好東西，讓 code 更好讀
- 重構是小步進行，因此中間有些步驟 code 反而會變得比原本還爛
- 對 long method 的敏感度要足後，提升品味、降低忍耐度
- 對 long method 的修改，並不是直接透過 extract 打散它，這樣反而讓追 code 變得更麻煩了，該做的事是找出它內部的其它 code smell 並解決
- long method 的主要作用是吸引 developer 注意，檢查是否有其它 code smell

## Alex's Note
- 早上問題回顧
- 不熟悉的時候，我們只跑E2ETest，逐漸增加單元測試的比例，測試的策略匯回著時間而發生變化．
- 集成測試目的就是避免集成．
- 很多單元測試都綁著這個內部結構
- 先重構測試點，測得還是原本的東西。
- 測試盡量不要用Mocking，除非是依賴第三方代碼的時候．如果是Mock自己的Code. 例如微服務，這樣子就很容易會有問題．
- 單元測試是保護行為，還是保護這個架構設計？變成保護架構設計就沒有意義了．
- 與第三方廠合作，首先也是希望直接整合，能用真的就不用假的．時間要花在風險避免，而不是弄出code.
- Temperature Reading
- Sprint review and Production Release，先上線後Review, Sprint review是為了feedback，而不是quality control.
- 傳統遊戲不太能算是傳統的軟體開發
- Code Appreciation
- 
- Magic number ，拉成一個看得懂的Method有時會比直接抽一個常數好得多，要真正解決問題
- Data clump : 缺乏更好的 Domain Class，可以進行設計．
- Primitive of section , wikidateId是一個String代表WikidataEntity.
- WikiData，P569 發生在系統邊界，他是可以一個PID也是一個Desc，如果同時用PID and DESC 就有兩個耦合，如果只有使用一個，那就只有一個耦合，所以只要用一個就好，
- .Story VS .feature
- 
- 三維 ： 永遠處理在那個時間當下的Structure / Behavior 的狀態
- Impact會弄亂結構，所以持續重構
- Story 代表著是History，Feature 是未來要維護的靜態結構．
- 
- 這邊就是把Story 當成 Feature，讓Feature跟過去狀態綁住
- Common language : 在PBI 叫做 Person ，在code 裡面Human，應該需要修改變成一致
- 在重構中，Long Method , Duplicate Method : 都變成 Long Function, Duplicate function
- Extract Method 不一定那麼有幫助，
- Information Hiding : 跳進去是個Interface.而且實作在哪邊不確定(多形，沒有辦法直接看到實作)
- Escalation 封裝 : 將功能集中在一起．
- 先Inline 到裡面，搞清楚在幹嘛，通常裡面都會有Code Smell，可能要先檢查一下．
- DoD
- Team agreement.對於完成有共同的認知與標準
- 產品與開發端之前有透明度
- 如果DoD沒有Support E2E那代表 PO 知道，需要另外找ＱＡ
- Derivative
- Option 期權 : 實務期權
- Feature 期貨
- 對軟體開發來說，ＰＯ沒辦法獨立管理軟體期權(哪個時間點能夠選擇哪些PBI的權利)，需要團隊幫忙才有辦法達到
- 團隊成長
- Continuous Improvement towards perfection.
- Quality is free
- 沒有Quality 才會產生額外的費用．
- Perfection is not attainable, but if we chase perfection we can catch excellence.
- Vision ：
- 目前最好的想法，也許未來會有更好的想法
- 想法到實現很快
- 沒有Bug
- Code可以直接溝通
- 沒有浪費
- 0秒就可以起開發環境
- 0秒就可以部署
- 隨時可以Deploy
- 我只要寫測試，不寫代碼就可以．
- 度量能達到的最低的水平，就是離完美的標準多少
- 如果有這個辦法可以有效的解決問題，但是遠離DoD，就不要採用
- 不應該會有Trade off.
- Finish and Done
- Finish : 沒有全部完成
- Done : 新生成的
- 開發者用自己的方法與順序，綁架User與PO
- 中午問答
- 
- 應該用目的出發
- 團隊對技術負責，要內部自我調整到可以在Support Sprint 開發，
- 根本上來說是團隊自己要負責，不能砍柴要磨刀，就去做．
- 團隊的技術PBI也可以建立，讓 PO有選擇優先權的機會，但基本上還是團隊自己的是情
- 雙方彼此要理解信任，Team 需要自己有信心，Team是醫生知道如何治病，PO是病人知道發生什麼事情，所以Team要讓PO知到．對自己專業有信心的醫生也不會去問病人著沒樣子
- 
- Interface，團隊內部，不要Publish interface.
- Public interface : 語言特性，只是解決方案的一部分
- Publish interface : 有人用，要維護的 介面
- 對於團隊外部的合作，
- 優先兩邊的人一起做，
- 
- 一部分連他的ＵＡＴ，有問題比較即時，
- 項目管理 ：移除Risk，最大的誤解是工作量，所先做能做的．應該要先解決溝通的Risk，而不是先做一些工作量，不然之後會被反咬．
- 先建立一套測試，先跑那個假設．提供給對方測試．
- 20問題 ：用Test看反饋的合不合理，來找不知道東西（不會故意寫出這個Bug. ）
- PBR 是檢查，Spec / feature，如果這部分給測試人員，他們都在疲於奔命，而沒有辦法做真正的檢查．
- 探索性測試，也是一種技能，只是很難同ㄧ個時間點做到．
- Sprint review:
- Demo : 會用成博覽會的形式 ,
- PO Don't be nice, 沒有做完，就不用看，不要降低標準．
- 收集回饋 :
- PO 也會把新的訊息帶給Team
- Fail Fast : 不要先Defense，讓他跑Exception，產生issue
- Point of View :
- 用這種方式來外顯化每個人的看法
- PO/Team 不是兩個對抗，是同一個團隊．
- Sprint 最後一天，可能會趕工了，步驟跟標準就會有一些差異，一但有壓力，會想回到最熟悉的方式．要幫助一個團隊改進，要注意壓力跟改進不會兩個都得到．
- PO : 可以幫助團隊成長．
- BySprint 收費，這個禮拜 就會專心做這個Feature，就算是沒有完成任何一個PBI
- 幫助其他人，比自己工作的優先序還要高，因為協助其他人更有價值，
- Pair 夥伴會說一直被打斷有問題，可能因為並行太多事情，所以才會被不斷被抓走．
-
- 工匠精神
- 自己一個人，學習很寂寞，而且會專牛角尖，而且對團隊沒有帶來益處，要找導師，要找夥伴。
- 不要放棄對工匠精神的標準，沒有人會在乎有沒有這些工程實踐，但自己不要放棄這個追求．
- 學的東西都會是動態，不要執著在特定的用法，不然很容易會被淘汰．
- As a developer 不要忘記寫程式的快樂
- 
- 兩層迴圈 先X還是先Y ，程式看起來一樣但其實CPU 作業不一樣．
- The law of leaky abstraction
- 邊做邊學
- 角色
- Innate knowledge，不用大學就能夠理解
- Master : 學徒
- 挑戰
- Software is eating the world.
- 軟體越來越難，起的作用越來越大，這software的作用比本業還要有用，然後幹掉本業的事物，e.g. Amazon , Uber ，慢慢的最後都會變成軟體公司．
- AI is eating the software.
- 要成為一個多面手，不要堅守一個部分，不然會被AI 蠶食．
- Retro
- O : Objective : 客觀挖發生過的事項，沒有感覺的部分
- R : Reflective : 反思一過情感上的感觸
- I : Interpretive : 解釋 ：對團隊價值觀，為什麼會發生這樣子的事情．
- D : Decisional ：如果是反方向，我們應該做哪一些事情，來強化或減少．
- 產出
- 會要做到哪三個事情，未來希望能夠做到．
- 跑測試，User Story Mapping , Example Mapping.
- 速率不要去調整，調整之後很可怕
- Manager 可以參加的地方
- DoD
- Overall Retro