看著之前用 PyCharm 重構 Python unit test 示範影片,感覺就好爽。
https://www.youtube.com/watch?v=3giSsoBPEU8&feature=youtu.be&ab_channel=JoeyChen
2020 年的最大感想之一,就是 Python 真是個不錯的語言,相見恨晚。如果開發人員本身就具備如何把產品設計得很乾淨、簡單、嚴謹,那 Python 既可以享受 Java/C# 強型別語言的 IDE 好處(透過 type hint),也可以有動態特性的彈性(例如參數個數、型別的不受限制)。
而且,Python 的測試超級好寫!也可以整理地非常乾淨,就像講話一樣的描述需求情境、規格。
Python 越來越多人在用,很多人(駕駛員問題,而非機體問題)卻濫用它的彈性,寫出很糟糕、很難偵錯、很容易出問題的程式碼。有單元測試當保護網,可以更安心建構 enterprise application 等級的系統,也可以安心的重構,減少缺乏編譯器這一層基本保護的風險。
※ youtube 給他訂閱起來呀!
「重構單元測試」的推薦目錄:
- 關於重構單元測試 在 91 敏捷開發之路 Facebook 的精選貼文
- 關於重構單元測試 在 91 敏捷開發之路 Facebook 的最佳解答
- 關於重構單元測試 在 91 敏捷開發之路 Facebook 的精選貼文
- 關於重構單元測試 在 Re: [請益] 這種情況要怎麼重構- 看板Soft_Job 的評價
- 關於重構單元測試 在 為何寫好Unit Test 前需要先了解重構? - Jack Yu 的評價
- 關於重構單元測試 在 91 敏捷開發之路- 【公告】2022 年五月#TDD與持續重構... 的評價
- 關於重構單元測試 在 【極速開發】PyCharm 重構單元測試 - YouTube 的評價
- 關於重構單元測試 在 遗留代码单元测试与重构的一点小体会 - GitHub 的評價
- 關於重構單元測試 在 使用AWS 針對Node.js 應用程式執行單元測試GitHub CodeBuild 的評價
- 關於重構單元測試 在 Re: [請益] 這種情況要怎麼重構- soft_job - PTT職涯區 的評價
重構單元測試 在 91 敏捷開發之路 Facebook 的最佳解答
這個週末玩 Python 有點玩上癮了。
雖然以前不喜歡動態語言,現在倒是覺得,如果開發人員本身就是能把 code 跟設計地很乾淨的人,用 Python 就可以同時享受動態語言的彈性,靜態語言的特性。
好,真是好。
雖然我 Python 熟悉度還是不高,但 PyCharm 我就還是蠻熟的了。
剛好在試著錄重構 單元測試 的影片,就放上來給大家當個參考啦。(我知道大部分的人連單元測試都不寫,產品代碼都不重構了,更何況 #重構單元測試)
有粉絲朋友也喜歡 Python 的嗎?留言+1 刷起來啊~
#相見恨晚
--
YouTube 影片這裡去:https://www.youtube.com/watch?v=3giSsoBPEU8&list=PLNPgPJ-90sSlgKMxFxjRfnTF-kPVFfr6y&index=74
那個頻道上我放了一些示範用的短片,或是一些培訓給學員的課前練習示範影片,有興趣的朋友就訂閱吧。
訂閱的人越多,我又有動力錄影片分享啊 :)
#極速開發
#單元測試
#JetBrains_Training_Partner不是喊假的
重構單元測試 在 91 敏捷開發之路 Facebook 的精選貼文
熱血是會互相感染的。
昨天有機會到台灣少數專精在 HR 領域產品的 MAYO 進行企業內訓。
參與的有不寫程式的 QA, 有幾位是前端工程師,有一位 Android developer, 一位 iOS developer ,其他的都是後端工程師。
不管是用哪一種語言,需求跟情境都是中性的,你可以用不同的語言來實作滿足一樣的需求。
也因為測試的本質是在驗證產品的運作是否滿足了需求情境的期望,所以不同程式語言碰到的問題(例如直接相依的強耦合),設計上的 smell,測試與重構的雞生蛋、蛋生雞,還有不管哪種語言你寫程式速度影響了一切。
大家從一開始對單元測試有著自己的想像(與偏見),到後面自己有能力重構單元測試,發現原來一切都跟產品設計息息相關,一切都跟需求和情境有關。
看測試的角度改從呼叫端、使用者角度去看情境,而不是從產品代碼商業邏輯去對著寫測試程式。
測試案例的設計,能使得產品代碼的設計方式、擺放位置、執行結果符合你的期待,只要位置用法跟你要的不一樣,就跟學開車一樣,總會有紅線提醒你,有東西不對唷。
怎麼避免你的測試過度敏感,就像洗個澡廚房的一氧化碳警報器就會大叫,管理室就會打電話來關心你,最後你不堪其擾,要洗澡就會關掉警報器。那就浪費了當初花時間撰寫測試的投資了。
結論:
去新竹感覺比去南港方便啊,26分鐘就到新竹高鐵站了。
重構單元測試 在 為何寫好Unit Test 前需要先了解重構? - Jack Yu 的推薦與評價
所以在寫好一個Unit Test 之前, 是需要先把程式碼進行重構這樣才有辦法寫出一個好的Unit Test. 但有趣的就來了, 如果先進行重構才去寫Unit Test 又要 ... ... <看更多>
重構單元測試 在 91 敏捷開發之路- 【公告】2022 年五月#TDD與持續重構... 的推薦與評價
本活動將以實務的需求,讓大家針對真實需求進行實例化需求分析、學會如何為真實的legacy code 進行單元測試與重構,最後現場示範重構學員小組的legacy code,再透過TDD ... ... <看更多>
重構單元測試 在 Re: [請益] 這種情況要怎麼重構- 看板Soft_Job 的推薦與評價
我這篇寫的跟原原PO的狀況無關
※ 引述《tbpfs ( https://pse.is/tbpfs )》之銘言:
: 其實我真的不懂為什麼要急著重構
: 有好處嗎?
: 一般而言,重構都是發生在農閒的時候
重構有好處, 而且有不得不做的狀況
我曾經遇到效能瓶頸,
發現是在整個流程順序上只要重新調整並安插幾個預處理的階段就能大幅提升效能
但原本的code就不是很clean, 隨便一個method破500行, 一個class有7、80個method
有二十多個boolean變數當作flag在控制狀態(但其實只要用3個變數就能搞定)
並且沒有unit test作保護
所以:
1. 花時間補unit test、再重構
2. 重寫
2當然最不實際, 1很多公司也不會認同, 所以最後就是直接做重構,
效能最後當然是有出來, 可讀性也提升很多
但老實講, 做的真的很痛苦
平時順手整理code那當然是舉手之勞
用千行來計的重構絕對不想再做一次, 重構完bug還算你頭上, 爽只有爽到別人而已
很多老鳥應該都知道了,這邊建議剛出社會的新鮮人:
就算你知道重構能夠大幅提升效能改善可讀性,
也要裝作不知道, 更不要主動提出重構
被你重構code的人可能會不爽你,
自己做了工作還變多 錢還是一樣,
爽只有爽到其他同事而已
公司大家寫哪種code就跟著寫哪種, 寫爛code搞得難維護更顯得你重要, 反正pm也不懂
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.112.12 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1593049606.A.118.html
就我所知國內不少公司是沒有在run tdd, 就算有, 稍有年紀的公司還是會有legacy code
重構當然還是從簡單的整理開始做起, snippet內的邏輯是能夠確認的;
我覺得把單元測試與重構的成功與否畫上等號是有點詭異的
※ 編輯: EricTCartman (36.231.112.12 臺灣), 06/25/2020 10:47:11
假設有10000行code, 流程會參考某個物件的狀態而變化,
今天重構其中100行, 在這100行內改變該物件的狀態, 補了測試也證明該單元沒有錯
但除此之外還有9900行, 實務上你也會把那9900行的測試補完才繼續重構嗎?
※ 編輯: EricTCartman (36.231.112.12 臺灣), 06/25/2020 11:22:56
不是重構; 但沒重構很難做改善.
重構途中也有可能踢掉重複、冗餘的計算部分
是針對10年前的code進行效能提升, 我不覺得提升效能算是做一個新feature
legacy code沒做測試這是大家都知道的事
做法一樣, 時間跟規模不會一樣, 這你認同吧
※ 編輯: EricTCartman (36.231.112.12 臺灣), 06/25/2020 21:01:02
... <看更多>