iT邦幫忙

鐵人檔案

2018 iT 邦幫忙鐵人賽
回列表
Software Development

看到 code 寫成這樣我也是醉了,不如試試重構? 系列

參賽天數 30 天 共 30 篇文章 | 65 人訂閱 訂閱系列文 團隊帥哥講師互相傷害團
DAY 1

什麼是重構(Refactoring)

前言 在開始講重構前,先來講個小故事: 臺中都會區鐵路高架捷運化計畫目前豐原到大慶的高架化工程已完成九成左右了。以下撇開政治因素與技術細節,純粹就維基資料來討論...

2017-12-11 ‧ 由 Miles 分享
DAY 2

技術債(Technical Debt)

昨天曾提到,難改的程式通常設計不會太好;程式會設計不好有很多因素,比方說,筆者最常看到的是:因趕上線而寫出設計不好的程式碼。 我們會因為某些因素,而寫出未來難以...

2017-12-12 ‧ 由 Miles 分享
DAY 3

非技術人員所要了解的警訊

Teddy 再談技術債一文有提到,軟體品質有分「外在品質」與「內在品質」。外在品質是使用者直接感受到的品質,而內在品質則是開發者才有辦法感受到的真相。 「魚與熊...

2017-12-13 ‧ 由 Miles 分享
DAY 4

開發者能察覺的壞味道(Bad Smell)

昨天提到,開發者都是在第一線直接被技術債凌虐,是最有感覺的苦主。 在談技術債的時候曾說過:「事後被別人發現的才叫 bug ,自己開發當下發現的不算」,技術債也是...

2017-12-14 ‧ 由 Miles 分享
DAY 5

敏捷與重構

敏捷軟體開發宣言是現正流行的開發精神。敏捷宣言雖然看起來有點抽象,其實背後有十二個原則: 我們最優先的任務, 是透過及早並持續地交付有價值的軟體 來滿足客戶需...

2017-12-15 ‧ 由 Miles 分享
DAY 6

軟體量測(Software Metric)

寫出好維護的程式要靠經驗累積的,初學程式經驗少,因此容易寫出有壞味道的程式。而有經驗的開發者,看到壞味道一定很敏感。但是檢查原始碼的狀況,也是得看人品。運氣不好...

2017-12-16 ‧ 由 Miles 分享
DAY 7

SOLID 之 單一職責原則(Single responsibility principle)

雖然軟體量測很方便,也能找到很多可能有問題的程式碼,但最終還是需要人工檢查程式的設計。這時就需要原則(principle),讓檢視過程能有正確的方向。 SOLI...

2017-12-17 ‧ 由 Miles 分享
DAY 8

SOLID 之 開關原則(Open-Close principle)

原文定義是這樣子的: Software entities (class, modules, functions, etc.) should be open f...

2017-12-18 ‧ 由 Miles 分享
DAY 9

SOLID 之 里氏替換原則(Liskov substitution principle)

一樣要考古一下原文: Subtypes must be substitutable for their base types. 子類別必須要能取代它的父類別...

2017-12-19 ‧ 由 Miles 分享
DAY 10

SOLID 之 介面隔離原則(Interface segregation principle)

Clients should not be forced to depend on methods that they do not use. 直譯:「客戶...

2017-12-20 ‧ 由 Miles 分享