LeSS in Action - 壞味道
閱讀時間約 1 分鐘
當我們使用主幹開發（Trunk-based Development）、以及驗收測試驅動開發（A-TDD）之後，所撰寫的程式碼會逐漸的變多，也因此我們會開始注意到程式碼有壞味道（Code Smell）的出現。
重構與壞味道
在驗收測試驅動開發的方式下，我們每一次的修改都是漸進的。每當一個步驟（Step）完成（Done）時就會進行重構調整，以利於下一個步驟的修改來逐步完成功能。
這也表示，我們有非常多機會重新檢視（Review）之前撰寫過的程式碼，得益於這樣的開發方式，我們很容易會觀察到壞味道的出現，進而將這些可能會造成未來維護困難的地方改善。
除此之外，我們會採用結隊程式設計（Pair Programming）的方式，這讓我們在開發過程中隨時都在 Code Review（程式碼審查）並且更快的發現壞味道。
Top-Down 的視角
在驗收測試驅動開發的方式來看，我們在實現功能的時候是由上而下（Top-Down）的方式，以使用者的角度觀察開始，逐步地完成細節。這樣的方式跟以往我們在開發軟體的方式差異非常大。
以往我們會希望了解系統（或者功能）的全貌，並且完整的設計（Design）所需的類別、介面之後，才開始實現功能。這樣的視角是由下而上（Bottom-up）的方式，我們會像堆積木一樣把每一個零件設計好組裝出來。
然而在敏捷開發中，我們會嘗試先使用最容易的方法（Make it Work）將預期的成果呈現出來，並且逐步的切割成小的零件（Make it Right）。這樣做的好處是，如果沒有需要重複使用，那麼只需要等待需要複用的時候進行重構即可。
基於這樣的理由，我們隨時可以在衝刺（Sprint）結束後重新安排任務，即使功能的細節實作並未完成（Finished）也能夠運作，更容易的對應變化而「敏捷的改變」
重構是為了下一次的修改而準備，當我們的程式碼都是被測試以及可以正確運作時就是有用的程式碼。
封面圖片使用 Unsplash 上 Battlecreek Coffee Roasters 的作品，這系列的文章只是課程的一小部分，因此並無法完整涵蓋所有概念以及精神，看關於技術的主題可以到弦而時習之找找靈感。
為什麼會看到廣告
55會員
40內容數
軟體工程師逐漸變成一個熱門的職業，當我們進入這個職業之後應該要具備怎樣的技能才會在工作上更加順利呢？這系列的專欄會分享日常工作中的經驗以及一些案例分析，讓我們一起努力成為一位更優秀的軟體工程師吧！
留言0
查看全部
你可能也想看
Google News 追蹤
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
「所以，你想要用A框架，但又覺得B框架也不錯？」David挑眉問道，一臉的疑惑和一絲不易察覺的笑意。
....
David神秘地笑了笑，「技術選擇可不是簡單的喜好問題，它牽扯到技術轉移的成本、技術負債的累積，還有整個團隊的長期發展。先來聽聽我的想法吧。」
一款遊戲的開發，肯定伴隨大大小小的修改和調整。
創作者不能怕改。但問題是，改東西需要花時間。一些看似簡單的改動，背後程式邏輯可能要好幾天，甚至幾星期才能修正。
對於不懂程式的人，有時很難判斷東西好不好修。所以今天就來說一下，對程式來說什麼樣的修正會令我們頭痛呢？
先以一個草莓奶油蛋糕為例
在這篇文章中，我們將介紹工作與以前念書時期在開發流程上的差異，並深入瞭解CI/CD、Travis CI以及加解密的應用。 CI/CD是自動化的軟體開發實踐，而加解密則是保護機密資料安全的重要技術。
本書大多數的內容都以 OO 的概念出發，詳列了許多設計的臭味道，也有大量的例子。個人雖然不會這樣寫程式，但仍是覺得受益良多，至少在 code review 時能更清楚知道該怎麼描述問題。不過，即便不是用 OO 的概念，有些章節還是可以帶來一些想法，用 OO 概念寫程式的人更不該錯過這本好書。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
列出一套完整的程式
程式設計有許多種方法，不過通常會先列出清單的再逐一執行，這樣會加快程式設計的速度。設計通常會採取順推的辦法。所以順推的程式設計方式就是經歷觀念溝通、系統分析、資料統合、權限管理、頻率與時間、後台管理、畫面設計等等階段後，將框架設計完了以後，先列出一套完整的程式，將所有使用者都確
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
「所以，你想要用A框架，但又覺得B框架也不錯？」David挑眉問道，一臉的疑惑和一絲不易察覺的笑意。
....
David神秘地笑了笑，「技術選擇可不是簡單的喜好問題，它牽扯到技術轉移的成本、技術負債的累積，還有整個團隊的長期發展。先來聽聽我的想法吧。」
一款遊戲的開發，肯定伴隨大大小小的修改和調整。
創作者不能怕改。但問題是，改東西需要花時間。一些看似簡單的改動，背後程式邏輯可能要好幾天，甚至幾星期才能修正。
對於不懂程式的人，有時很難判斷東西好不好修。所以今天就來說一下，對程式來說什麼樣的修正會令我們頭痛呢？
先以一個草莓奶油蛋糕為例
在這篇文章中，我們將介紹工作與以前念書時期在開發流程上的差異，並深入瞭解CI/CD、Travis CI以及加解密的應用。 CI/CD是自動化的軟體開發實踐，而加解密則是保護機密資料安全的重要技術。
本書大多數的內容都以 OO 的概念出發，詳列了許多設計的臭味道，也有大量的例子。個人雖然不會這樣寫程式，但仍是覺得受益良多，至少在 code review 時能更清楚知道該怎麼描述問題。不過，即便不是用 OO 的概念，有些章節還是可以帶來一些想法，用 OO 概念寫程式的人更不該錯過這本好書。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
列出一套完整的程式
程式設計有許多種方法，不過通常會先列出清單的再逐一執行，這樣會加快程式設計的速度。設計通常會採取順推的辦法。所以順推的程式設計方式就是經歷觀念溝通、系統分析、資料統合、權限管理、頻率與時間、後台管理、畫面設計等等階段後，將框架設計完了以後，先列出一套完整的程式，將所有使用者都確
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人