LeSS in Action - 重構

更新於 2022/06/13閱讀時間約 1 分鐘
我們已經了解到了驗收驅動開發持續整合以及壞味道這幾個概念,要減少技術債的方式就是重構,然而在實踐重構的時候並非我們所想像的必須「安排時間」重構,而是在開發的過程中不斷的進行。

重構的目的

我們之所以會認為重構是一種「任務」是因為想要去消除技術債,然而重構是為了讓下一個功能能夠被持續的加入到產品中所做的修改。
那麼,要如何為「下一次修改」而準備進行重構呢?實際上就是我們在討論的壞味道問題。舉例來說,用最容易注意到的「重複」問題來看,假設我們已經發現了產品中有重複的程式碼可以改寫,如果不進行重構重複使用的話,在下一次的時候可能就會變成複製貼上的實作,並且慢慢的累積出更多重複的部分,最後變成技術債。
當我們有測試、持續整合的協助下,我們可以安心的修改實作在開發中不斷的重構消除掉這些壞味道,那麼我們的程式碼品質就會持續的維持在一個相對高的水準。

重新思考重構

其實,卡住我們重構的一大問題是要做大規模的改寫,同時對測試沒有信心。然而我們從驗收驅動測試的角度開始思考,會注意到我們可以從「使用者直接注意到」的地方開始。
這其實也就是重構的定義中「不改變外部行為的前提下,對內部結構的改善」的處理,當我們從最外層開始思考一層一層的修改,也許重構也沒有想像中那麼的可怕。
因為我們不再需要將完整的功能全部修改,而是以一個功能為單位,一層一層的由上而下(Top-down)的改寫,直到最後就能夠將整個產品中的技術債消除,同時因為我們只關注「功能」的實現,如果沒有要修改的必要也可以先不調整,這樣也明確的限定了重構的範圍,相比過去一但開始就會有一大堆實作要一起調整的狀況,也明確許多。

封面圖片使用 UnsplashEugen Str 的作品,這系列的文章只是課程的一小部分,因此並無法完整涵蓋所有概念以及精神,看關於技術的主題可以到弦而時習之找找靈感。
為什麼會看到廣告
avatar-img
55會員
40內容數
軟體工程師逐漸變成一個熱門的職業,當我們進入這個職業之後應該要具備怎樣的技能才會在工作上更加順利呢?這系列的專欄會分享日常工作中的經驗以及一些案例分析,讓我們一起努力成為一位更優秀的軟體工程師吧!
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
蒼時弦也的沙龍 的其他內容
當我們使用主幹開發(Trunk-based Development)、以及驗收測試驅動開發(A-TDD)之後,所撰寫的程式碼會逐漸的變多,也因此我們會開始注意到程式碼有壞味道(Code Smell)的出現。
不同於我們大多數討論持續整合(Continuous Integration)是以工具為主的議題,在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代,也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後,就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同,我們是以 Trunk-based Development(主幹開發)的方式進行,也就是只有 main 一條分支,並且所有人都會提交進去。
完成對功能的了解之後,我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是,我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中,我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
當我們的衝刺(Sprint)完畢之後,還需要對這一次的衝刺進行評論(Review)以及回顧(Retrospective)來對工作的狀況進行改善。
當我們對敏捷團隊有一些概念後,我們還需要了解在敏捷開發中重要的幾個事件,以及這些事件背後所代表的意義以及整個團隊所能夠做的事情。
當我們使用主幹開發(Trunk-based Development)、以及驗收測試驅動開發(A-TDD)之後,所撰寫的程式碼會逐漸的變多,也因此我們會開始注意到程式碼有壞味道(Code Smell)的出現。
不同於我們大多數討論持續整合(Continuous Integration)是以工具為主的議題,在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代,也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後,就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同,我們是以 Trunk-based Development(主幹開發)的方式進行,也就是只有 main 一條分支,並且所有人都會提交進去。
完成對功能的了解之後,我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是,我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中,我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
當我們的衝刺(Sprint)完畢之後,還需要對這一次的衝刺進行評論(Review)以及回顧(Retrospective)來對工作的狀況進行改善。
當我們對敏捷團隊有一些概念後,我們還需要了解在敏捷開發中重要的幾個事件,以及這些事件背後所代表的意義以及整個團隊所能夠做的事情。
你可能也想看
Google News 追蹤
Thumbnail
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題,等你踹共啦!還有機會獲得經典的「偉士牌樂高」喔!馬上來參加本次的活動吧!
Thumbnail
隨著理財資訊的普及,越來越多台灣人不再將資產侷限於台股,而是將視野拓展到國際市場。特別是美國市場,其豐富的理財選擇,讓不少人開始思考將資金配置於海外市場的可能性。 然而,要參與美國市場並不只是盲目跟隨標的這麼簡單,而是需要策略和方式,尤其對新手而言,除了選股以外還會遇到語言、開戶流程、Ap
Thumbnail
本文深入探討代碼重構的定義、原因以及操作步驟。代碼重構不僅是整理代碼,還是專案優化的關鍵。隨著需求變更和人員調動,專案面臨無形傷害,因此進行代碼重構能改進軟體設計,提高工作效率,並降低未來的開發成本。透過解決重複代碼、過長函式、過大類別等問題,最終提升專案穩定性和用戶體驗。
Thumbnail
「所以,你想要用A框架,但又覺得B框架也不錯?」David挑眉問道,一臉的疑惑和一絲不易察覺的笑意。 .... David神秘地笑了笑,「技術選擇可不是簡單的喜好問題,它牽扯到技術轉移的成本、技術負債的累積,還有整個團隊的長期發展。先來聽聽我的想法吧。」
Thumbnail
一款遊戲的開發,肯定伴隨大大小小的修改和調整。 創作者不能怕改。但問題是,改東西需要花時間。一些看似簡單的改動,背後程式邏輯可能要好幾天,甚至幾星期才能修正。 對於不懂程式的人,有時很難判斷東西好不好修。所以今天就來說一下,對程式來說什麼樣的修正會令我們頭痛呢?   先以一個草莓奶油蛋糕為例
Thumbnail
舊網站改版是一個複雜的過程,而成功舊網站改版的關鍵在於確定清晰的目標和策略、基於用戶需求的設計、優化網站速度和性能、保持SEO優化,以及進行測試和迭代。
Thumbnail
這篇文章探討了在軟體開發中的技術債可能來自哪些原因,以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇,提供了對於技術債的思考與建議,針對開發人員在需要做出無奈的技術決策時,提供了一些建議。此外,還提供了一些在做出技術決策時的方法,如保留抽象層和避免vendor lock-in。
砍掉重練…。不知道什麼時候起這四個字成了資訊人員的工作原則之一,但是,只要系統修改的時間超出一定範圍,砍掉重練的時間成本絕對低於原系統修改。 可是在基礎建設的部份呢? 例如伺服器、網路設備方面呢? 其實,砍掉重練也是常有的事,尤其虛擬化後,Server要砍掉重練更是輕而舉。
Thumbnail
追求乾淨的程式碼是好的開始,但不要陷入過度設計的陷阱,導致程式難以維護。實際上,考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況,適時調整工作重心。技術不斷進步,使得寫程式變得更加容易,但這並不意味著工程師的角色會消失。在選擇技術時,也要考慮隱形成本有時簡單的解決方案反而更有效。
Thumbnail
「元件削減」刪除系統中的特定元件,把此元件的有用功能轉移到系統其它剩餘的元件或是超系統(周遭環境中)的元件,實現成本節省、製程簡化、易用易修、提升系統整體效益的目標。本文中大學旅館系的師資削減案例,可突顯了削減對成本控制的實際情況。元件削減常用在專利迴避方面;因元件少於別人專利,可以迴避對方專利。
我們之前講到如果想要降低創業的風險,最好的方法是找到一個對標的對象,這個商業模式已經被驗證是可行的,直接去模仿他的成功路徑。 但我們不可能永遠都在抄,最終還是要做出我們自己的產品。 所以下一步是要去思考哪裡可以優化改善。 最簡單的方式,是可以從價格的角度去優化。 很多的品牌,他的商品都會存在
Thumbnail
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題,等你踹共啦!還有機會獲得經典的「偉士牌樂高」喔!馬上來參加本次的活動吧!
Thumbnail
隨著理財資訊的普及,越來越多台灣人不再將資產侷限於台股,而是將視野拓展到國際市場。特別是美國市場,其豐富的理財選擇,讓不少人開始思考將資金配置於海外市場的可能性。 然而,要參與美國市場並不只是盲目跟隨標的這麼簡單,而是需要策略和方式,尤其對新手而言,除了選股以外還會遇到語言、開戶流程、Ap
Thumbnail
本文深入探討代碼重構的定義、原因以及操作步驟。代碼重構不僅是整理代碼,還是專案優化的關鍵。隨著需求變更和人員調動,專案面臨無形傷害,因此進行代碼重構能改進軟體設計,提高工作效率,並降低未來的開發成本。透過解決重複代碼、過長函式、過大類別等問題,最終提升專案穩定性和用戶體驗。
Thumbnail
「所以,你想要用A框架,但又覺得B框架也不錯?」David挑眉問道,一臉的疑惑和一絲不易察覺的笑意。 .... David神秘地笑了笑,「技術選擇可不是簡單的喜好問題,它牽扯到技術轉移的成本、技術負債的累積,還有整個團隊的長期發展。先來聽聽我的想法吧。」
Thumbnail
一款遊戲的開發,肯定伴隨大大小小的修改和調整。 創作者不能怕改。但問題是,改東西需要花時間。一些看似簡單的改動,背後程式邏輯可能要好幾天,甚至幾星期才能修正。 對於不懂程式的人,有時很難判斷東西好不好修。所以今天就來說一下,對程式來說什麼樣的修正會令我們頭痛呢?   先以一個草莓奶油蛋糕為例
Thumbnail
舊網站改版是一個複雜的過程,而成功舊網站改版的關鍵在於確定清晰的目標和策略、基於用戶需求的設計、優化網站速度和性能、保持SEO優化,以及進行測試和迭代。
Thumbnail
這篇文章探討了在軟體開發中的技術債可能來自哪些原因,以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇,提供了對於技術債的思考與建議,針對開發人員在需要做出無奈的技術決策時,提供了一些建議。此外,還提供了一些在做出技術決策時的方法,如保留抽象層和避免vendor lock-in。
砍掉重練…。不知道什麼時候起這四個字成了資訊人員的工作原則之一,但是,只要系統修改的時間超出一定範圍,砍掉重練的時間成本絕對低於原系統修改。 可是在基礎建設的部份呢? 例如伺服器、網路設備方面呢? 其實,砍掉重練也是常有的事,尤其虛擬化後,Server要砍掉重練更是輕而舉。
Thumbnail
追求乾淨的程式碼是好的開始,但不要陷入過度設計的陷阱,導致程式難以維護。實際上,考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況,適時調整工作重心。技術不斷進步,使得寫程式變得更加容易,但這並不意味著工程師的角色會消失。在選擇技術時,也要考慮隱形成本有時簡單的解決方案反而更有效。
Thumbnail
「元件削減」刪除系統中的特定元件,把此元件的有用功能轉移到系統其它剩餘的元件或是超系統(周遭環境中)的元件,實現成本節省、製程簡化、易用易修、提升系統整體效益的目標。本文中大學旅館系的師資削減案例,可突顯了削減對成本控制的實際情況。元件削減常用在專利迴避方面;因元件少於別人專利,可以迴避對方專利。
我們之前講到如果想要降低創業的風險,最好的方法是找到一個對標的對象,這個商業模式已經被驗證是可行的,直接去模仿他的成功路徑。 但我們不可能永遠都在抄,最終還是要做出我們自己的產品。 所以下一步是要去思考哪裡可以優化改善。 最簡單的方式,是可以從價格的角度去優化。 很多的品牌,他的商品都會存在