# 2022-09-28
## Leon's Note
### Interesting Points
- 我們追求的是 usable 而不是 reusable
- reusable 其實是一種軟體大害，注意「reuse」跟「消重複」是不一樣的東西，避免一開始就先考慮 reuse, 但要消除 duplication
- 當合作方式變成了 commitment 性質，就會讓彼此更在意 due date 以及文件的完整性
- 用開發產品的方式思考：想想 iPhone，即便不知道自己接下來要做時麼，但下一次發布會卻早就訂了
- 因為沒有什麼罰則問題，跟 project 不一樣之處在於，review 前有什麼就推出什麼
- 注意是否處於 contract game 當中，這種遊戲本質上就是一個說謊的遊戲，大家都在撒謊，而 developer 在這場遊戲是沒有下家的，只能犧牲產品品質
- 嚴格分開組織現況與自己的學習，學習學的是乾淨的內容，而既有組織中可能有許多有毒因子，強推所學反而有害
- 把大風險和模糊的技術層面、不明白之處先行開拓，否則愈後面時間壓力只會愈來愈大，更容易走老路
- cypress 其實只是一個工具去 trigger browser 進行測試的行為，其它類似工具(e.g. testcafe)工具也差不多
- 不應額外花錢在 QA，而是生產過程中本身就應保證品質
- CI 是一種理念，不是工具；CI system 才是協助實現理念的工具
- 進入 flow 後會大副提升 output，但 output 如同飛機重量，應當是愈少愈好
- 能 review 不代表 item done！
- Top-Down 開發就是一種 pull system
- A-TDD (aka BDD / SBE): key example 儘快轉化為文檔以「保存知識」
- 該文檔相當適合以 gherkin style (GWT) 撰寫為 .feature file，好處是該文檔內容能夠直接拿來發給客戶讓他們確認情境
- 豐田的看板（カンバン）與軟體開發常說的看板其實是不同東西，此看板想強調的是有資訊的小卡片，例如輪胎庫存區的供應者聯繫卡片
- 與 software 的看板同名僅是巧合
- Just In Time: 任何行動都是由最初的需求者提出的需求所驅動，就是一種 pull sysyem
- 一次造一台汽車，而不是一次造一千台產生庫存 or 半成品
- SMED (Single Minute Exchange of Die) 快速換模法
- 「說」太多會有很多空想，說太多了就開始做，遇到卡住、缺少要件，就重啟談話，至於如何做是不用預先說的，碰到問題討論時自然會浮現 HOW

### 自動化
- 日語：「自働化（Jidoka）」，其實是自動停下來（Auto-no-mation），在不 work 時能夠自己停下（紡織機）
- 發生問題 → 停下整個產品線 → 找出問題、改善（需要有人 involved） → 重啟 (Stop & Fix)
- 比起把事情自動化，更應優先把精力放在 Auto-no-mation，很多時候自動化倒沒那麼必要

### Develop
- 開發成本 = new feature effort + integration effort，絕不只有 new feature effort！
- 秉持「每個 commit 都會直接上到 production」這種思維，是十分有好處的
- 每當 bug 出現時，在解決 bug 之前，先用 E2E test / unit test 重現，然後才 fix
- 反向測試大都意義不大！因為絕大多數的情況它都不會失敗，也就是綠燈並不一定就是沒問題，也會有測不完的問題；對於反向情境的顧慮，可以試著與一個正向測試結合
- pair 時的 navigator 不能自己去實現想法，driver 則不能實現自己的想法，彼此只能言語溝通，因此 pair 所帶來的巨大優勢就是讓參與者打磨「說人話」的技能
- commit 都用 rebase，形成單一 trunk，這件事唯一的缺點是體感上像是自己的 commit 是 append 在既有的歷史之後
- 不使用 rebase 並產生 merge 分支的致命缺點就是，會竄改既有歷史
- 讓歷史的車輪只會不斷向前滾，不要造成 confused
- 有安裝 cypress-cucumber package，cypress 才能辨別 cucmber 的語法及 file
- 先寫下的 test (E2E / UT) 能夠讓其他開發人員明白新 code 的意圖
- 因此即便是暫時 ignore 的 E2E test，相關 feature 也可以先 push，因為不會造成其他人困惑
- no dead code 的用意在於不讓其他沒有 context 的人困惑生長出來的代碼的用途
- 每個 item 從用戶的角度來看都是獨立的，要嘛能用、要嘛不能用
- 團隊一起有了 E2E 綠燈後，便可以在確保綠燈不壞的前提下，分頭去進行工作，這時的平行作業就是合理的

### Testing
- unit test 如果只是重複 production code 那意義不大
- 在 TDD 開發時，嘗試先用真實的外部依賴而不是看文件或是用猜測的，確定測通了以後才把 golden example 作為 mock 資料
- DB 其實很多時候不是外部依賴，而是邏輯核心，因此 unit test 直接訪問 DB 並沒有什麼問題
- unit test 用的 DB 不宜有 seed 資料，應該每次都清空，且資料不宜真實寫入（e.g. 用 transaction）
-

## Alex's Note
- 認證設定：https://learn.microsoft.com/zh-tw/windows/wsl/tutorials/wsl-git
- 丟一顆球可以，五六七八個球就不行，形容多團隊．
- 屁股決定腦袋，在一個公司中，坐的位置決定了思考的方式．
- 結隊編成：
- 傳播知識,
- 取代code Review，
- 把思想語言化，
- Navigator and Driver 透過這種方式會做好人與人溝通的準備
- 沒有人 Pair，也可以找一個布偶先嘗試說一遍
- Mob : 重質量，同時多個點提供訊息，有沒有辦法Scale
- 最終目的是追求的是沒有Integration 的步驟
- 要習慣PSPI，要調整過工作順序，讓他自然發生，
- Task 重現問題，才是第一順位，使用Accept Test.
- 要著如何測試這個圖片沒有的情況，盡量不測試Negative 的 Test（很慢而且嚴格的條件才會出錯），最好跟正向的Test Case結合,
- Sync 場景：E.g 2+3 =5 (正向), 2 +3 !=8(負向)
- 併發場景 ：負向測試，就算通過，所花的時間也會很長．
- 數學：集合論，如何確認Coverage，沒有辦法包含完整，所以只寫正向
- 
- 
- 重Git要看出歷史，亂七八糟的分支看不出來，
- 
- 要整理Git.要直線性
- 
- Pull and Pull Rebase.
- 用Merge 歷史不是都往前走
- M的訊息沒有什麼意義，而且對別人來說會多出現1的那個點
- 
- Rebase，把基礎變成2 ，再把1放上去
- 
- Rebase 後要先 解決衝突，Mark 成沒有衝突的狀態，再使用git rebase --continue
- 
- 看不出來這一段在幹嘛，有新增Code，但對於其他團隊，他們不知道在幹嘛
- 
- 開發：擴展對我們產品的理解，程式新增的部分都是一個新的知識點，如何保持這個知識點，就是用測試來表達，並且透過閱讀測試，來學習目前的的內容，測試是Nevigation Process
- 有沒有端對端測試保護，提供價值確認？不要做太多技術儲備，往往未來用不到．
- 要拆掉很痛苦
- 也不捨得
- 拆分工作，大家都走習慣的，而不是做風險最高的
- 從E2E Test. 驅動 前端與後端開發，從E2E Test 提示 隊友，我們在做什麼，
- PBI 常常用到User Story 這個詞，轉換成cucumber會變成.feature這種檔案，說跟做，要並行，How的部分會自己生出來，
-
- Q : update是不是比Create更早作，A: Update 可以比Create更早做，
- 理論上PBI 沒有依賴，代表用戶上想要用的事情，依賴是後面上的實現，如果有出現ＰＢＩ依賴，代表 PBR做得不好，為了避免實現上的依賴，就需要持續溝通．
- Reusable software (我們是要能用而不是重用)
- NIH Not Invent Here. (內部結構沒有集成) （消重複）
- 先完成才消重複
- 用Code溝通．Code = 溝通

### 中午問題解答
- Q:  有時候會嘗試做一些讓User感覺的PBI，但是後來User決定放棄，這一些嘗試性功能經過良好的開發，已經很大的改變的既有Code的結構（BSSSSSS），這時我們應該Rollback，還是盡可能維持Easy Change，在新的結構上恢復既有的行為呢？
- 如果持續集成，只會有手動處理，Sprint done 有Finish ，Dead code用Coverage 可以移除，微服務多個代碼庫很難看到這個代碼庫． 沒有保護的東西乾脆不要要，對這個問題要更主動刪代碼，Emirical Process ，一般只會做一些小小的改動，開發理念要支持
- Q: 沒有明確的Due Day 那不同業務團隊間的合作（業務,客服），例如他們已經跟外部用戶都承諾了，那該著麼處裡？
- 降低Quality 沒有意義，在時間不變的狀況下，應該調整的是Scope.
- Contract game : 撒謊的遊戲，每個人都每個人都往下丟責任
- PROD : 在 Due day 內能夠提供多少Feature，
- Project ：在Due day內一定要完成多少Feature

- 豐田紡織
- 
- 機器不知道如何做到快，但是知道著麼停，知道問題，修正後再重新啟動．
- 工人會覺得變成機械的奴隸，但對大野耐一，每一次機器停止都是改進的機會

- 自動化, Automation with human touch.
- 
- Autonomation : Autono mation , Auto nomation. 有人介入的automation.
- Aodon 中文的燈瓏，有問題就會亮起來，豐田是以人為本．測試就是autonomation
- 
- 外部Coach，自動化最重要的就是提供Autonomation.
- 很多時候過分自動化，但是沒有Autonomation，
- Pair Programing ,
- TPS (豐田系統), Zero quality control ，不應該花跟多Quality control上面，應該不斷左移，重Day1 就應該注意
- 心流，進入心流是增加output.做軟體，最重要的是增加Outcome，積極的 找可以打斷的幾會，減少Output的同時，避免Outcome變小。
- 
- 教育開發團隊，產出 Key Example，了解 Command Concept，
- 
- 先敲出Feature的文檔，有多少個Key example已經落實到code裡面，有沒有忘記，變成一個文檔，提交到代碼庫．
- Wording有沒有統一
- 如何度量進度？，我著麼之到我還要多少時間做他
- 在時間盒內，要達到文字上的共識，要有一個Ubilanguage.
- Workshop : Timebox
- 
- Concurrence. (Noun)
- 測試開發並行, the fact of two or more events or circumstances happening or existing at the same time.
- 確認是朝著我們的目標邁進,agreement or consistency
- 要花多少時間，當我發現新Secnairo 再請User 確認，並且提交．
- 要做的事情 是增加透明度，
- Cucumber不是一個最快的方式，他有花成本，要維護很麻煩，所以必要性是很重要的．
- E2E 測試，很花成本，feature form, 透過Step Definitions來跑，
- 要做到一個Biz 需求改變，只需要簡單的更改程式
- 
- 會透過開發不斷修改 PBI的Accept Criteria.
- ATDD是各方面人馬溝通的管道．
- 
- 二戰之後，要學別人造汽車
- 工業化流水線(福特參考屠宰場建立)，在戰後的日本不適用，
- 流水線，如果東西都一樣適合流水線，東西都不一樣不適合流水線
- 日本就參考超市，沒有服務人員，自己結帳，貨架上商品固定，只有沒有了，才會有補充（減少浪費），產生kanban，其實是卡片，並不是大看板．
- 輪胎用完了，才看到看板，上面有輪胎的號碼，跟聯絡電話．
- 希望達到，一輛汽車只花費一輛汽車的成本，如果1000輛汽車的需求，只要作1000次就好，SMED Single-Minute Excahnge of Die.
- 有ＡＢ兩種產品如何達到SMED，驗證方法就是輪流製作A 或Ｂ。
- Pull : Just in time.
- 一開始起名叫Ohno System.
- 二戰戰敗後豐田 沒有 裁員 過半個人，因為靈活性夠．
- David Adenson，SW kanban跟豐田一點關係都沒有
- 
- 他是一個Work flow System ，跟TPS(Toyota Way) Lean 沒有什麼關係．基本上他就是一個Push系統
- 測試驅動開發
- 
- 要如何寫呢？
- 
- 會發現 寫的東西，比實際上 多很多，而且用不上，每次整合都有新的驚喜發現需要改Code，這會是 button up，
- 
- 改成寫一點前端，寫一點HeadCode的後端，通過E2E Test，這樣子就可以達到前後端共識，並且開始往下長，只做必要的部分．
- 
- 一開始會從Top to down，等穩定之後，才會從中間開始進行測試開發
- 舉例 PBI拆成三個Scenario
- 先做GWT 加上@Ignore @WIP WIP 最多幾個，Push，來達到共識，有共識就回頭可以工作
- 一個Loop 1hr ~~ 30 分鐘，舊應該可以完成
- 
- 91補充
- Feature toggle 在 一開始 E2E 測試的時候，
- Feature Toggle不需要最好
- Feature Toggle必須一個Boolean
- E2E 先有不能壞，這要一起做，不分前後端，之後在平行開發．