【樓主一生平安】
#熱血,是會物以類聚的。
一位擅長 java 的同學,之前參加了我的三門培訓:
①【#針對遺留代碼加入單元測試的藝術】
②【演化式設計:#測試驅動開發與持續重構】
③【#極速開發】
他最近再把《#單元測試的藝術》看完了一遍,並將書中的 C# 範例程式碼轉成了 java,其實能自己跟著做過一遍,收穫最大的肯定是自己。
同時也造福了其他習慣用 java 的同學,在看這本書時可以更容易理解書中的意義。
2018 年是我很重要的一年,因為我把上列的三門培訓拓展到了 java, php, C# 三門語言,其中【極速開發】更是能同時用在所有 JetBrains IDE、Android Studio 以及 Visual Studio + ReSharper 上。
我自己對一門培訓要能支援到其他語言的要求很嚴格,這也是為什麼 2019 年的【#DI與AOP實戰】以及【#從重構學會設計高易用性與高彈性API】,我至今仍不支援 C# 以外的語言。
#自己強還不夠,還要能讓別人更強
#別人變強還不夠,還要能讓他發光發熱,繼續影響別人
花了一些時間,把單元測試的藝術又看了一遍,順便把 C# 程式碼轉成 Java
不過有些 Java 不支援的真的就只能讓他去了🤣 (Events, Delegates...)
https://github.com/Coffee0127/the-art-of-unit-testing
--
書中介紹了...
* 一個好的單元測試應該具備哪些特色 (可讀? 可維護? 可靠?)
* 整合測試 vs 單元測試區別
* 何謂假物件 (Fake Object) [很多人會被Library誤導XD Mock, Spy, Stub 分不清楚,很巧的我也曾是很多人的其中一個]
* 本書一再強調他不談設計,但是他推了很多書,例如 Code Complete, Clean Code
* 該如何正確面對一個要加功能但是沒有單元測試的 Legacy Code
91 哥火力支援-https://dotblogs.com.tw/…/13/priorities-for-adding-unit-test
可以加入 單元測試的藝術閱讀交流 社團跟更多人交流
https://www.facebook.com/groups/288261638343874/
--
不過最想講的,還是 9.2.3 引入外援 這章節
> 我強烈建議邀請組織外的專家來幫助導入變革
這邊的專家當然就是業界有名的點火師 Joey Chen 啦
上面說了書中介紹的這麼多東西,大部分在 單元測試實戰操練營 會提到
然而課堂上會被灌輸更多書中沒提到的 (例如:show your intention)
整體來說,我覺得是一堂 濃縮再濃縮、提煉再提煉 的必修課程
// 然後下一步就被燒到接著學 TDD,接著覺得自己寫 code 超慢跟著學急速開發
// 覺得 C# 這圈子好幸福,好多大神
按讚 91 敏捷開發之路 以獲得更多熱血課程😎
https://www.facebook.com/91agile/
di與aop實戰 在 91 敏捷開發之路 Facebook 八卦
解決問題的起點是,「發現問題」跟「面對問題」
學習起點只是知識點,學習的內化則是將知識點與自己既有的知識體系建立成知識面。
會用就好只能應急,只能把別人的詩朗誦地很好聽,但始終無法成為大詩人。
前端的世界更是如此,因為框架推陳出新的迭代速度更快,只有了解了本質,在熟悉新框架才能只需要關注在「差異」、「適用場景」、「優缺點」。
不了解本質,就只能像狗追尾巴一樣,一直被學習新框架搞得團團轉。
沉澱了兩天,其實上完課後還在整理家裡,到今晚才能夠好好再回顧一下上週六日所學到的內容。
這次的「Clean Coder: DI/AOP 進階實戰」課程,在過去的工作經驗中已經有使用 DI 在產品代碼上的經驗,上課前就一直在猜想著 91 究竟會用什麼樣的方式來帶我們進入 DI/AOP 的實作。課程一開始讓我們重新體驗寫個 #乾淨的胖子 開始。接著帶著我們思考這樣樣的程式究竟有什麼樣的問題,並透過重構的手法將胖子瘦身。平時在開發產品時通常寫到這裡就會結束了,看起來很乾淨、又不肥。但事實上卻只是將一坨垃圾分成數個小堆掃到桌子底下,看起來很乾淨,但其實垃圾仍然存在。
#不知道有問題
> 最怕的就是你覺得沒有問題,但實際上問題很多。
這門課最精華的莫過於是 91 帶著大家重新思考每當需求變更時如何以改最少的 Code 來達到目的,如何不動現有的 Source Code,而寫新的物件來取代或組合上去,這考驗著如何在程式碼中實踐 SOLID、OO 等設計方法。
> 什麼是實作?什麼是Flow?什麼是設計?
平時寫 Code 時很容易將需求都直觀的依順序寫下來,所造成的現象是當需求變更時我的 Production code 要修改、呼叫端要修改、Unit Test 要修改,這也是我一直困擾的問題。每當這樣的狀況時我總要額外花上許多心力在修改 Unit Test。91 帶我們重新思考需求與 Code 其實是可以拆開來看的,別一股腦的把需求攤開轉成 Code 實作。要能透過各種設計方式,將物件組合在一起來達到需求。
#動手解決問題
這兩天的課程就是在不斷的思考可能的問題→找出問題→思考如何解決→動手寫Code 的迴圈,每當解決一個問題時心裡總會想到在工作時的某段 Code 也是同樣的問題,我也許可以拿來先試著修改看看,心裡充滿著想趕快動手的衝動。這門課不是在教你怎麼用 DI/AOP,而是該怎麼用這些 Framework 來解決問題?
Resharper 也多學了新招,每次回來上課總能再多學到關於 IDE 操作的技巧,而不是只能看著 vim 的游標在那邊閃啊閃,卻還是拿著滑鼠裝忙…😅
di與aop實戰 在 91 敏捷開發之路 Facebook 八卦
【手很癢】
第二位被燒到的夥伴,上完課的副作用就是手會很癢,當天捨不得睡覺,好想趕快自己再練習、複習一次上課的東西,避免自己忘記那樣的手感,那樣的爽度。
其實能把髒代碼變乾淨,胖子變瘦子,自己從 #不知道有問題,到 #知道原來這樣有問題,到 #自己動手解決問題,腦袋多巴胺會大量釋出,讓腦子跟心情變得好興奮、好興奮。
#熱血點火師 的專業技能,在於怎麼讓大家經歷一場這樣的旅程:
①「覺得自己寫得不錯,沒問題啊」
② 接著「透過提問、引導、需求挑戰,大家突然發現雖然自己覺得沒問題,但其實有什麼問題」
③ 察覺到問題的本質之後,「發現自己不知道怎麼解決」
④ 透過不斷提問、回答、引導、刺激,「腦袋開始有一些抓不穩的想法跟嘗試」
⑤ 看到講師示範後的「恍然大悟」,原來我該會的都會,我只是不知道怎麼靈活應用跟組合知識技能。#趕快讓我寫code
⑥ 「自己動手解決問題」,好滿足,知識點 ++
⑦ 講師:「好了,大家做得很棒,現在再來看看,設計上還有什麼問題?」 眾人大驚?! 這樣還有問題?
~Loop~
其實我的專業在於培訓、在於引導、在於感染、在於喚醒,培訓的有效性,以及課後大家願意持續動手嘗試,在實務上應用,撞牆後有能力繼續往下挖,主動提問跟分享。
自己可以寫出很優雅的代碼,很棒。
但怎麼讓大家都可以變強,讓大家都能想要優雅,讓大家都能優雅,則是一門藝術、一門學問。
第二梯次 【Clean Coder:DI/AOP 進階實戰】,晚了就額滿了:https://dotblogs.com.tw/…/dependency-injection-and-aspect-o…
Joey Chen 真的很變態,這是我這次上完DI and AOP 兩天課程的心聲!
上課中的每個舉例與解法都直指我工作中的痛點,抓問題的能力強的很變態!
只要與課程中相關的內容講解過程中旁徵博引,把相關、不相關的programming 知識與技巧帶進來!這需要懂的東西多的變態啊!
羞辱人的方式很變態!當我以為我懂了,下一個段落就被打臉,用這種方法讓使用情境牢記在心!
點火能力是征服宇宙的變態,這應該不用我多說!
#我要去寫code了
#期待CSD開課
di與aop實戰 在 Clean Coder:DI 與AOP 進階實戰,201909 第二梯次 - - 點部落 的相關結果
帶著大家手把手,把legacy code 重構成乾淨的設計,如何較無痛地引入依賴注入與AOP 設計,讓你具備基本的軟體架構設計能力,從此不再為擴充性跟可測試性 ... ... <看更多>
di與aop實戰 在 di與aop進階實戰 的相關結果
2019 年新課程,【Clean Coder:#DI與AOP進階實戰】,往軟體架構師前進的第一塊敲門磚。 怎麼樣避免成為架構太空人,怎麼樣能捲起袖子針對新系統從無到有,針對legacy ... ... <看更多>
di與aop實戰 在 Clean Coder:DI 與AOP 進階實戰#202205 - 最好的TDD 學習 ... 的相關結果
Clean Coder:DI 與AOP 進階實戰#202205 ... 重構成乾淨的設計,如何較無痛地引入DI 與AOP 設計,讓你具備基本的軟體架構設計能力,從此不再為擴充性跟可測試性煩惱。 ... <看更多>