Search
開始在實務上展現綜合戰技的效果了 <3
今天第一次嘗試 CodeReview 時拉著夥伴補寫單元測試並試著重構。
一起將原本相依的 class 透過注入的方式解掉。原本相依於 DB 的程式碼，透過 mock 就能夠開始模擬 DB 回傳值，並用單元測試驗證 程式碼是否有如我們所想的執行。
我們也因此找到了程式碼裡的幾個問題，消除了幾個 bad smell 及 over design 的程式碼。
Pair 的過程中不斷的交換彼此的想法，講不清楚的部份就用單元測試把情境攤出來，用實際例子來說明。
這是個 baby step，給我感覺這盒子的第一下反應挺不錯的，讓我會想再來戳第二下、第三下…🤣
【王建興專欄】軟體開發必須面對的Dirty Code
對於程式設計來說，所產出的程式碼，怎樣才算骯髒？為什麼它會被視為「骯髒」？
其實，不太容易找到一個確切的Dirty Code的定義，它似乎包括了大多數程式設計者，對於自己所不喜歡的程式風格或特性。
一般來說，恐怕大多數的程式設計者都會同意，那些「可讀性低」、「不容易維護」、「不利日後修改」、「不利日後擴充」、「沒有考慮周詳完備，只求應急了事」的程式碼，是所謂的Dirty Code。
就像你在程式碼的內容中，如果看到有人「寫死（hardcode）」常數，你可能就會覺得這有點 Dirty，因為一旦想要修改這個常數，就得找出程式碼中所有用到的地方，並且逐一修改，這顯然滿足「可讀性低」、「不容易維護」、「不利日後修改」等標準。
又像是有人使用 goto 之類的指令，大肆在程式碼片段中任意地跳躍，或是使用未封裝的全域變數，放任程式碼四處加以修改、…… 等等。對於這些風格或寫法，相信讀者都會同意還滿 Dirty 的。
另一方面，自從「重構（Refactoring）」的方法問世以來，其中系統性的整理了若干所謂程式碼的「壞味道（Bad Smell）」，像是「重複的程式碼」、「過長的函式」、「過大的類別」等等。
但什麼原因導致程式設計者寫下 Dirty Code？
除了程式設計者的知識和技能不夠之外，另一個引發Dirty Code的重要原因，就是緊迫的時程。
我們也常會看到Quick and Dirty Code 這個名詞，原來 Dirty 是伴隨著Quick而來。為什麼想貪快而不顧髒？有時候是出自於天性，明明知道更不髒的寫法，但就是貪快；更多時候是因為時程壓力太大，為了縮短時間，也只好「冒險一髒」了。
http://www.ithome.com.tw/itadm/article.php?c=83209&s=1
重複 程式 碼是廣為人知的設計壞味道（ Bad Smell ），是不是只要出現重複 程式 碼就需要重構加以移除呢？今天Teddy討論有時候重複 程式 碼也是有它的優點， ... ... <看更多>
程式 bad smell 在 接歪踢- 最近開始讀《重構- 改善既有程式的設計》這本書覺得 ... 的必吃
最近開始讀《重構- 改善既有程式的設計》這本書覺得這本書的編排實在是很棒雖然內容多 ... 有點相見恨晚的感覺這系列文章試著針對每個Bad Smell來提出如何重構你的程式碼. ... <看更多>