以我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入魔年代的人特別能體會這篇在講什麼...