Comments on: 版本控制，版本升級是不是個問題？ http://mmdays.com/2008/01/04/programming-language-version-control/ 網路, 產業, 資訊, 觀察, 生活, 電影, 技術, 新知, 科技, 媒體, 趨勢, Web 2.0 Wed, 23 May 2012 15:48:00 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: 網站製作學習誌 » [Web] 連結分享 http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-38806 網站製作學習誌 » [Web] 連結分享 Wed, 25 Nov 2009 02:43:27 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-38806 [...] 雖然 Java 不是我的飯碗，不過裡面的討論還是值得關注一下。另外後續還有這篇：版本控制，版本升級是不是個問題？ [...] [...] 雖然 Java 不是我的飯碗，不過裡面的討論還是值得關注一下。另外後續還有這篇：版本控制，版本升級是不是個問題？ [...]

]]> By: Dennis 的無差別 Blog » 網摘: 版本控制，版本升級是不是個問題？ http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-14546 Dennis 的無差別 Blog » 網摘: 版本控制，版本升級是不是個問題？ Thu, 10 Jan 2008 14:07:32 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-14546 [...] Mr./Ms. Days (MMDays) - 網路, 資訊, 觀察, 生活 » Blog Archive » [MMDays 專欄] ... [...] [...] Mr./Ms. Days (MMDays) – 網路, 資訊, 觀察, 生活 » Blog Archive » [MMDays 專欄] … [...]

]]> By: 網絡集錦 « Alan Poon’s Blog http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-14534 網絡集錦 « Alan Poon’s Blog Wed, 09 Jan 2008 14:17:31 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-14534 [...] Mr./Ms. Days (MMDays) - 網路, 資訊, 觀察, 生活 - [MMDays 專欄] 版本控制，版本升級是不是個問題？ http://mmdays.com/2008/01/04/programming-language-version-control/ [...] [...] Mr./Ms. Days (MMDays) – 網路, 資訊, 觀察, 生活 – [MMDays 專欄] 版本控制，版本升級是不是個問題？ http://mmdays.com/2008/01/04/programming-language-version-control/ [...]

]]> By: Luke http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-14459 Luke Mon, 07 Jan 2008 04:24:20 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-14459 就我看了那麼多留言, 大家的立場、所屬公司、參與過的專案都不大一樣, 而重點就在於大家都以自己的立場為出發點, 所以造就一連串發散的討論。 就我看了那麼多留言, 大家的立場、所屬公司、參與過的專案都不大一樣, 而重點就在於大家都以自己的立場為出發點, 所以造就一連串發散的討論。

]]> By: Luke http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-84393 Luke Mon, 07 Jan 2008 04:24:00 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-84393 就我看了那麼多留言, 大家的立場、所屬公司、參與過的專案都不大一樣, 而重點就在於大家都以自己的立場為出發點, 所以造就一連串發散的討論。 就我看了那麼多留言, 大家的立場、所屬公司、參與過的專案都不大一樣, 而重點就在於大家都以自己的立場為出發點, 所以造就一連串發散的討論。

]]> By: 程式者的胡言亂語 http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-14444 程式者的胡言亂語 Sat, 05 Jan 2008 03:59:36 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-14444 <strong>”版本控制，版本升級是不是個問題？”後記...</strong> 在我寫前一篇文章時，其實我猜想 Mr. Saturday 應該就是任職於某公司，因為從他的文中所描述的情況，大概也沒別家公司了 XD 這 .. 不管我有沒有猜對， Mr. Saturday 都不要打我啊～ 說... ”版本控制，版本升級是不是個問題？”後記…

在我寫前一篇文章時，其實我猜想 Mr. Saturday 應該就是任職於某公司，因為從他的文中所描述的情況，大概也沒別家公司了 XD 這 .. 不管我有沒有猜對， Mr. Saturday 都不要打我啊～ 說…

]]> By: M http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-14443 M Sat, 05 Jan 2008 00:08:24 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-14443 給一個我跟銀行主管交涉的例子，的確EOL是關鍵，但是他們為了確保投資值得，會要求這個時間最少是十年，所有的3rd party程式也都能確保有十年的生命期。 有點規模的銀行（台灣沒有見過），甚至要求每個3rd party程式資料庫都要被檢查，而且要求廠商提出十年的保證期，不然不能使用。 當然，這已經不是Java的問題了。 最後，雖然我認為Java的版本更新是問題，不過只要沒牽扯到UI，基本上沒大問題。主要的問題都是發生在Swing上面，要是你夠猛用AWT寫各種元件（如tree, table），那可能改版的陣痛會少更多，我也遇過這種專案，可惜後來找不到人要維護，寫程式的人可能已經變總經理了，新人根本不可能會AWT。 要記得對客戶來說，UI才是大問題，後方的計算要錯還真是難。 最後，那個換核心系統還用COBOL的問題是單純政治。COBOL沒死，而且沒有凋零，因為這一換的生命週期最少是二十年。 給一個我跟銀行主管交涉的例子，的確EOL是關鍵，但是他們為了確保投資值得，會要求這個時間最少是十年，所有的3rd party程式也都能確保有十年的生命期。
有點規模的銀行（台灣沒有見過），甚至要求每個3rd party程式資料庫都要被檢查，而且要求廠商提出十年的保證期，不然不能使用。
當然，這已經不是Java的問題了。
最後，雖然我認為Java的版本更新是問題，不過只要沒牽扯到UI，基本上沒大問題。主要的問題都是發生在Swing上面，要是你夠猛用AWT寫各種元件（如tree, table），那可能改版的陣痛會少更多，我也遇過這種專案，可惜後來找不到人要維護，寫程式的人可能已經變總經理了，新人根本不可能會AWT。
要記得對客戶來說，UI才是大問題，後方的計算要錯還真是難。
最後，那個換核心系統還用COBOL的問題是單純政治。COBOL沒死，而且沒有凋零，因為這一換的生命週期最少是二十年。

]]> By: M http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-84391 M Sat, 05 Jan 2008 00:08:00 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-84391 給一個我跟銀行主管交涉的例子，的確EOL是關鍵，但是他們為了確保投資值得，會要求這個時間最少是十年，所有的3rd party程式也都能確保有十年的生命期。 有點規模的銀行（台灣沒有見過），甚至要求每個3rd party程式資料庫都要被檢查，而且要求廠商提出十年的保證期，不然不能使用。 當然，這已經不是Java的問題了。 最後，雖然我認為Java的版本更新是問題，不過只要沒牽扯到UI，基本上沒大問題。主要的問題都是發生在Swing上面，要是你夠猛用AWT寫各種元件（如tree, table），那可能改版的陣痛會少更多，我也遇過這種專案，可惜後來找不到人要維護，寫程式的人可能已經變總經理了，新人根本不可能會AWT。 要記得對客戶來說，UI才是大問題，後方的計算要錯還真是難。 最後，那個換核心系統還用COBOL的問題是單純政治。COBOL沒死，而且沒有凋零，因為這一換的生命週期最少是二十年。 給一個我跟銀行主管交涉的例子，的確EOL是關鍵，但是他們為了確保投資值得，會要求這個時間最少是十年，所有的3rd party程式也都能確保有十年的生命期。
有點規模的銀行（台灣沒有見過），甚至要求每個3rd party程式資料庫都要被檢查，而且要求廠商提出十年的保證期，不然不能使用。
當然，這已經不是Java的問題了。
最後，雖然我認為Java的版本更新是問題，不過只要沒牽扯到UI，基本上沒大問題。主要的問題都是發生在Swing上面，要是你夠猛用AWT寫各種元件（如tree, table），那可能改版的陣痛會少更多，我也遇過這種專案，可惜後來找不到人要維護，寫程式的人可能已經變總經理了，新人根本不可能會AWT。
要記得對客戶來說，UI才是大問題，後方的計算要錯還真是難。
最後，那個換核心系統還用COBOL的問題是單純政治。COBOL沒死，而且沒有凋零，因為這一換的生命週期最少是二十年。

]]> By: A little Java User http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-14441 A little Java User Fri, 04 Jan 2008 18:34:11 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-14441 <strong>Java會步上COBOL之升級是否為問題...</strong>     最近正熱的議題?其實我怎麼覺得好像在半年一年多前就有國外媒體還是誰提過?所以已經有點冷感了。而小弟本身就是資訊焦慮者，每次遇到升級就會非常想幫手上的東西升級(... Java會步上COBOL之升級是否為問題…

    最近正熱的議題?其實我怎麼覺得好像在半年一年多前就有國外媒體還是誰提過?所以已經有點冷感了。而小弟本身就是資訊焦慮者，每次遇到升級就會非常想幫手上的東西升級(…

]]> By: orson http://mmdays.com/2008/01/04/programming-language-version-control/comment-page-1/#comment-14440 orson Fri, 04 Jan 2008 17:31:28 +0000 http://mmdays.com/2008/01/04/programming-language-version-control/#comment-14440 也舉銀行當例子好了 我公司的客戶(們) 他們的運作規則大概是這樣的 買系統（建置系統）的時候 會要求廠商用當時最新的穩定產品 等系統上線之後 除非『絕對必要』 上線產品當時的所有系統環境，就會是這套系統永遠的環境，直到系統消失。 追平台的版本？ 想太多 廠商說產品EOL，繼續用到不能用為止 10年 20年的系統 從來沒升級過的 在銀行比比皆是 對他們來說 開門做生意 IT系統只是支援性的系統 能用 夠好用 夠重要 沒有人會去動它 也沒有人想去動它 因為 沒有人願意承擔萬一系統停擺 讓公司不能賺錢 甚至賠錢的風險 另外 談到COBOL 小弟對JAVA跟COBOL都是完全的門外漢 我只知道一件事 台灣 2000年以來 有換核心銀行系統的銀行(8家) 所採用的系統 只有兩家不是用COBOL寫的 這兩家 很剛好 都很小 一個用JAVA（嚴格來說，應該說是ORACLE） 另一個用.NET 其餘六家 有四家在台灣排在前10大 而且 現在的COBOL 也算是個VM 也可以Write once run everywhere 也支援HTTP,XML,COM等介面 (有興趣請參觀acuCOBOL) 步入COBOL後塵 好像是說COBOL已死 但實際上COBOL活的很好 以一個Business Oriented Language來說 應該可以說無人可出其右 COBOL已死？我們只是不在它的世界而已吧 最後 說個追版本的小故事 某銀行的某一個關鍵系統 原本用JDK 1.4開發 UT UAT都完成了 結果開發廠商 的技術頭頭發現 1.5的效能比1.4好很多 而且架構也比較漂亮 然後他們就很神奇的的更換了JDK。到上線的那一天 well，直接跳到結論，效能的問題根本不在AP，是DB架構太....。 取得這個結論的花費，應該有3千萬吧。 追版本對嗎？ 追版本不對嗎？ 我不知道 我還在寫C跟Delphi。 也舉銀行當例子好了
我公司的客戶(們) 他們的運作規則大概是這樣的
買系統（建置系統）的時候 會要求廠商用當時最新的穩定產品
等系統上線之後 除非『絕對必要』 上線產品當時的所有系統環境，就會是這套系統永遠的環境，直到系統消失。
追平台的版本？ 想太多
廠商說產品EOL，繼續用到不能用為止
10年 20年的系統 從來沒升級過的 在銀行比比皆是

對他們來說 開門做生意 IT系統只是支援性的系統 能用 夠好用 夠重要 沒有人會去動它 也沒有人想去動它 因為 沒有人願意承擔萬一系統停擺 讓公司不能賺錢 甚至賠錢的風險

另外 談到COBOL 小弟對JAVA跟COBOL都是完全的門外漢 我只知道一件事
台灣 2000年以來 有換核心銀行系統的銀行(8家) 所採用的系統 只有兩家不是用COBOL寫的 這兩家 很剛好 都很小 一個用JAVA（嚴格來說，應該說是ORACLE） 另一個用.NET 其餘六家 有四家在台灣排在前10大
而且 現在的COBOL 也算是個VM 也可以Write once run everywhere 也支援HTTP,XML,COM等介面 (有興趣請參觀acuCOBOL)
步入COBOL後塵 好像是說COBOL已死 但實際上COBOL活的很好 以一個Business Oriented Language來說 應該可以說無人可出其右
COBOL已死？我們只是不在它的世界而已吧

最後 說個追版本的小故事
某銀行的某一個關鍵系統 原本用JDK 1.4開發 UT UAT都完成了 結果開發廠商 的技術頭頭發現 1.5的效能比1.4好很多 而且架構也比較漂亮 然後他們就很神奇的的更換了JDK。到上線的那一天 well，直接跳到結論，效能的問題根本不在AP，是DB架構太….。 取得這個結論的花費，應該有3千萬吧。 追版本對嗎？ 追版本不對嗎？ 我不知道 我還在寫C跟Delphi。

]]>