《修改軟件的藝術》
進行一個預期九個月的專案,到第八個月時,我們發現進度比預期晚了六個月。問題在哪?怎麼會變成這樣的呢?
其實我們一直是晚了六個月,只不過我們到第八個月才發現罷了。
—
敏捷迭代的重點,讓你不斷再次確認目標是否產生變化,是否要調整方向步伐,我們是否能如預期般達成目標。
如果不行,在目前的情況下,我們能做什麼是最有價值的行動呢?
在這過程中,避免因為工作任務顆粒度過大,導致資源無法釋放,無法因應變化去選擇有更價值的工作進行,因此承擔機會成本。抑或是得把已經投入資源進行開發,卻仍無法產生價值的半成品放一旁,因此承擔了沈沒成本。
越早發現問題,修復問題的成本與風險越低。頻繁確認目標以及實際的落差、頻繁交付價值、調整行動,這才能應對現代軟體產品的變化性。
我喜歡這本書,也推薦給想要體會在遺留代碼系統中的敏捷實踐為何的朋友。九個實踐如下:
1) 在問如何做之前,先問為什麼做、給誰做、做什麼。(user story template)
2) 小批次建置,每一段之間都是自動化的鐵路,異動量少,建置發生問題時,根本原因越容易找出來,能得到更快的 feedback ,就能更快的做出反應。
3) 持續整合(Continuous Integration), 持續整合說真的跟 build solution 用哪一套的關係不大,重點在團隊能在多快的時間內讓大家寫的程式變成一份並確認執行無誤。
持續整合的有效性與即時性也絕對跟你團隊的分支策略有關。(建議基於主幹的開發)
4) 協作,如何透明順暢頻繁地溝通,又不會花太多無謂的溝通成本,如何確保大家的程式碼理解一致、閱讀無誤。extreme programming 裡面有非常多良好的實踐可以解決這些問題。
5) write clean code,高內聚、低耦合,職責明確,互動簡單,意圖清楚。(簡單設計simplicity 的四條原則)
6) 測試先行,test first, 其實是 think first, identifying requirements first. 在你動手寫產品程式碼之前,總要先搞懂需求的期望是什麼,需求怎樣叫完成。
要滿足使用者哪些情境,才叫符合預期。(這就是驗收測試驅動開發, ATDD)
這才是我們為何要寫程式的目標,接著以終為始,從 ATDD 往下 drill down 多個 TDD 循環以完成所有情境的程式碼,並在每個 TDD 循環中,一分不多一分不少的把力氣花在該花的地方上,並且在每一次的綠燈情況下進行重構。(包含測試程式)
這,才是實務上會 work 的 TDD,這才是為什麼 TDD 是種開發方法論,而不是測試方案。
7) 用測試描述行為,事實上 test-first + test as scenario, 怎麼把繁複的需求功能抽絲剝繭成關鍵情境,並進行排序來達到 baby step 的效果,到這邊6+7 就是 實例化需求(specification by examples)+驗收測試驅動開發(ATDD)+測試驅動開發(classic TDD, 紅燈、綠燈、重構)
8 ) 最後實現設計,意圖導向設計,重構、重構、重構,你得知道怎麼辨識出 code smell, 你得知道重構技巧,你得知道怎麼用最短時間、最低風險,正確地重構你的設計,來讓用的人很好用,看的人很好懂,改的人很好改。
這邊要避免不必要的過度設計,又是一整門學問了。(過度重構也是一種浪費,通常是以 #過度解耦 的模樣呈現。)
9) 從遺留代碼中學習,耐住性子去尊重這些遺留代碼。他們過去有其存在的價值與原因,至少你的薪水可能就是這堆線上又髒又臭的代碼在幫你賺的。
一定要壓抑住自己重寫系統或功能的衝動。
重寫跟重構不一樣的,重寫在實務跟價值上是不會 work 的。
而且,如果每次碰到遺留代碼就想重寫,你就永遠無法具備重構實務產品的能力。
當然,重構之前一定要有測試保護,這也是為什麼你該學的單元測試,是 #針對遺留代碼 如何優雅低風險低成本的加入單元測試。
沒有單元測試的保護,沒有單元測試提供的反饋(自己能做到的獲得最快的反饋實踐就是單元測試),就無法「快速進行較進階的重構」
—
當然,以上有蠻多是書裡沒提到的細節,也是我上課會提到、甚至設計成 workshop 的內容。
寫著寫著沒想到寫這麼多,沒辦法,共鳴點太多了,裡面真的沒啥廢話,也沒啥太打高空的東西。
都是扎扎實實該落地的實踐,要想當個基本功紮實、穩定輸出戰力,要想領的比別人多,就得比比別人具備更多能產生價值的能力。
不要再被你身邊的環境或公司受限住了,那都是你下意識給自己的藉口理由。
你覺得這些東西在你現在的公司工作用不上,所以你不想學。
但因為你不學、不會,又怎麼進得去把這些東西發揮地淋漓盡致的公司呢?人家怎麼會願意用你呢
👉 修改軟件的藝術,請參考 天瓏資訊圖書 上的介紹, https://www.tenlong.com.tw/products/9787115467768
※ 對實踐 5,6,7,8,9 有興趣,想透過實作了解的更透徹的朋友,可以參考底下兩門培訓:
1)演化式設計:測試驅動開發與持續重構 202009,https://dotblogs.com.tw/hatelove/2020/05/08/202009-Evolutionary-Development-TDD-and-Continuous-Refactoring
2)【針對遺留代碼加入單元測試的藝術】202011,https://dotblogs.com.tw/hatelove/2020/05/08/Unit-testing-effectively-with-legacy-code-202011
測試驅動開發與持續重構 在 91 敏捷開發之路 Facebook 八卦
【樓主一生平安】
#熱血,是會物以類聚的。
一位擅長 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/
測試驅動開發與持續重構 在 91 敏捷開發之路 Facebook 八卦
【有用就有用,沒用就沒用】
上課只是學習的起點,課後的實務應用,實務上的撞牆卡關,才能發現內化過程中真正的卡點,而課後在群組上的討論,也是培訓的核心價值之一。
只有協助大家突破實務上應用的卡點,這份知識才能轉換成學員的技能。(雖然課程的內容跟進行方式,就是以各個階段的卡點來刺激大家思考,跟發現不知道的東西)
有興趣的朋友,上過課的夥伴,可以參考一下 張晏甄 是如何在課後開始在實務上卡關,如何一路補足相關的知識,一路摸索出自己的學習路線,透過不斷的練習跟應用,來體會上課內容的精髓。
文章中提到的「Emergent Design」,常見的翻譯就叫做 #浮現式設計,之前有一本我挺喜歡的書名就是浮現式設計,是 Net Objectives 這間公司幾位員工寫的書。
這也是為何我後來把 2018 年的【重構與 TDD 實戰營】課程名稱,修正成【演化式設計:測試驅動開發與持續重構】的原因,因為更貼近了真實設計過程的核心價值。
▍補充
晏甄這篇文章提到的培訓:
① 演化式設計:TDD與持續重構(七月):https://dotblogs.com.tw/…/201907-evolutionary-development-t…
② 熱血 coding dojo(三月底):https://yihuode.io/activities/767
※ 基本上 熱血 coding dojo 還沒對外公開販售,30 席名額就會被老鳥搶光了。
③ 極速開發(十月):https://dotblogs.com.tw/…/2019/02/18/extreme-developing-tra…
※ 晏甄上完 #極速開發 後的心得文在這:https://blog.opasschang.com/…/%E7%B9%BC%E5%AD%B8vim%E7%9A%…/
④ 針對遺留代碼加入單元測試的藝術(十月):https://dotblogs.com.tw/…/unit-testing-effectively-with-leg…
#熱血,是會互相渲染的
分享一下過去三個月學TDD的歷程,另外想問哪間公司或team真的有在用TDD開發或寫單元測試的求收留嗚嗚嗚好想變強喔
測試驅動開發與持續重構 在 202102 演化式設計:測試驅動開發與持續重構-- 心得- 第二大腦 的相關結果
上完[演化式設計:測試驅動開發與持續重構],課後兩個月補記心得和筆記。 熟練Tennis Kata TDD 練習,上傳到Youtube 頻道 ... <看更多>
測試驅動開發與持續重構 在 [心得] 91 的演化式設計:測試驅動開發與持續重構 - Medium 的相關結果
所以這一次,我參加的是TDD 的課程。 這次的課程「演化式設計:測試驅動開發與持續重構」,主要分為兩個部分「重構」與「 ... ... <看更多>
測試驅動開發與持續重構 在 演化式設計:測試驅動開發與持續重構202009 | In 91 - - 點部落 的相關結果
... 探索/分群/排序、邏輯樹拆分、TDD 循環與baby step、迭代堆砌產品代碼增量. 報名這裡去➟【202009 演化式設計:測試驅動開發與持續重構報名表單】 ... ... <看更多>