以我20年的经验来说，什么敏捷，设计模式，很多都是脱裤子放屁。
更早期还有什么OO方法论，部分人神鬼上身，什么东西都要OO一下，连写个九九乘法
表都要开一个 class ninenine。
就好像1995年，C++锋头上的时候，说C++难用的会被一堆脑粉抨击，不外乎就是说，
不是C++难用，是你不会用。
这是不是跟太极拳很像？太极拳多强，打输泰拳，脑粉会跟你说，不是太极没用阿，
是你自己没有把太极的精髓发挥出来。
到最后这根本就是信仰了。但时间会证明一切阿，C++就是产能低落，太极就是打不赢
综合格斗。
回到正题吧，有一段期间我们公司也导入设计模式，搞到每一个简单的动作都要有
USECASE，你能想像这是怎么回事吗？这就像建构式数学，明明简单到可以9x5=45的东西，
他规定你要9+9+9+9+9。
工程师是人，不是白痴。每一个输出入函示都要UNIT TEST？有些简单到如同9x5的东西
你真的还要替他见一个UNIT TEST？单步追踪一次就够了吧，里面程式码没几行，还是
呼叫共用的函示库，这能出错叫做共业，根本不需要花时间在这种地方演戏。
后来我们导入设计模式大约一两年后，大家就慢慢不了了之，很多状况都是慢慢不了了
之的，没有人会愿意出来说，我们当初想法天真错误啥的，就一切尽在不言中了。
作者:
prag222 (prag)
2018-04-04 23:14:00有感 CRUD功能 又不是啥敏感重要资料也样unit test 哈更何况不是写UNIT TEST就不会有BUG?写了=0 BUG?
作者: sam7159 (sam) 2018-04-05 00:00:00
有同感
作者:
sorryla (Mr.东)
2018-04-05 00:24:00C++产能低落的话就不会还这么多人用了
设计模式会弄到任何动作都有 Use Case?这设计模式和我学的好像不太一样……
我觉得是你公司导入异次元的设计模式另外 unit test 不是用来防 bug
而且每个输出入函式都要写 Test Case，这是多久前的观念啊……现在很少人用单一函式来定义“单元”了吧？
是用来保护后续对该 funtion 的修改不会破坏既有行为再简单的方法随着时间和需求总会慢慢变复杂有个 unit test 在那边至少要重构或修改该 function会比较单纯附带一提，凡事都要有 user case 比较像物件导向参考 Object Oriented Software Engineering 这本书然后你对 unit test 的误解建议你观看这本书xUnit Test Patterns: Refactoring Test Code
作者:
sharku (明珠求瑕)
2018-04-05 01:32:00奇怪, 设计模式跟unit test的关系是?
作者: megawalker (小智猫) 2018-04-05 02:13:00
觉得脸肿肿的...
UnitTest 是针对工作单元 而非 method 吧....
作者:
Eos (美丽时光)
2018-04-05 02:44:00推
作者: rabido 2018-04-05 06:40:00
贵公司对技术上的误解好像颇大的...
作者:
Argos (Big doge is watching u)
2018-04-05 08:53:00混了20年 结果对设计模式的适用与否与UI本质还搞不清楚？这样也可以混20年 你瞧程式设计多好混？ㄏㄏ时间早就证明一切囉 不要说FLAG的code好了 就连程式语言本身内部也满满都是设计模式的应用喔～呵呵还是说Google Apple FB都白痴 就你们公司都天才？
作者: sayya2311 (ya) 2018-04-05 09:00:00
推工程师不是白痴. 有些囉囉嗦嗦的事做完, 结果解决的事情的难度都还不比国中的数学难...那为什么选择不相信你的工程师,或改找有合格水准的人进来?
作者:
darthv (闲谈莫论国事)
2018-04-05 09:12:00scrum以前叫standing meeting,换汤不换药还好我写kernel，不用跟一堆c++搅和在一起
如果只有自己写的 project 做 unit test 的确很烦但一但要修改别人的逻辑时 就很有用好吗...
作者: jfang 2018-04-05 10:03:00
同感
作者:
maxqq (max)
2018-04-05 11:35:00应该就是当下规范导致不好用吧，习惯就成自然太过自信未必是好事，很多事情还是战战兢兢来得好
作者:
alihue (wanda wanda)
2018-04-05 11:51:00还好我们公司没这种老屁股
作者:
robler (章鱼丸)
2018-04-05 12:20:00觉得是你不会用，不是test case没用
作者:
Masakiad (Masaki)
2018-04-05 12:42:00写的出这种见解我也只能说20年的经验跟1年的差不多.....
作者:
Sirctal (母猪母猪 夜里哭哭)
2018-04-05 13:59:00混了20年连 design pattern都搞错??
作者:
Masakiad (Masaki)
2018-04-05 16:07:00如果是我被得罪我一定可以包涵，但讲错误的讯息出来误人子弟是很不好的事情。
作者:
testPtt (测试)
2018-04-05 16:15:00C++产能低落要看用在什么地方
作者:
final01 (牛顿运动定律)
2018-04-05 18:56:00这20年？比大学毕业还糟XD
搞到每一个简单的动作都要有 USECASE每一个输出入函示都要UNIT TEST有些简单到如同9x5的东西你真的还要替他见一个UNIT TEST这些问题 是这么决定的人造成的 无关方法跟工具啊拿刀割自己再怪刀子不好的港节
台湾风气是 all or none, 引进一项制度就要全体采用oo 很棒, 所有架构都给我改成 oo, scrum 赞, 都给我用
还好吧，真的就是这样阿不过果然又有脑粉出来：是你没了解太极的精髓 ccc就算我只有一年经验，可能也屌打你10年经验吧
不如你说说其他语言在什么情境屌打 C++?至少先定义你说的产能是什么？
无关精髓, 只能确定为了用而用才会用了以后一堆抱怨
作者: kira1101 (肉包) 2018-04-06 00:45:00
快去出书证明你的理论 肯定被当大师膜拜敏捷与设计模式无用论 by YAYA6655
楼上出书好了。我淡然处之。总之我不用就是 :)不过你出书我可不捧场，总之我不用:)脑粉：是你不会用，不是它没用。
用以前要先弄清楚有没有用 若没用一开始不要用就没事了
作者:
sorryla (Mr.东)
2018-04-06 02:01:0020年经验学到的是讲不出道理只会讲人家脑粉，受教了
作者:
alihue (wanda wanda)
2018-04-06 02:11:00还好我公司的老人强多了
作者:
Masakiad (Masaki)
2018-04-06 07:33:00一言不合就把异己变成脑粉，通篇没有真正讲中scrum oo unit test的一些问题，像个初学者抱怨玩具烂我不玩，还一个老前辈架子出来劝世的态度。还偷换概念变成太极拳打泰拳斗输赢，这种工具不但没输赢还可以截长补短，举例：很多语言可以oop也能fp。所以你是真的20年来都观念错还是想偷换概念呢？
说20年经验又说离开业界很久,言之无误.看起来像钓鱼
作者: jame2408 (冰) 2018-04-06 14:42:00
内文举例一堆错误, 设计模式与 ooad 有啥关系? 针对 unit test 的单元认知太狭义! 以上名词都只是工具, 面对不同问题使用, 不是学新东西就乱用, 然后抱怨不好用!可以写使用后感想, 但不要写一堆错误观念, 误人子弟!
作者:
gname ((′口‵)↗︴<><...<><)
2018-04-09 15:35:00有经历过早期OO入魔年代的人特别能体会这篇在讲什么...