作者thefattiger (LawTea)
看板Soft_Job
標題Re: [討論] 前人的code 後人翻寫的機率高嗎?
時間Wed Sep 26 20:15:37 2018
這位前輩你好，小弟有些不同的意見
※ 引述《accessdenied (存取違規)》之銘言：
: 單元測試有時候反而破壞程式碼的易讀性和維護性
: 因為要做到單元測試，就得斷開所有的相依性
就算沒有單元測試，"高內聚，低耦合"的原則，也應該是適用的
所謂斷開相依性更準確地說應該是"相依於抽象而非具體類別"
Design Pattern有80%以上的pattern都是在做這件事
: 而對抗相依性，作法就是引入 DI。但是 DI 就會增加代碼閱讀和維護的複雜度。
: 舉例來說，如果代碼內有時間上的相依性，例如用了 DateTime 物件取得現在時間做某些
: 判斷，原本可以很簡單的寫出易於閱讀和維護的邏輯：
: If (DateTime.Now > 12:00:00) then return “PM” else return “AM”;
: 為了讓單元測試可以控制驗證條件，只能
: Interface IDateProvider { virtual GetNow(); }
: Class DateMock : IDateProvider { GetNow() { return 13:00 }
: IDateProvider dateProvider = container.Build(....);
: If (dateProvider.GetNow > 12:00:00) then return “PM” else return “AM”;
: 然後再搞個 config 想辦法讓程式吃到你寫的 DateMock 類別....
: 上面是sudo code 就不用討論語法細節
以您提的DateTime為例，若If那行出問題，沒有單元測試的情況下
我們可能沒法馬上知道錯的是DateTime，還是比較的邏輯(可能是>寫成<)
小弟以為單元測試的好處就是在測某個功能時，可以用Mock確保其他東西都是正常的
這樣有錯誤才好抓出來
多加一個IDateProvider有另一個好處是可以應付DateTime不只一種的狀況
例如TaiwanDateTime和USDateTime
: 這就是單元測試的代價！程式真的會比較容易閱讀嗎？
"理想上"的狀況是測試程式本身就能明確表達出需求
讓人能夠只看測試程式而不用去trace又臭又長的商業邏輯就能大概知道整隻程式在幹嘛
: 單元測試要花在切除相依性的條件花費的成本時間遠高於撰寫production code
: 而且你的 production code 能不能賺錢還不知道咧？
: 到底需不需要單元測試和 clean code ？ 先搞清楚寫的用途和目的，你寫的東西有沒有
: 真正的商業價值再說吧。
商業價值跟有沒有單元測試或clean code，應該是沒有相關的
總不是說一個本來會賺錢的專案因為寫了單元測試就不賺錢了吧?
況且單元測試本身就是為了減少開發與維護成本所出現的東西
: 不要把 clean code 和 TDD 無限上綱了
: 工程師最容易自嗨就是這樣，還會自以爲「這是專業」？
: 乞丐的乞討專業比我們強也不會產生「價值」。
就我遇到的狀況都是"我們不要搞那些了，程式能動就好"
倒還沒聽說過因為用TDD，測試程式寫太多拖累整個專案的事情...
寫出易讀、易維護的程式碼也是軟體工程師的職責之一吧!
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 58.114.212.150
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1537964139.A.1A1.html
※ 編輯: thefattiger (58.114.212.150), 09/26/2018 20:16:13
※ 編輯: thefattiger (58.114.212.150), 09/26/2018 20:17:07
1F：推 senjor: 其實我大概知道為什麼這麼多人討厭clean code跟TDD了... 09/26 20:17
2F：→ senjor: 因為他們不懂所以討厭，無法理解所以誤解，因為誤解而厭惡 09/26 20:17
討厭TDD我還可以理解，但為什麼要討厭clean code呢?
它不就是一些寫出可讀性好的程式碼的建議而已嗎?
別的不說，一個專案如果function動不動就上百行，應該沒人想看吧
※ 編輯: thefattiger (58.114.212.150), 09/26/2018 20:22:09
3F：→ Killercat: TDD其實不是一開始就走TDD的話 碰壁是天經地義的事 09/26 20:23
4F：→ Killercat: 這本來就是一個適合從零開始的方法 09/26 20:24
5F：推 accessdenied: 不是因為寫太多測試案例而拖累專案，而是維護太多 09/26 20:29
6F：→ accessdenied: 測試案例而拖累專案。測試案例本身也是程式碼，也可 09/26 20:29
7F：→ accessdenied: 能有bug，再來就是你的商業策略轉彎的時候，大量已 09/26 20:29
8F：→ accessdenied: 存的測試案例要跟著全改就是包袱了 09/26 20:29
9F：→ accessdenied: 但是那些因為商業邏輯變動而不適用的測試案例，要 09/26 20:30
10F：→ accessdenied: 嘛一支支改，不然就是拋棄不用，未來也不會拿來再跑 09/26 20:30
11F：→ accessdenied: 偏偏商業邏輯是變動最快的決策之一 09/26 20:31
12F：→ landlord: 維護測試成本過高，要嘛測試品質很差，要嘛代碼設計爛 09/26 20:34
13F：推 sharku: 測試個案也是需要clean code的好嗎 09/26 20:35
14F：→ Killercat: 這也是一種說法，所以才會有robot framework跟小黃瓜 09/26 20:36
15F：→ Killercat: 這種接近自然語言的東西 請QA/QE來寫 09/26 20:36
16F：→ Killercat: 這些壁其實前人都碰過 不然機器人小黃瓜不會紅起來 09/26 20:36
17F：→ sarafciel: 如果改code要測試全翻 那可能是你的程式基礎架構拆的不 09/26 20:40
18F：推 accessdenied: 感謝樓上大大指點，這兩個關鍵字我去研究一下。我一 09/26 20:40
19F：→ accessdenied: 直以為小黃瓜是女性用品，原來是工程師的良藥 09/26 20:40
20F：→ sarafciel: 夠細 不過我是沒有碰過商業邏輯改到要幾乎全翻的情況XD 09/26 20:41
21F：推 alihue: .net 也有 spec flow，不過 .net core 不知道有沒有要支援 09/26 20:48
22F：→ Killercat: 其實我覺得這發言情有可原 因為一開始就長歪的 要能CI 09/26 20:48
23F：→ Killercat: 跟test driven是的極度痛苦的流程，有偏見也難免 09/26 20:49
24F：→ Killercat: 這一開始就要寫的不要太歪 才不致於以後無法收拾 09/26 20:49
25F：推 accessdenied: 也許我沒見過樓上說的方法，以前看到的景象都讓我皺 09/26 20:51
26F：→ accessdenied: 眉頭，既然時代有進步了，那我再多瞭解看看 09/26 20:51
27F：→ landlord: 時代的眼淚跟可怕的測試，看了跟維護起來真的很嚇人的。 09/26 21:04
28F：→ landlord: @alihue,非驗收測試或跟需求方雙向交流，cucumber非必要 09/26 21:05
29F：推 clarkman: 以前滿常翻code的，但重寫自己就要有認知新的bug要自己 09/26 21:22
30F：→ clarkman: 吞下，不過重構後的code穩定很多，省了後期的debug時間 09/26 21:23
31F：推 rollr: 講的很好耶 09/26 23:09