九月份梯次的【演化式設計:測試驅動開發與持續重構】,workshop 預計支援 Python 啦!(不過這個梯次已經額滿,有興趣的朋友,請先填寫報名表單,等待明年梯次的開課通知跟搶早鳥啦)
感想:
動態語言在重構上,IDE 能幫忙做的果然相對少。還好動態語言如果是即時重構,要花的功也不算多。
但我真心佩服在動態語言上重構,還敢不寫測試的朋友們,你們太有勇氣了...(靜態語言真的至少還有編輯器幫忙抓 API 上錯誤的地方)
那些用 main() 在測試的人,也真的讓我很佩服,人生短短數十年,真的不該花時間在 main() 跟 print() 上 debug 跟驗證結果。
--
課程簡介與報名,請參考:https://dotblogs.com.tw/hatelove/2020/05/08/202009-Evolutionary-Development-TDD-and-Continuous-Refactoring
同時也有1部Youtube影片,追蹤數超過18萬的網紅公視新聞網,也在其Youtube影片中提到,促轉會今天公布中正紀念堂轉型的規劃構想,將以「反省威權歷史公園」為主軸,改造威權空間與重構紀念敘事,並對園區內主要威權象徵有三大處置措施,包括移除大廳銅像,改造堂體功能及外觀,以及破除園區整體崇拜軸線。 詳細新聞內容請見【公視新聞網】 https://news.pts.org.tw/article...
即時重構 在 91 敏捷開發之路 Facebook 的最佳貼文
【賀!正式成為 JetBrains Training Partner】
能成為 JetBrains 的 Training Partner,其實對我來說是個重要的認同。
雖然,我們一直都不是關注在工具上,而是關注在 #商業價值。
在怎樣的限制底下,透過怎樣的組合、怎樣的工具、怎樣的解決方案、怎樣的方法論、怎樣的協作方式,能幫助我們獲得最大的 ROI,那才是我們關注的點。
軟體產品開發,就像大家說的「又快又好又便宜」是不存在的,那麼我們的目標就該放在「讓我們產品能做得又快又好,自然產品跟服務的售價就可以跟著價值成正比。」
每每聽到團隊在哀時間不夠、技術債太多、產品太難維護,但是:
1) 很少看到團隊在想辦法縮短交付需要的時間(都是在抱怨交付需要更多時間),仍用著土法煉鋼、土砲式的開發工具跟開發方式,喜歡人工處理一切事務再來承擔時間、風險、成本帶來的負面影響。
2) 很少看到避免欠債與定時清理技術債(其實大部分的人 #只懂得欠債的開發方式,而不是時間或環境限制了他們)
3) 很少看到有人在寫完產品代碼的前後馬上加入對應的 #自動測試程式 (不論是單元測試還是驗收測試),然後進行 #持續重構、#即時重構(他們把時間拿來抱怨前人的遺留代碼有多髒多臭多重)
我們擅長用高科技的工具或產品來幫助我們更快交付更高的價值,就跟現代戰爭一樣,一顆巡弋飛彈這麼貴,但只要能達到更高的戰略價值,減少犧牲、增加勝算、縮短需要的時間,那就是個足夠好的投資。
有好工具,也要搭配對的開發方式、正確的方法,才能加乘整體的綜效。
※ JetBrains Training Partners: https://www.jetbrains.com/company/partners/#countries=Taiwan&profession=TrainingPartner
--
成為 training partner 最大的好處是,至少上課的時候,能 request 專門上課用的短暫有效 license,讓大家在上課時能更關注在目標和學習的內容上。
即時重構 在 91 敏捷開發之路 Facebook 的最讚貼文
對作者怎麼會去挑那種沒在實務上用TDD就像吃飯喝水一樣自然的人來當例子,感到疑惑。
幾點不同角度的補充:
1. TDD 導致效率低下,那是人的問題。
也是有人可以因此效率、生產力拉高。
我認同大部分人會效率低下,那是因為大部分人根本沒搞懂「測試驅動開發」、搭配正確的工具使用方式與開發順序,能發揮多大的效果。
2. 手動測試再自動化模擬,以及最後講的BDD很完美,可以知道作者其實在挑的是 classic TDD 的毛病,他個人也是贊同 ATDD 當切入點。
他同時也贊同先想清楚再寫測試或是定好目標再寫功能,差異只在目標如果清楚,可以不用先寫測試,也能寫功能。
但這也有另外一個盲點,正常來說測試寫起來非常快,幾乎就是目標情境明確之後,大腦的想法轉變成測試程式,趨近於講話的速度,有個「可以快速取得反饋」的自動測試擺在那邊,絕對比寫好之後手動測試要來得好多了。
而且別忘了,沒有自動測試就無法有效即時重構,而先有了產品代碼,寫測試就很花時間。
個人覺得作者有這種感受,是對拆分需求情境到每個情境都很小和單純還有些卡點。
TDD 只是一種把想法目標具現化出來後,朝向「simple design」的手段。
ATDD 則是以使用者需求情境為切入點,以終為始的聚焦做法,一開始就把方向定了,搭配「跟情境無關的都先不做」,就能瞬間提升幾倍的功率,避免複雜與過度設計。
BDD 則是希望更站在 domain 的角度、使用端的角度來關注、描述情境與功能使用,甚至能做到連非技術人員都看得懂你的程式要表達的情境,藉此更快速的取得「使用者或領域專家的反饋」
最後,TDD 為啥聽起來很棒,但實務上卻很少看到人家落實、內化、養成習慣?
因為TDD是多門軟硬技能都須具備的綜合戰技,少了一塊效果就會打折。當然,換另外一個角度,把這些基本功等練到十分扎實之後,用對方式一起發揮時,產生的綜效會是數十倍。
要舉個例子的話,就像獵人裡面的:「凝」、「堅」、「周」、「隱」、「流」、「圓」。
基礎功要夠扎實、要能靈活正確結合這些基礎功,還要能持續努力練習、改善與建立習慣,本來就不是每個人都做得到。當然,有個好的 mentor 來帶領著修行,還是很有效果的。
想體會、見識一下怎麼用 TDD 來獲得爆發性的效果,想有人帶著讓你知道你少了哪些基本技能、可以怎麼鍛鍊才能獲得結合之後的綜效:https://dotblogs.com.tw/hatelove/2019/06/22/201912-evolutionary-development-tdd-and-continuous-refactoring
—
我就是那個很自然 TDD 的開發人員,ATDD/BDD/TDD, 可以去問問客戶端一起 pair 過的工程師,我們是怎麼在實務上打通這一整條路的,我是怎麼不斷提問、引導、舉例、示範、動手完成產品功能的。
作者應該來問我,或是跟我 pair 一下的。
--
順便一提,我從來不「要求」開發人員要用「TDD」,我只是會在他們提出某些「問題」時,告訴他們我是用「TDD」來避免或解決這問題的。
TDD 只能是種習慣,不該是種開發規範。
TDD 是用來解決問題的手段,如果你不存在著這些問題,當然不一定需要用 TDD 來開發。如果你的問題有更剛好的解決方案(也就是對你來說,不成問題了),那你也不一定需要 TDD。
即時重構 在 公視新聞網 Youtube 的最佳貼文
促轉會今天公布中正紀念堂轉型的規劃構想,將以「反省威權歷史公園」為主軸,改造威權空間與重構紀念敘事,並對園區內主要威權象徵有三大處置措施,包括移除大廳銅像,改造堂體功能及外觀,以及破除園區整體崇拜軸線。
詳細新聞內容請見【公視新聞網】 https://news.pts.org.tw/article/543855
-
由台灣公共電視新聞部製播,提供每日正確、即時的新聞內容及多元觀點。
■ 按讚【公視新聞網FB】https://www.facebook.com/pnnpts
■ 訂閱【公視新聞網IG】https://www.instagram.com/pts.news/
■ 追蹤【公視新聞網TG】https://t.me/PTS_TW_NEWS
■ 點擊【公視新聞網】https://news.pts.org.tw
#公視新聞 #即時新聞
即時重構 在 [Books]重構-改善既有程式設計-Part2 - Paul Wu 的推薦與評價
重構 改進軟體設計: 經常性的重構可以幫助程式碼維持該有的型態,改進設計 ... 時間預算法: 用於效率要求極高的即時系統,分解設計時要做好預算,預先 ... ... <看更多>
即時重構 在 Facebook 宣布將重構React Native 專案 - 關於網路那些事... 的推薦與評價
可以在任意主執行緒透過javascript進行即時更新UI工作,保持UI即時響應的特性,而不是讓每個UI都在不同執行緒做更新處理。 其次,正在將異步渲染(async ... ... <看更多>
即時重構 在 #即時重構 - एक्सप्लोर करें | Facebook 的推薦與評價
九月份的【TDD 與持續重構】預計可以支援Python 當示範語言了! 用Python 整理完一遍上課的內容,感想是:. 1) 寫Python 沒寫測試就重構,真是有勇氣. ... <看更多>