推 t64141: 專業推 12/19 12:41
推 saivantist: 推，受益良多 12/19 12:55
推 neo5277: 糟糕我也很愛SOP.... 12/19 14:42
推 kurtsgm: 3.a在大型project裡面要清實在超痛苦 XD 12/19 14:47
推 akito117: 專業推 12/19 15:21
推 gary62107: 推 12/20 14:12
※ 引述《eori (浮光掠影)》之銘言：
: 進來公司一個多月，被指派說要去修改一個系統。 該系統已經用了10年以上，文件寥寥
: 可數，代碼改得亂七八糟，註解只有幾行。我這個職位兩年內換了五個人，其他同事只知
: 道大概，問細節就說去看code。老闆一直認為這個系統很簡單，搞不懂為什麼沒人懂。請
: 問大家有沒有相似經驗，後來又是怎麼解決，可以給我當作參考，謝謝。
上面那一篇是精神面正解 我這邊說一下操作面好了
第一階段
前幾天code大概看看就好 先看coding style分成幾類 然後cloc一下
先報告這個系統約XX萬行 程式裡面有YY種風格混在一起
(先展現這系統確實不好處理)
第二階段
先管大架構 簡單的報告這個系統分成幾個子系統 如果可以的話......
沒文件也沒註解的話命名又鳥的話 這邊開始就要奮鬥了
先對子系統寫一些簡單的測試 最低限度的測試就好 邊界或特殊狀況都不管
(因為有寫東西 總行數有變多)
做一些簡單重構讓程式碼好讀 還有寫好註解
因為一般老人最愛SOP 寫一份文件應該是上面會比較喜歡
不過寫不寫看還是看老闆要求 如果要寫的話 註解跟文件盡量一樣
(這樣有兩個好處 1. 後面的人不能直接抄你的註解轉文件 2.方便改)
第三階段
在大概知道架構後處理容易產生bug或難以debug的地方 這部份很吃經驗
好比 a. 解開A include B / B include C / C include A環狀
b. 改掉些白目的寫法 像是把很多事情壓成一行
c. 把一些奇奇怪怪寫法改成正常的寫法
d. 整理coding style
這邊要告報做了多少事就靠diff 盡量維持每週處理差不多的量
好比改得多就不要去動coding style 改得少就找一天刷coding style之類的
第四階段
正式增修和改寫程式本體還有維護它
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.113.63.41
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1482097153.A.F4D.html
※ 編輯: Sidney0503 (140.113.63.41), 12/19/2016 05:48:41