對不起! 我不知道您的實際狀況, 不過要修改的地方過多,
我會傾向於重寫.
而且不用 OO 也要修改 8000+ code, 這應該不只是單純的
軟體方法的問題, 而是原專案分析不當, 或是模組沒劃分好,
這種症狀大概以急著要完成專案或為了趕工引起居多.
如果以前的程式撰寫之時 programmer 或 analysist 負責一點
把整個軟體或程式的邏輯與架構整理清楚, 並且留下堪用的文件,
相信接手的人就不會那麼痛苦.
不過以我的情況卻是很可惜的, 我以前的主管是:
他要立即看到可以動的 prototype, 常常希望先有個畫面可以操作,
讓他可以秀給更上級的主管看看. 這樣對實際執行的 programmer 相當痛苦,
因為他連產品功能與定位尚未確定, 常常完成一項功能之後他一句不滿意
讓我幾天的心血泡湯, 最要不得的是: 他到外國參展時看了一些
國外的軟體執行畫面, 連別人的操作流程或功能與市場定位都弄不清楚之餘,
回國之後就要求也做一個, 要他開詳細規格書倒是閃得挺快的.
依他意思做出來操作邏輯有誤導致不能用或不合用還會反過來指責別人.
我朋友還陶侃了一番: 難怪xxxx股票漲不起來, 原因在此.
勸畢業生新鮮人找工作要慎重, 別看大公司薪水高有分紅及股票之類,
或是在大公司上班比較有面子與保障............
--
※ Origin: 水 世 界 ◆ From: Ts1-ppp07.ace.net.tw
--
Origin: 靜宜資管水世界 bbs.cs.pu.edu.tw
我看過的軟體,幾乎都是這樣,或者看起來文件齊全,
實際上文件跟程式有太多對不起來的地方,結果還是沒用。
不過就算修改,也一定還是會有趕時間的問題,
因為問題多半來自於主管,修改時只可能比寫作時更趕,
程式設計的問題,最大又最難解的就是人的問題,人的問題不解決,
什麼程式設計方法都沒用,只不過是讓問題更晚爆炸而已。
這時,我傾向儘量不大改原有的程式,用原來的邏輯、原來的 dirty code 來改,
即使很蠢笨,但是這是較安全的做法。
而這樣的工作如果還要繼續做,就得另外找時間一步一步地做取代的動作。
如果沒有辦法湊出這樣的時間或者主管什麼都要知道又什麼都不懂,
那麼也許該考慮去留問題。
原來的程式碼如果亂七八糟卻能用,通常表示已花了許多時間在除錯上,
任何動到筋骨的改法,一不小心就會出現莫名奇妙的問題,
讓你改不下去,這是最可能出現的狀況,而且絕不會有人願意讓你重寫。
事實上,要我改別人的程式,除非是自己需要,否則我是絕對不幹的。
什麼只要兩個星期,做好就是 50 萬,這種話聽多了,全是騙人的,
如果不是救不起來的東西,怎麼可能想找我,這種東西我連幫忙轉包都不肯的。
--
[m [1;37m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 163.13.93.101] [m