Re: [心得] 花了很多時間重構卻被打槍用舊code

: → kingofsdtw: 正確性，未大量上機無法確定穩定，效能未知 09/14 21:45: → kingofsdtw: 但是code可讀性+100% 09/14 21:45正確性，你是重構別人的code，意思是說，你有測完
【所有】的input 在【所有】的狀態下，的【所有】的output??
當然要包括Exception。
至於可讀性+100%這種心理自high 的，真的無法講什麼，正如有人回應，
你寫的Code 放手一週後回頭看，相信你又要【重構】了。
如果你沒這樣的覺悟，就表示你寫得還不夠多。

台灣人就是看什麼agile, scrum, code review 等爛書，作者們都是沒有
什麼大軟體專案都沒參與過，甚至連programming 嘴得上的作品沒有。
但這些是給不懂開發軟體，沒參與過的人，拿來嘴很好用的。

而 Refactoring, Clean Code 看書名好像是有料之人,結果翻一下作者的經歷，
還是嘴王。偏偏一群人拿出來當神在拜。
但這個對哪些沒覺悟，又想拿功績的人來說，也頂好用的。

真的有經驗談，有含金量的，真的只有人月神話和design pattern了。
但design pattern 也被用爛了。

但...軟體專案，真的不用評估嗎?
哪麼，講個簡單的，不知修汽/機車時，大家會不會要老闆估工時? 就是【多久會好】
這一句話。
然後
waterfall: 時間到了去拿車。
agile/scrum: 天天去問候老闆，看他修到哪。
--
open source projects:
https://github.com/terrylao/

--

這句只是將時程換成自己提而已，但最終還是由老闆來回應不是嗎? 結果不就一樣了。

一個只會騎機車的，在教你麼開大卡車，你會覺得怪嗎? 最慘的是這幾位，可能只有在騎腳踏車而已。 卻嘴出了一套，讓沒做過案子，甚致連寫程式都不會的人，可以拿來嘴。 堂而皇之的稱這是管理。 而這些工作者們，更慘的是也還信了，將這些廢話當聖經了。 小故事，當年的UML 的作者們，一經推出，也是美國大小公司爭相使用，台灣就更 別說了，最好是拉個屎都UML 一下。而當年IBM(UML 原產地) 更推出Rational Rose， 讓你class diagram 畫好即產生code。 現在Rational Rose 都已經停止銷售了，20年過去了，你class diagram 了沒? 人們往往忽視軟體開發是工程問題，而軟體界總是有些新把戲出來， 讓一群人當它是小學生問題。正如常見的三年的資深工程師一樣。 修車修三年，能叫資深嗎? 見人見智。畢境有其局限性，跟修過的車型及遇過的問題相關。 但修車修三年後，變成要去設計一台車，我相信，這就天才加後天囉。