#純靠北工程師4wl
----------
安安是我，各位遠端工作、上課都使用甚麼軟體呢？
我今天要來靠北我學校遠端教學的問題，強制同學要開啟鏡頭，向全部同學及教師公開你的鏡頭，單純為了點名確認你有在上課。

我以為是使用
Google Meet
Microsoft Teams
Cisco WebEx
Adobe Connect
或被禁用的 Zoom

都不是，而是選擇使用
CyberLink U Meeting

好吧，既然都選擇了，那就試用看看，或許很好也說不定。

但事實是這東西一場會議只支援到 30 分鐘，也就是說我每半小時就要重新連一次，我為了上課一天要重新連十幾次，想要解決這個問題就要付錢，但公家機關不想付這筆錢，就當作每半小時重新點名一次。

蛤？每半小時要重新連線當作點名，那開鏡頭的意義也是點名？在程式重構當中這稱之為重複的程式碼吧？

蛤？相較於其他軟體而言，如果它免費版支援的時間少，那想必附加的功能應該很強大、具有市場優勢對吧？也沒有，就真的沒有其他功能，它就只是個多人視訊通話的軟體。

再來如果你不希望你的背景被公諸於世，那很多套都有支援虛擬背景的功能，而 U Meeting 則是完全沒有，再講一次，它就只是個多人視訊通話的軟體。

----------
💖 純靠北官方 Discord 歡迎在這找到你的同溫層！
👉 https://discord.gg/tPhnrs2

----------
💖 全平台留言、文章詳細內容
👉 https://init.engineer/cards/show/6357

「什麼是 legacy code?」

#修改代碼的藝術 #讀書心得 #LegacyCode

什麼是 legacy code? 已存在但很難改好的程式碼就是 legacy code。

「很難改好」由兩個部分組成。

第一個部分「很難改」，指的是程式碼的可讀性與可維護性很差。另一個部分「很難好」，指的是改完不知道對不對。

Michael Feathers 著重在第二點，也就是當某一段 production code 沒有測試保護，不管它原本寫得多好，物件導向跟封裝設計地再好，對於接手修改的人員來說，仍然存在著改完不知道有沒改對的情況。這樣會使得後續接手人員綁手綁腳，浪費許多時間與重工成本。

反之，如果一段程式碼有對應的測試程式保護，只要這一點成立，要把程式重構以滿足第一點，也就是滿足可讀性與可維護性，也就沒什麼困難的，因為已經有測試程式當保護網。

而這一點，也是 TDD 最前面該建立的觀念，因為開發工法一連串的演進，都是從這裡開始的。

#單元測試的藝術2ndEdition #讀書心得

可以從一些靜態分析數據來挑，哪一些測試好做跟有比較高的價值！

複雜度越高，代表幾件事：
1. 人腦不好判讀，也就容易寫錯，尤其是 condition branch 的部分，bool 一直都是口是心非最常出現的地方。

2. 複雜度高，也很容易是職責攪在一起的地方，職責攪在一起就代表，只要某個職責需求有所變化，這一段程式碼就會被影響到，進而需要進行修改與調整。而只要有異動和調整，就可能會把原本是對的，改成是錯的。所以為這建立測試程式，可以讓後續的回歸測試時間縮得更短。如果要改的就是這一大段複雜的方法，那為他撰寫好完整的測試程式，後續調整或維護的人員，就可以從測試案例的 scenario 瞭解這段程式碼究竟代表著什麼樣的需求與期待。需求要調整時，先從測試案例著手，而不是直接動手改 production code。

3. 複雜度高，如前面講的，通常不好維護、不好讀、職責攪在一起，因此也是重構的優先候選。要重構前，要先建立測試，才能確保程式碼不會因為重構的修改而導致執行結果不如預期。

外部依賴的部分，代表的是耦合性。耦合性越強，代表彈性越弱，代表越容易牽一髮動全身，代表單元測試的可測試性薄弱。因此：
1. 外部依賴越多，可測試性越低，撰寫單元測試程式的成本與時間越高。（重構解耦完才能撰寫 isolated unit test）
2. 若單元測試成本過高，且環境允許使用整合測試，那就適合直接使用整合測試。有了整合測試保護後，接著只要時間允許，需求需要，隨時可以對程式重構進行解耦，解耦完成就代表外部依賴減少了，自然撰寫 isolated unit test 的成本就降低了。

總結
整體投資報酬比依序是：複雜度高且外部依賴低 > 複雜度高且外部依賴高 > 複雜度低且外部依賴依 > 複雜度低且外部依賴高

上面是投資報酬比，但有個簡單的例外情況：線上出錯了的程式，優先順序最高。

最後，舉幾個例子：
1. 複雜度高、外部依賴低：很多純粹邏輯驗證的 validation 屬於這一類。例如統一編號/身份證字號的驗證、不需要太多外部依賴的商業邏輯驗證（例如毛利率要>n%, 訂單金額不可以小於0、某些長度不可以過長、編碼規則驗證等等）

這類 case 很容易出錯，但其實測試成本極低。

2. 複雜度高、外部依賴高：business/domain layer 的物件居多。重點在於職責怎麼切分，接著才是有哪一些是值得解耦的。（完全介面導向+DI的設計，是有點 over design 但不失為一個簡單的 policy）

3. 複雜度低、外部依賴高：如果是正常的，那大概就是一些 pattern 的中間層產物，例如 adpater、model mapping、proxy 類型的。這類即使不寫測試，造成的影響不大，原因是當其他該寫測試的都寫了，一旦 runtime 執行出錯，馬上就可以找到問題可能就在這些中介層或外部依賴。

另外一類正常的，就是貧血的 Dao 物件，不帶商業邏輯，但會與外部資料來源相依，例如外部的 web service, database, file 等 persistance 資源。這類型因為往往不帶邏輯，而對需求來說，想驗證的也是 to end 的 result，所以撰寫整合測試的價值優於單元測試。

4. 複雜度低、外部依賴低：這....好像比較常出現在非 public/internal 的 function，就讓 public 的 test cases 去 cover 即可。如果這樣的方法也是 public 的，有時間就幫他寫測試，沒時間的話，因為他沒啥邏輯，出錯的機率低，可以等到需求異動時再來補測試案例即可。（當然，如果你是TDD，根本就不會有這些問題）