※ 引述《pokerhand (pokerhand)》之銘言：
: 看著上面的美玉之文 讓我覺得不補充一下細節過意不去
: 先說, 由上面眾多好文, 我已經大概了解要怎麼做了. 感謝各位寶貴的經驗談.
: 特別是熱心的lovdkkkk, 來信跟我討論令我受益良多.
: ---
: 我所在的team 算新人team, 有支援AB兩個 project, 支援的人數一半一半,
: 我負責帶支援AB兩個project的新人的技術方面.
: 我支援的project A的前輩都是身經百戰的強者,
: design pattern跟OO思維到系統架構熟到爛.
: 對重構 & 測試先行 & 物件抽象非常在行, 重構在這邊的進行大致上是沒什麼問題的,
: 也不用特別去推, 大家都有共識.
: 有問題的是支援project B的新人, 向我們反映那邊的code實在是....
: project B的前輩也是相當熱心的在帶支援B的新人,
: 但無奈觀念還是在functional programming, 很多寫法在maintain上會出問題而不自知.
^^^^^^^^^^^^^^^^^^^^^^ <- procedural programming
functional programming是像F#那些應該更加難以理解的東西... :P
Project B可以先把project拆成數個DLL, 然後以DLL為單位重整結構.
首先把core的business object建設出來. 有新功能需要的時候
就先讓老手寫procedual function到library裡, 他們應該會很習慣... :P
在project間的空檔就是修補漁網的時候了. 可以請project A的人
示範如何將procedure code改成OO的method的應用方式. 多改幾次
就可以叫他們自己改看看. 到熟練時就可以直接寫OO了.
最初的時候要求最好放鬆些, 本來的global variable用一個static
class暫時存放也無所謂. 這些改了容易有副作用的東西最好等待
全team的能力都提昇到一定程度再作refactor. Interface / common
base class也比照處理, 不必太心急.
短期內難免會有效能下降, 但應在可接受範圍. 在拆解成DLL模組的
過程中也等於做了初步的function/method篩選, 轉換成OO的時候
也會清楚一些, 避免一些「藕斷絲連」的情況.
注意整個「改建」工程必須由熟悉Project B的人主導和控制進程,
這人必須熟悉Project B的所有data flow, 要支持OO化, 會不會OO
反而次要... 最好不是Project A的人, 以避免許多技術層面以外
的問題...
--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.92.4.195