作者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/cn.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