iT邦幫忙

鐵人檔案

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

軟體開發隨筆談 系列

其實我原本是只有要報名 Agile 主題,但選太快不小心報錯了,但是又不能撤銷報名。只好把這邊修改一下,如果有餘力就簡單談點去年沒完成的經驗分享吧。

鐵人鍊成 | 共 31 篇文章 | 40 人訂閱 訂閱系列文 RSS系列文
DAY 1

前言

在去年,我嘗試了第一次的 IT 鐵人賽,但沒多久就失敗了。只留下幾篇關於 Issue Description 的文章,和更多的空白文。 今年我重新調整好心態,不...

DAY 2

重構的時機

就讀碩士時,在拜讀《重構─改善既有程式的設計》後,就熱衷於重構相關議題。認為重構很治癒,把壞味道變成美好的架構是一門讓人陶醉的藝術,直到現在仍然如此。 但是在職...

DAY 3

如何導入 Code Review

「為什麼要 Code Review」以及「 Code Review 有什麼好處」,我想前人都已經講的很多了,我今天就不多贅述,先聊點別的吧。 倘若團隊沒有 Co...

DAY 4

為程式碼變動做出解釋

今天比較忙,時間較少,不如就簡單延續昨天的話題閒聊吧。 昨天講到〈如何導入 Code Review〉,既然講到 Code Review,就代表會有一份程式碼的變...

DAY 5

我們都應該要略懂全端

嘛,這是一個比較爭議性的標題。畢竟全端工程師印象中是一個源自於對低薪卻要求一堆的職位需求進行嘲諷的名詞,我不確定是不是真是這樣,但是依照術業有專攻這個前提,有成...

DAY 6

沒有最好的設計,只有最適合當前的設計

在編寫軟體時,若要說是否有一個讓人特別著迷且容易獲得成就感的過程,那麼設計架構應該也是其中一個。好的架構能讓日後維護更加方便,不好的架構只會讓這個專案難以擴充、...

DAY 7

對版控提交變動的時機

我想現在很少有軟體專案不透過工具進行版本控制的,今天就來聊聊透過版本控制工具(revision control system)提交變動的時機吧。這邊會以比較主流...

DAY 8

其實技術債是可以被管理的

原本是想聊聊類似〈MVP 與 Product〉這樣的主題的,但覺得在這之前必須先暸解技術債這個概念再進行比較好,所以我們今天就來聊聊技術債吧! 關於技術債的基本...

DAY 9

MVP 與 Product

每天寫文除了寫文本身很花時間以外,想題目我覺得也很花時間。還好,今天的題目剛好昨天就想好了。可喜可賀。今天就來聊聊 MVP 和 Product,也會把一半的重點...

DAY 10

程式碼風格要點在於一致,而不是優劣

在〈如何導入 Code Review 〉有略提到程式碼風格的議題,提到程式碼風格應該透過自動化去檢核,而不是在每次 Code Review 時仰賴人工審核。然後...