Re: [討論] 維護前輩or離職人員寫的程式??
※ 引述《jodo1984 (XDDD)》之銘言：
: 我還在新人的時候，那時候主管把一支程式丟給我維護
: 後來沒多久那位學長就離職了,之後很努力的花了3個月
: 才慢慢看懂這支程式也加了一些功能和修改一些BUG
: 但是那段時間因為能力不如主管預期(一個月就要完全了解)
: 所以那段時間常常被唸甚至完全的黑掉。
: 最近剛好朋友也遇到這種情況，又勾起我的疑問!!
: 想請問各位前輩通常都怎麼維護別人寫的程式，一行一行研究嗎?
: 還是先把程式流程了解再從每個FUNCTION去深入擊破
剛開始應是先藉由維護特定的流程為目的,先見識到系統中的一個脈絡,然後慢慢的
事(流程)和物(程式)整合起來.
流程不會寫在程式裡. 就想想有些建築格局是因應著人的動線而設計; 假如把人
和動線抽離掉,光是看看空間,川堂或走廊之類的,你能自己用聯想而自己找出哪些
動線嗎? 應該很難. 同理,看看程式,只是看看有哪些表單傳送給哪些程式,之後又走
到哪裡,但是流程在哪裡,通常就不是死死讀一讀程式碼就可以了. 應該要積極點
跟人聊聊,問問別人如何使用這系統.
但是不要一行一行研究. 一行一行學習,是純粹技術新人在做的,那種人是連技術基礎
都待學習. 技術基礎夠的人,對一個系統的初學認識,應該先從結構上著手,而不是從
細節開始做.
一個修改的需求來的時候,通常我關心幾個方面:
1. 這個需求或許牽連到同一類功能,而系統中這個功能總共有幾個存在之處. 這件事情
的重要在於,假如你漏了其中一個存在之處,就是一個缺失.
2. 要修改的功能本來是什麼樣子.
3. 而細節上,什麼情況叫做bug或者是要修改掉的東西.
4. 相關的流程是哪些,輸入資料有哪些,會收到哪些輸出資料.
然後,動手的時候就是先定位目標物,然後進去看細節. 針對程式,自己先做一些定義
明確的處理動作,而且要趕快做完. 做完之後,跳出來把之前所做的明確定義打散,
重新問問自己或團隊的人:這樣子修改有沒有滿足那些描述較模糊的需求?
只要你能認為,問題並沒有解決,那麼就要再想辦法做一輪維護動作.
而修改的成效驗證,最好找一些具體的辦法來驗證. 有用到資料的程式,就弄一些測試
資料來驗證; 如果功能是程式機制,則最好準備一些豐富一點的測試資料,才能運用
歸納法來證明你所做的有效.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 36.226.94.189
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 2 篇)：