ADZ 學習筆記

Ruby/Rails, Startup, Life

rails 筆記 - 重構計畫

| Comments

為了要有更好的系統擴充能力,在發展系統功能的時候我們常常要在 refactor 與新功能間奮戰,今天被公司的人問到該怎麼估 refactor 計畫的時程,以下是我自己在開發時的方法。

開發過程中就要 list refactor idea

像是 refactor 這種沒有終點的行為,應該在開發功能時,為了避免完美主義手癢把軟體過度工程化,我通常會先以 user story 上的目標盡快完成,如果了解未來軟體擴充方向,在開發的時候可以把一些 refactor 的 idea 先 list 起來。

如果說 user story 對應到的是一個商業價值的話,refactor idea 對應到的則是一個有利於系統或開發的價值,也許是增加 performance、也許是增加設計彈性、也許是 DRY 未來的程式碼。

不過現在覺得有價值的東西不一定未來真的會需要用到,通常系統怎麼發展還是要看商業上怎麼發展,而且很多時候的需求其實都只是自己的假設而已,所以 list 這些 idea 我會順便紀錄下當時列出的原因跟目的,例如:

  1. 把 xxx 資料物件化 (未來在 yyy 擴充需求時會用到)
  2. 把某些資料計算改成 lazy loading 並 cache 起來 (增加運作時的 performance、避免不必要的計算)
  3. 把某些資料改以 callback 方式來組織增加橫向擴充能力 (未來增加 xxx, yyy, zzz 功能時不需影響主體)

DONT DO

以前做法不順暢的原因通常是把 開發Refactor 拆成兩件事情,導致當非不得已需要 refacotoring 的時候才開始想要怎麼做,然後就會發生:有能力計畫的人時間被塞爆,剩下的人閒置又無法開發新功能。

Planning

只要在開發中有去思考以上這些問題,第二階段要 refactoring 的時候其實就像在做 sprint planning 一樣,依照目前的發展狀況對最有價值或最重要的 ticket 先做就可以了。 (把 idea 拖到要開始 refactor 階段後會發現很多東西其實都不需要實作)

如果在開發中產生的 idea 可能過於抽象或太大,確定要做的 ticket 這時候可以釐清細節並拆成更小的 ticket,這時候的 ticket 就是估得出來的時間了。

捨比取重要

另外我想在面對 技術問題 的時候很多人都會有這樣感想:選擇不做什麼 比起 要做什麼 是還要難決定的事情,因為每樣東西感覺都有其價值,差別是這個價值反映在商業上是 現在未來 亦或是 另一個平行宇宙,所以最好的狀況還是 RD 貢獻的產出能隨著公司發展而發展。

實踐心得

其實這些想法是基於上過 xdite 的敏捷開發課程,對我而言課程中最重要的是 planning 部分,而我認為好的 plan 最重要的是 效率和諧的流程,就是那種大家把自己的 ticket 做完就莫名其妙沒事了那種感覺。

我在嘗試實踐以上想法的過程中,第一個改掉的習慣是 停止想像力的發揮 把想出來的東西轉化成明確的 issue,雖然說這過程不容易、也一點都不好玩,不過這樣做以後確實讓我的 team work 的很順利。

Comments

comments powered by Disqus