Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

軟體工程說來容易做來不易.

4 views
Skip to first unread message

來了! 稻中電腦社!

unread,
Oct 23, 1998, 3:00:00 AM10/23/98
to
※ 引述《Roland...@cis.nctu.edu.tw (Roland)》之銘言:
: > 紙上作業應是指: 事前完善的分析與設計,
: > 為日後 reuse 與 maintain 的工作鋪路,
: > 除非現在寫的程式沒有下一版, 否則現在不先好好分析與設計,
: > 等下一版開發時, 您會發現之前寫的程式根本無法 reuse,
: > 才曉得報應來了!(如果是別人寫下一版, 那算是躲過報應)
: > 接著就開始實地體驗軟體工程教科書上的箴言.
: 我最近接了一個專案,修改以前的程式(數百個 *.cpp/*.c)檔.
: 因為上一版,沒有用 OO 的觀念.結果要修正8000 多個地方.
: 如果上一版用了 OO 的觀念...只要修正一個地方.....

對不起! 我不知道您的實際狀況, 不過要修改的地方過多,
我會傾向於重寫.
而且不用 OO 也要修改 8000+ code, 這應該不只是單純的
軟體方法的問題, 而是原專案分析不當, 或是模組沒劃分好,
這種症狀大概以急著要完成專案或為了趕工引起居多.

如果以前的程式撰寫之時 programmer 或 analysist 負責一點
把整個軟體或程式的邏輯與架構整理清楚, 並且留下堪用的文件,
相信接手的人就不會那麼痛苦.

不過以我的情況卻是很可惜的, 我以前的主管是:
他要立即看到可以動的 prototype, 常常希望先有個畫面可以操作,
讓他可以秀給更上級的主管看看. 這樣對實際執行的 programmer 相當痛苦,
因為他連產品功能與定位尚未確定, 常常完成一項功能之後他一句不滿意
讓我幾天的心血泡湯, 最要不得的是: 他到外國參展時看了一些
國外的軟體執行畫面, 連別人的操作流程或功能與市場定位都弄不清楚之餘,
回國之後就要求也做一個, 要他開詳細規格書倒是閃得挺快的.
依他意思做出來操作邏輯有誤導致不能用或不合用還會反過來指責別人.
我朋友還陶侃了一番: 難怪xxxx股票漲不起來, 原因在此.

勸畢業生新鮮人找工作要慎重, 別看大公司薪水高有分紅及股票之類,
或是在大公司上班比較有面子與保障............

--
※ Origin: 水 世 界 ◆ From: Ts1-ppp07.ace.net.tw
--
Origin: 靜宜資管水世界 bbs.cs.pu.edu.tw

小明

unread,
Oct 24, 1998, 3:00:00 AM10/24/98
to
《 在 JSLi...@bbs.cs.pu.edu.tw (來了! 稻中電腦社!) 的大作中提到: 》
: 對不起! 我不知道您的實際狀況, 不過要修改的地方過多,

: 我會傾向於重寫.
: 而且不用 OO 也要修改 8000+ code, 這應該不只是單純的
: 軟體方法的問題, 而是原專案分析不當, 或是模組沒劃分好,
: 這種症狀大概以急著要完成專案或為了趕工引起居多.

我看過的軟體,幾乎都是這樣,或者看起來文件齊全,
實際上文件跟程式有太多對不起來的地方,結果還是沒用。

不過就算修改,也一定還是會有趕時間的問題,
因為問題多半來自於主管,修改時只可能比寫作時更趕,
程式設計的問題,最大又最難解的就是人的問題,人的問題不解決,
什麼程式設計方法都沒用,只不過是讓問題更晚爆炸而已。

這時,我傾向儘量不大改原有的程式,用原來的邏輯、原來的 dirty code 來改,
即使很蠢笨,但是這是較安全的做法。

而這樣的工作如果還要繼續做,就得另外找時間一步一步地做取代的動作。
如果沒有辦法湊出這樣的時間或者主管什麼都要知道又什麼都不懂,
那麼也許該考慮去留問題。

原來的程式碼如果亂七八糟卻能用,通常表示已花了許多時間在除錯上,
任何動到筋骨的改法,一不小心就會出現莫名奇妙的問題,
讓你改不下去,這是最可能出現的狀況,而且絕不會有人願意讓你重寫。

事實上,要我改別人的程式,除非是自己需要,否則我是絕對不幹的。
什麼只要兩個星期,做好就是 50 萬,這種話聽多了,全是騙人的,
如果不是救不起來的東西,怎麼可能想找我,這種東西我連幫忙轉包都不肯的。

--
[m [1;37m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 163.13.93.101] [m

0 new messages