JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Software Engineering  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to topicthreaded modego to previous topicgo to next topic
話題被移動
該話題已被移動 - popcorny , 2003-10-15 10:51
如果您尚不清楚該話題被移動的原因,請參考論壇規則以及本版公告或者聯系本版版主。
本主題所含的標籤
無標籤
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
ming215





發文: 143
積分: 2
於 2003-10-12 03:15 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
好公司通常都是大公司。因為好,所以有機會變大。大公司到未必見得是好公司。

不過,好主管通常在爛公司都待不久。

----------------------------

咦,這麼晚不睡覺,有搶到100嗎?

Shock? 搶到100? 哪裡口以搶?..哇要搶 100萬~~(新台幣)

呃...現在不晚呀...現在素....一早.............粉早.....呃...太早了.. 再來企Sleepy


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
qing



版主

發文: 90
積分: 1
於 2003-10-12 11:25 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
當兩個人的討論集中在演算法時,其實補掉很多潛在的漏洞。像qing這種大師,其實寫程式就沒有bug。所有的defect都是導因於requirement/design的不清楚。兩個人可以互相進行想法上的溝通與驗證,其實是很棒的經驗。


最好是這樣啦. 怎麼看都像是在反諷耶~


當他在向我開示extreme programming時,我直覺覺得如果你在做pair programming時,遇到一個完全無法跟上你腳步跟思路的人,可能就會很痛苦吧。所以這可能只能當成是精英團體的特有process。


離題愈來愈兇. 不過既然 "又" 提到了 Pair Programming..
根據經驗, 兩個實力差不多的人可以提高生產力, 兩個實力略有差距的, 可以引導和教學的效果. 兩個實力相差太多的人, 似乎配合起來就不是很順暢. 就像引言所說的, 滿被限制在精英團體的一種特有 process.


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:qing]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-12 17:12 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
qing wrote:
最好是這樣啦. 怎麼看都像是在反諷耶~

咦,我本來想說,你寫的程式bug很少,後來想起你講的笑話,才改口的啊。你不是說過你寫的程式怎麼可能有bug呢?Smile


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
joke0827





發文: 2
積分: 1
於 2003-10-14 23:13 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
已經是討論的尾聲了才進來
似乎有點......
不過我就是那種提出要把COBOL ==> J2EE公司裡面的員工
基本上呢 如果我是廠商 給我在多錢我都不接這種案子
我不知道各位在軟體公司上班的先進怎麼看我們這種所謂的大公司
是隻肥羊呢 還是隻猛獸
我不接的原因簡單說起來最主要的只有一個
台灣的軟體開發文化太糟糕
不是廠商不好 也不是把案子包出去的公司不好
是整個環境的文化不好

不過針對這樣的轉換 我倒也有一些想法..........


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:joke0827]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-15 01:01 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
joke0827 wrote:
已經是討論的尾聲了才進來
似乎有點......
不過我就是那種提出要把COBOL ==> J2EE公司裡面的員工
基本上呢 如果我是廠商 給我在多錢我都不接這種案子
我不知道各位在軟體公司上班的先進怎麼看我們這種所謂的大公司
是隻肥羊呢 還是隻猛獸
我不接的原因簡單說起來最主要的只有一個
台灣的軟體開發文化太糟糕
不是廠商不好 也不是把案子包出去的公司不好
是整個環境的文化不好

不過針對這樣的轉換 我倒也有一些想法..........

歡迎歡迎,這個thread要繼續成長就要靠諸位了。

如果我是廠商,給我很多錢,我就會去接。不過前提是錢要夠多。

把cobol 的東西轉出來,光是data migration跟data model redesign,以及平行作業用的tool,就會是大工程。可是相對的,只要有了一次的經驗,這種案子就是個超大的商機。

環境不好,才有賺錢的機會。最少我是這樣認為啦。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
arthuroy





發文: 106
積分: 3
於 2003-10-16 01:34 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
嗯 目前 COBOL to Java 國外是有廠商號稱工具可以轉換 (不會是像以前 AS400 RPG 轉成 Window-based terminal 那種吧 呵),所以台灣才會有人覺得這是一個商機。至於那個工具怎麼用,well,沒去美國受訓我也不知道 (其實我們是不想去學,Java 就 Java,COBOL 要幹嘛...寫 COBOL 不如寫 Store Procedures Tongue )

不過前提是: 原來系統的 domain knowledge 若是沒有文件或是文件沒有隨著程式改變而更新的話,那代表有可能還是要經由 code study 的方式來了解原系統的運作 (突然想起 singleton 兄那篇提到的: 「我在學校時,總是覺得,只要有了文件,萬事都ok。只要離開的人,留下夠多的文件,人員的更替就不會有問題。現在就明白自己年幼時,是多麼地無知識淺。」,嗯...)。SA 人力方面會是一個問題,靠 programmer 或是 SD 去讀程式碼反向做出 business logic,個人覺得也會掉七落八的,題外話: 近來的 SA 都不太會寫程式了,也不想寫程式,唉...

所以情況就會變成像是 AS400 RPG migration 的案子一樣,這類的技術人力要外包或是採用約聘的方式進行。嗯 COBOL 不難懂,其實 AS400 RPG 也不難懂,只是要花多少專案經費處理這類的人力。

----
不在台灣幾天,一堆帖子,看帖子真的是會看死人呀...


reply to postreply to post
Self-Pity

I never saw a wild thing sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:arthuroy]
im1000



版主

發文: 149
積分: 7
於 2003-10-16 01:44 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
arthuroy wrote:
嗯 目前 COBOL to Java 國外是有廠商號稱工具可以轉換 (不會是像以前 AS400 RPG 轉成 Window-based terminal 那種吧 呵),所以台灣才會有人覺得這是一個商機。至於那個工具怎麼用,well,沒去美國受訓我也不知道 (其實我們是不想去學,Java 就 Java,COBOL 要幹嘛...寫 COBOL 不如寫 Store Procedures Tongue )


呵呵, 我還遇過 tandem 轉成 webservice 呢 :p


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:arthuroy]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-20 01:59 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
arthuroy wrote:
嗯 目前 COBOL to Java 國外是有廠商號稱工具可以轉換 (不會是像以前 AS400 RPG 轉成 Window-based terminal 那種吧 呵),所以台灣才會有人覺得這是一個商機。至於那個工具怎麼用,well,沒去美國受訓我也不知道 (其實我們是不想去學,Java 就 Java,COBOL 要幹嘛...寫 COBOL 不如寫 Store Procedures Tongue )

對銀行,還有很多早期買了大電腦開發一大堆東西的公家單位,國營事業,還有大公司來說,他們被ibm掐的死死的。而且越來越不容易找到人去maintain他們的程式了。所以把這些東西搬到另一個新平台,其實是一種深層的渴望。

就市場面來看,這是商機。因為這種系統通常都很大,所以死不得,做這種案子對小軟體公司來說,都是從未聽過的天價。不過risk很高,而大公司也不放心讓你做。這才是主要的問題啦。基本上這是那種看得到,吃不到的東西。要吃還要有一身本事。所以我們看看拿來聊天就好。

arthuroy wrote:
我在學校時,總是覺得,只要有了文件,萬事都ok。只要離開的人,留下夠多的文件,人員的更替就不會有問題。現在就明白自己年幼時,是多麼地無知識淺。

我講這句話時,其實想到了以前在銀行要maintain程式時,想看手冊,接著看到了一整個屋子IBM原廠出的枕頭書。遇到那種source code是用幾十萬行的cobol系統,真是欲哭無淚。台灣最熟的人在ibm,好像trace過中間的幾萬還是幾十萬行。(這個數量級對我來說,已經超出了我認知的極限。所以也沒差了。)

中間有很多人寫了外圍程式,也又是base on別人的output再加東西上去啦。這些東西你看得到文件算你狗運好。

我後來看到有人說,哎呀,我們只要留下文件...這種話,就想起一屋子跟山一樣高的原文書。(這座山每次回想都會長的比以前高。)我自己手頭上這幾個案子,每個都留下數百MB的文件檔。中間很多版本還sync不起來。所以後來誰再跟我說,只要留下夠多詳細的文件,人員的離開就不會太大的影響...我就會苦笑。

哪有這種事情。每個人要走我都會心痛。當然,我自己是抱持著雀躍萬分的心情離開的。
arthuroy wrote:
近來的 SA 都不太會寫程式了,也不想寫程式,唉...

我覺得這是因為很多不夠格的人,都掛了SA的名字,可是功力跟視野,怎麼說都還差一截吧。先前想找qualified的SA,找了大半年,還沒幾個合格的。被老闆追殺的,都要流眼淚了說,還好現在已經不幹了,就不用繼續煩惱。Smile


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-20 09:40 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
對銀行,還有很多早期買了大電腦開發一大堆東西的公家單位,國營事業,還有大公司來說,他們被ibm掐的死死的。而且越來越不容易找到人去maintain他們的程式了。所以把這些東西搬到另一個新平台,其實是一種深層的渴望。

就市場面來看,這是商機。因為這種系統通常都很大,所以死不得,做這種案子對小軟體公司來說,都是從未聽過的天價。不過risk很高,而大公司也不放心讓你做。這才是主要的問題啦。基本上這是那種看得到,吃不到的東西。要吃還要有一身本事。所以我們看看拿來聊天就好。

我講這句話時,其實想到了以前在銀行要maintain程式時,想看手冊,接著看到了一整個屋子IBM原廠出的枕頭書。遇到那種source code是用幾十萬行的cobol系統,真是欲哭無淚。台灣最熟的人在ibm,好像trace過中間的幾萬還是幾十萬行。(這個數量級對我來說,已經超出了我認知的極限。所以也沒差了。)

中間有很多人寫了外圍程式,也又是base on別人的output再加東西上去啦。這些東西你看得到文件算你狗運好。

我後來看到有人說,哎呀,我們只要留下文件...這種話,就想起一屋子跟山一樣高的原文書。(這座山每次回想都會長的比以前高。)我自己手頭上這幾個案子,每個都留下數百MB的文件檔。中間很多版本還sync不起來。所以後來誰再跟我說,只要留下夠多詳細的文件,人員的離開就不會太大的影響...我就會苦笑。

哪有這種事情。每個人要走我都會心痛。當然,我自己是抱持著雀躍萬分的心情離開的。

我覺得這是因為很多不夠格的人,都掛了SA的名字,可是功力跟視野,怎麼說都還差一截吧。先前想找qualified的SA,找了大半年,還沒幾個合格的。被老闆追殺的,都要流眼淚了說,還好現在已經不幹了,就不用繼續煩惱。Smile


我有種被隱示的感覺....

好啦... 我就是不夠格 才想當 SA 的.... 我想要哭了.... JiaYun~~ 我可以在你的懷裡哭嗎?

(文件通常是越做越濫.... 人的惰性... 不應該說把文件留下來是錯誤的... 且一個真正好的文件是有其功能. 只是通常只有第一版是可以看的...)


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-20 09:48 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
我有種被隱示的感覺....

好啦... 我就是不夠格 才想當 SA 的.... 我想要哭了.... JiaYun~~ 我可以在你的懷裡哭嗎?

(文件通常是越做越濫.... 人的惰性... 不應該說把文件留下來是錯誤的... 且一個真正好的文件是有其功能. 只是通常只有第一版是可以看的...)

我沒有影射你啊。我有種被戴帽子的感覺。我也想要哭了.... JiaYun~~雖然我不知道你是誰,可是我也可以在你的懷裡哭嗎?......Tongue

A...不對,已經結婚的人應該回家抱老婆痛哭才對。(JiaYun,不認識你,不過借花獻佛開個玩笑。別生氣喔。Big Smile)

文件有他的功能,不過文件不是everything。文字、語言或圖形其實拿來作為溝通的媒介,我覺得都還是有不夠清晰的地方。人與人之間的互動還是很重要的。所以我才會覺得台灣的軟體業,不會全部往outsourcing大陸移動。總會留下一些機會,給準備好的人。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-20 10:08 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
我沒有影射你啊。我有種被戴帽子的感覺。我也想要哭了.... JiaYun~~雖然我不知道你是誰,可是我也可以在你的懷裡哭嗎?......Tongue

A...不對,已經結婚的人應該回家抱老婆痛哭才對。(JiaYun,不認識你,不過借花獻佛開個玩笑。別生氣喔。Big Smile)

文件有他的功能,不過文件不是everything。文字、語言或圖形其實拿來作為溝通的媒介,我覺得都還是有不夠清晰的地方。人與人之間的互動還是很重要的。所以我才會覺得台灣的軟體業,不會全部往outsourcing大陸移動。總會留下一些機會,給準備好的人。


aii... 我果然是畫鬼符寫鬼字的人....
的確要把智慧傳遞給另一個人事很難的...
不過訓練是必要的, 就像是老師也不是一天就可以當成的...

希望有一天我可以把我的 鬼畫 變成人人可以看的 天畫~~

(文件當然不是 everything, 但是他應該擁有 common domain knowledge 的 bridge. 反正要構成這個理論, 可能還需要一段很長的時間.... 至少我自己啦...)


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-20 11:40 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
aii... 我果然是畫鬼符寫鬼字的人....
的確要把智慧傳遞給另一個人事很難的...
不過訓練是必要的, 就像是老師也不是一天就可以當成的...

希望有一天我可以把我的 鬼畫 變成人人可以看的 天畫~~

(文件當然不是 everything, 但是他應該擁有 common domain knowledge 的 bridge. 反正要構成這個理論, 可能還需要一段很長的時間.... 至少我自己啦...)

文件雖然不是everything,在我們還沒有找到更有效率的溝通方式前,還是很重要的。只是我們很少看到可以真正幫develope team省事的工具。如果你為了跟user溝通做了一種文件,你為了跟programmer溝通做了另外一種文件,為了跟tester溝通,又再做了另一種文件,這中間怎麼mapping,就很討厭了。

我不喜歡用UML來做SA,就是因為它讓我跟user溝通時,困難度增加很多,可是使用這種modeling language的人一直說它有其他的好處。我不否認它有好處,問題是光這一個壞處就打死了啊。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-20 12:41 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
文件雖然不是everything,在我們還沒有找到更有效率的溝通方式前,還是很重要的。只是我們很少看到可以真正幫develope team省事的工具。如果你為了跟user溝通做了一種文件,你為了跟programmer溝通做了另外一種文件,為了跟tester溝通,又再做了另一種文件,這中間怎麼mapping,就很討厭了。

我不喜歡用UML來做SA,就是因為它讓我跟user溝通時,困難度增加很多,可是使用這種modeling language的人一直說它有其他的好處。我不否認它有好處,問題是光這一個壞處就打死了啊。


user? 你的 user 是誰啊? 客戶嗎?

uml 只用來跟工程師溝通用的... use case diagram 也只有 SA 在用而已...

跟 user 溝通用的 通常會用 user 看的懂的文字, 圖形 等等.... 但絕不應該是 UML...


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-20 12:55 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
user? 你的 user 是誰啊? 客戶嗎?

uml 只用來跟工程師溝通用的... use case diagram 也只有 SA 在用而已...

跟 user 溝通用的 通常會用 user 看的懂的文字, 圖形 等等.... 但絕不應該是 UML...

我指的user是客戶啊。就是有domain know-how的人。

我們會寫use case spec。用word檔寫成的東西。這據說是use case driven OOAD的根本。以前在公司內部,常常會有很激烈的論述,討論SA是不是該拿這個東西跟user確定requirement。以及,我們是否要把這個訂為標準。因為要朝ISO/ CMMI / whatever ...那類的東西前進,後來就一人一把號,各吹各的調。Tounge

至於use case diagram,不知道是不是功力的問題,很多看到的人,通常都覺得這個東西會不會畫得太簡單,以致於沒什麼用?

對了,我們有另外一種user。我們幫大公司做案子時,他們的IT都會要求我們去解釋我們的design document,順便做些免費的教育訓練。遇到他們心情不好就說你講的太差,圖畫得不對。叫你回家重新準備。Sad我通常也覺得,這種溝通亂沒效率的。不過除了陪公子小姐讀書以外,沒什麼好的idea。工程師們當然視這種坐檯式的技術移轉為畏途囉。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-20 13:48 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
我指的user是客戶啊。就是有domain know-how的人。

我們會寫use case spec。用word檔寫成的東西。這據說是use case driven OOAD的根本。以前在公司內部,常常會有很激烈的論述,討論SA是不是該拿這個東西跟user確定requirement。以及,我們是否要把這個訂為標準。因為要朝ISO/ CMMI / whatever ...那類的東西前進,後來就一人一把號,各吹各的調。Tounge

至於use case diagram,不知道是不是功力的問題,很多看到的人,通常都覺得這個東西會不會畫得太簡單,以致於沒什麼用?

對了,我們有另外一種user。我們幫大公司做案子時,他們的IT都會要求我們去解釋我們的design document,順便做些免費的教育訓練。遇到他們心情不好就說你講的太差,圖畫得不對。叫你回家重新準備。Sad我通常也覺得,這種溝通亂沒效率的。不過除了陪公子小姐讀書以外,沒什麼好的idea。工程師們當然視這種坐檯式的技術移轉為畏途囉。


我應該加入你們的討論團隊... 我個人支持不拿 use case/ use case spec 跟客戶談. 應該拿的是商業邏輯跟她們談... 不過... 還是要看 case. 有些 case 事實上他們內部已經分析好了, 我想談的對象就是你講的 IT ppl.... 那談的方式就會很制式化

假設我們主掌分析團隊, 那我們面對的對象是 stackholders/ end-users 那談的方式要以她們的邏輯來談. .... 忽然覺得 我等下一定無法回應你的回答跟問題...

aii... 通常公司沒有幾個有好了 mis 部門, 通常只是修修電腦, 協助一些文書軟體使用上的問題... 但是又不願意把權限全部外包給 software company.... 不過就算真的全部外包了... 又有幾家軟體公司會真正的協助客戶做最有效率最正確的分析跟設計呢?

(use case diagram/ use case spec(and also activity diagram) 應該是 initial business(coperation) modelling tool. )


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-20 14:12 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
我應該加入你們的討論團隊... 我個人支持不拿 use case/ use case spec 跟客戶談. 應該拿的是商業邏輯跟她們談... 不過... 還是要看 case. 有些 case 事實上他們內部已經分析好了, 我想談的對象就是你講的 IT ppl.... 那談的方式就會很制式化

我們的很多討論,就會落在,不拿use case/use case spec,那應該拿哪一種商業邏輯文件跟user確認?哪一些是標準?要不要用rup裡面的?為什麼不用use case spec?看過distilled umlStupid的人就會說跟domain expert,應該用use case spec去談。這裡面寫的就是他們日常生活的語言...還有人會說,你們為什麼不follow standard?UML才是王道...

基本上會變成Use case driven OOAD = UML = 王道 = 大一統的天下,再過幾年以後,其他人都會滅亡...跟這種事情不會發生的論戰。

Biologic wrote:
aii... 通常公司沒有幾個有好了 mis 部門, 通常只是修修電腦, 協助一些文書軟體使用上的問題... 但是又不願意把權限全部外包給 software company.... 不過就算真的全部外包了... 又有幾家軟體公司會真正的協助客戶做最有效率最正確的分析跟設計呢?

喔,以前我們的客戶都是台灣一等一的大公司,裡面的人才濟濟,不是那種只會修電腦的啦。

我知道的,像是台積電幾年前就一直都把他們的project整個外包,他們希望做好project management跟domain expert就好了。所以除了這種人以外,他們主要的人員就是DBA。

他們裡面員工的素質真的蠻高的。最少我有不少優秀的同學都待過這家公司。我認識裡頭一些人也都是從大廠回來的,或者是思路非常清楚的domain expert,不是那種尋常沒見過世面的小MIS。不過話說回來,像台積電這麼專業的user,全台灣大概也沒幾家。Smile

其實UML+OOAD+J2EE這種東西在這種大公司裡面比較有票房。因為這些公司有錢也勇於嘗試新科技。中小企業反倒花不起錢養這種新玩具。

軟體公司其實也想幫客戶做有效率又正確的分析跟設計,誰不想有效率的結案呢?只是大家的想法跟目的各異,經驗跟對於方法論的了解也有所不同,所以到最後就會很辛苦。

我曾經做過一個案子,客戶的IT人員就把你當作是挖寶的對象,所以拿放大鏡來看你的一舉一動,想要從中學習。接著就常常提供他們高明的遠見,要求你要照著design。這個案子還沒做完,我們公司做這個案子的人就先走一半。客戶的IT人員倒是覺得這沒什麼關係,反正他們組織更替超快,他們只是想拿公司的資源學點東西。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
arthuroy





發文: 106
積分: 3
於 2003-10-23 15:52 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
對銀行,還有很多早期買了大電腦開發一大堆東西的公家單位,國營事業,還有大公司來說,他們被ibm掐的死死的。而且越來越不容易找到人去maintain他們的程式了。所以把這些東西搬到另一個新平台,其實是一種深層的渴望。

就市場面來看,這是商機。因為這種系統通常都很大,所以死不得,做這種案子對小軟體公司來說,都是從未聽過的天價。不過risk很高,而大公司也不放心讓你做。這才是主要的問題啦。基本上這是那種看得到,吃不到的東西。要吃還要有一身本事。所以我們看看拿來聊天就好。


的確是,所以我們只是當個旁觀者,看看未來會怎麼發展就好,自己不要介入 (說的好像是做時光機回到過去不要干預過去的歷史一樣 呵)。

我們必須承認目前有不少公司還是使用 IBM 大型電腦在處理交易,市場面來看的確這是一個商機,不然美國也不會有公司在發展這類的工具軟體。我不知道是不是這個公司利用這種工具幫助客戶做系統昇級兼自我轉型進行技術大躍進的工程,我以個人淺薄的眼光及不足的知識坐井觀天地認為: 如果你是剛出社會或是還沒有什麼軟體開發經驗的人,花時間深耕 COBOL 的語法及程式架構,不如把時間浪費在美好的 Java/J2EE (或是 C#/.NET) 上;如果要把 COBOL 轉換的方法學好,不如去學 PDM/CRM 或是做做 Customization for Oracle solution。

若是不想競爭這麼激烈,加上不想時時督促自己學習新的事物,那我建議去學 AS400 RPG - 至少 IBM 在這塊領域還是一直支援/支持著,沒有像微軟那樣會放棄 outlook express 的開發或是像 IE 許久沒更新版本,不顧其標準仍支援不足。

大老闆們再幾年就可以退休,現在做做他們的時代中當紅的 COBOL 或是 AS400 RPG 自然是得心應手讓人折服,彷彿就像我們現在見到寫組合語言奇人般的神聖無法匹敵;只是你的未來還很長,不是十年內就可以退休。當然在轉換的過程中要學 J2EE/.NET,只是我不認為上帝特別鐘愛你,一天二十四小時之外多給你 bonus time。

IBM 或許可以針對硬體/OS 進行現代化的工程,只是你只是小小的工程師,你不會因為做這個聲名大噪,成功名就賺大錢 (雖然做 J2EE/.NET 也不一定會有這種結局),只是我擔心你的競爭力,還有你執著這種現代化工程的耐心能支撐多久 - 然而 J2EE/.NET 的演進與時間不會停滯下來等待你。

行行出狀元,這道理我了解,或許十年後我會羨慕你 - 就像近幾年很多人看著竹科電子新貴坐擁股票那般;只是我實在無法說服我自己去賣香雞排,因為我知道我撐不到成功的那一天。

singlelog wrote:
我講這句話時,其實想到了以前在銀行要maintain程式時,想看手冊,接著看到了一整個屋子IBM原廠出的枕頭書。遇到那種source code是用幾十萬行的cobol系統,真是欲哭無淚。台灣最熟的人在ibm,好像trace過中間的幾萬還是幾十萬行。(這個數量級對我來說,已經超出了我認知的極限。所以也沒差了。)

中間有很多人寫了外圍程式,也又是base on別人的output再加東西上去啦。這些東西你看得到文件算你狗運好。

我後來看到有人說,哎呀,我們只要留下文件...這種話,就想起一屋子跟山一樣高的原文書。(這座山每次回想都會長的比以前高。)我自己手頭上這幾個案子,每個都留下數百MB的文件檔。中間很多版本還sync不起來。所以後來誰再跟我說,只要留下夠多詳細的文件,人員的離開就不會太大的影響...我就會苦笑。

哪有這種事情。每個人要走我都會心痛。當然,我自己是抱持著雀躍萬分的心情離開的。


文件 (這裡指的不是那種把程式碼列印出來當文件的文件喲) 是一種留下蛛絲馬跡的東西,讓後人至少能有跡可循,導引讀者進入作者的思考模式與邏輯,了解當時的情況及做出的決定 - 蠻適合用來撰寫歷史或是考古用;當然歷史學家跟考古學家是受後人敬仰的,我沒有任何貶低的意味在。文件也是一種溝通方式,比較起來還是優於口耳相傳的方式,當然一旦造假、不符合事實,情況會相當嚴重。

創意的東西或是說動腦的東西,重點是在「人」,不是那種單純機械動作就可以取代的;然而現在的成功人士/大老闆們,看見了未來 - 以機械取代人工的生產方式,誤認為掛上工程 (engineering) 二字就可以自動化、可以無人生產,從而為自身或是員工們帶來財富,而渾然不知 (抑或是故意忽略) 生產線組裝/硬體組裝 (電腦或是蓋房子) 跟 軟體組裝 這兩件事在 2003 年還是不能混為一談。

文件的確需要,但是 synchronization 跟 writing 還沒有完美解決方案;就算真的能做到,閱讀的人 (吸收者) 也要花費相當的時間與具有有相當的能力才能將文字描述的知識轉換為自己腦袋中的知識。所以總結來說,人還是重點 - 寫文件的人、讀文件的人若是功力差太多時,文件寫的再好再多也無濟於事。但是若是沒有文件,其實更是痛苦;舉例來說,Hibernate 若是沒有文件,大家一定滿頭霧水不知從何下手。

singlelog wrote:
我覺得這是因為很多不夠格的人,都掛了SA的名字,可是功力跟視野,怎麼說都還差一截吧。先前想找qualified的SA,找了大半年,還沒幾個合格的。被老闆追殺的,都要流眼淚了說,還好現在已經不幹了,就不用繼續煩惱。Smile


還有另外的例子就是: 不斷地告訴你公司一直在找資深的設計師或是很會寫程式的人,結果總是落空,到了離職時還沒見到任何的兵力增援 - 又要馬兒好又要馬兒不吃草,結果就是產業外移,往大陸發展做代工的市場,期望再來一次那種加工區的繁榮景況,老板們好坐著數鈔票。


arthuroy edited on 2003-10-25 14:00
reply to postreply to post
Self-Pity

I never saw a wild thing sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:arthuroy]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-23 21:27 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
arthuroy wrote:
我們必須承認目前有不少公司還是使用 IBM 大型電腦在處理交易,市場面來看的確這是一個商機,不然美國也不會有公司在發展這類的工具軟體。我不知道是不是這個公司利用這種工具幫助客戶做系統級兼自我轉型進行技術大躍進的工程,我以個人淺薄的眼光及不足的知識坐井觀天地認為: 如果你是剛出社會或是還沒有什麼軟體開發經驗的人,花時間深耕 COBOL 的語法及程式架構,不如把時間浪費在美好的 Java/J2EE (或是 C#/.NET) 上;如果要把 COBOL 轉換的方法學好,不如去學 PDM/CRM 或是做做 Customization for Oracle solution。

了解cobol大概比了解J2EE簡單一百倍吧Smile?會想要花時間去鑽研cobol的人,在這個世界上可能已經很少了。那就是為什麼會有這樣的需求鑽出來。

有需求,就有可能有商機。只是看我們有沒有興趣去做這樣的事情。有些時候會是有一套新的系統要出來把這舊的架構換掉,這就是這整個thread的kernel。我們可以不懂cobol,可是當有把cobol replace掉的機會時,那就是個要接或不要,技術上可行不可行的問題了。

arthuroy wrote:
若是不想競爭這麼激烈,加上不想時時督促自己學習新的事物,那我建議去學 AS400 RPG - 至少 IBM 在這塊領域還是一直支援/支持著,沒有像微軟那樣會放棄 outlook express 的開發或是像 IE 許久沒更新版本,不顧其標準仍支援不足。

基本上了解一套老系統,把他做reverse engineering,跟熟悉一套舊的語言,想拿舊語言繼續開發會是不一樣的事情。我的假設是,有可能會有這樣子的案子出現,你得要跟舊系統talk,或是把舊系統幹掉。無可避免的,你會需要了解舊系統在做什麼。不過這跟學RPG維生,是兩碼子事。Smile

arthuroy wrote:
大老闆們再幾年就可以退休,現在做做他們的時代中當紅的 COBOL 或是 AS400 RPG 自然是得心應手讓人折服,彷彿就像我們現在見到寫組合語言奇人般的神聖無法匹敵;只是你的未來還很長,不是十年內就可以退休。當然在轉換的過程中要學 J2EE/.NET,只是我不認為上帝特別鐘愛你,一天二十四小時之外多給你 bonus time。

每個人都應該培養屬於他自己的專長。不過我的假設比較像是了解J2EE/.NET的人要與懂cobol的人合作。

嗯,arthuroy點出了以前我沒有特別想過的一個點。先前我只有想到要把懂舊系統,懂舊語言的人找進來,我倒是沒想到這樣的人,跟接受新思維新技術的人,可能還要一段很長的磨合期。兩個講不同語言的人,需要時間才能融合成一個team。

基本上我不鼓勵大家去摸這種古老科技,這也不是我可以鼓吹得動的。Smile這比較像是工作上遇到了,或是另外一種特別的domain,跟你做ERP,CRM一樣。怎麼把舊系統的東西轉出來,這種know-how,就是想做這種business的人的domain knowledge。這跟追求J2EE是不衝突的。

不過我覺得每個人還是得為自己的將來做規劃。一直往技術研發這條路走,就是往programmer -> designer -> architect,或是programmer -> designer -> program manager 這樣子前進吧。這條路是沒辦法休息的,要一直鑽研下去。喜歡當RD的人,會從工作本身獲得很大的樂趣。

要不就是要往domain knowledge的累積跟鑽研system analysis的理論與實務這方面走,也就是說,去當SA啦。SA一旦對於domain以及SA的工作熟悉了以後,就不用日以繼夜地鑽研技術了。

往管理職走,則是另外一條道路。要做這一行,每個人都要先想想自己想往那裡走。

提到文件的話,我覺得文件很重要,可是人的腦袋與經驗,比文件更重要。軟體公司該想想怎麼做知識的累積。不是光看浮面的文件有沒有照規定去寫。

arthuroy wrote:
還有另外的例子就是: 不斷地告訴你公司一直在找資深的設計師或是很會寫程式的人,結果總是落空,到了離職時還沒見到任何的兵力增援 - 又要馬兒好又要馬兒不吃草,結果就是產業外移,往大陸發展做代工的市場,期望再來一次那種加工區的繁榮景況,老板們好坐著數鈔票。

資深的SA,不知道都躲到哪裡去啦。Smile這是我在找人找很久了以後,第一個慨嘆。第二個想法,則是對急功近利的作法感到很厭倦了。找不到人,就要自己慢慢養起來。這需要有長時間的投入與心血灌溉,很多公司很怕花了這樣的心血,這個人學成之後就繞跑。所以一直想找捷徑,看看有沒有那種right person at right time with right price。對啦,簽樂透也會有人中頭獎啦。

至於大陸的加工區喔。我比較不擔心這個也。如果我們的人都只會J2EE,那這種東西就很難有什麼優勢可言。大陸的人,印度的人,世界各個地方的人,都可以學得會。而他們可能只要有你一半不到的價碼,就很滿意了。在台灣的人得要把眼光放在不同的地方。J2EE只是本事中的一種,最重要的是創意以及解決問題的能力。做出napster的人好像也不是什麼科班出身的人,也不是什麼J2EE的高手。當然啦,如果你的志向就是以pure programmer的這條路的話,面臨第三世界的競爭就會是無法避免的事情了。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
go to first page go to previous page  1   2   3   4   5  go to next page go to last page
» JWorld@TW »  Software Engineering

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8