程式者的胡言亂語
星期六 一月 05, 2008
回應”版本控制，版本升級是不是個問題？”
在前一篇「關於”Java即將變成另一個COBOL”這篇文章」之後，Mr. Saturday也針對其中的「Java版本發行速度太快」這個議題發表了”版本控制，版本升級是不是個問題？”這篇文章。首先謝謝Mr. Saturday在文中還稱呼我是前輩，其實我不是啊～我很幼齒，雖然大河馬叫我學長，但其實我還比他年輕好幾歲呀。
有興趣的人可以先看看JDK的版本編號原則。從Sun的官方網站上可以查到J2SE SDK/JRE Version String Naming Convention。J2SE的release共分三種類型，分別是：Feature、Maintenance、以及Update。Feature代表的是”Contains new functionality”，編成
那我們就回到Mr. Saturday這篇文章中吧。Mr. Saturday提到：「程式語言的升級有的時候不只是更改語法或是加入新的 language feature 和 library，很多時候伴隨著升級而來的，是去除舊版本的 bug 和替換舊的 library，甚至於改變某些 function 的行為．」就JDK的版本變更原則來說，加入新的language feature是要變更一個大的版本號才會發生的事，例如從JDK 1.4跳到JDK 1.5。事實上，近來JDK在語言層次上最大的幾次變更，就我個人的感受，大致上是發生在JDK 1.0 -> JDK 1.1，JDK 1.1->JDK 1.2、JDK 1.4 -> JDK 1.5。像JDK 1.5吸收了許多來自.Net的觀念，加入了Generics、Annotation、Enumerated Types等等，都是很大的語言變動。一來，這些事件的發生是散佈在十多年的時間間隔之內，二來，你不得不說，就語法本身向下相容的情況，Java做的很好。我在這十多年來，如果暫時撇開不看deprecated的問題，只有中招過一次（我有個維護了class，有個叫enum的method，因為JDK 1.5把enum列為關鍵字，所以完全不能在JDK 1.5之後的版本去compile這個class。不過，如果在JDK 1.4先編譯好，再丟到JDK 1.5之後的VM執行，倒是沒有什麼問題）。光是看JDK 1.0時代留下來的那堆什麼Vector、Stack、Enumeration之類設計十分拙劣的classes至今依舊殘存著，就知道為了維持向下相容，Java付出的代價還挺沉重的。雖然說，deprecated就是提醒你快點準備把它們廢掉，不過有一堆class中的deprecated warnings，厚臉皮撐著，也就還渡過了相當漫長的許多年，至今仍是相安無事。所以我想說的論點是，語言本身的變化其實並不頻繁（轉眼間，.Net已經是3.0了呀），而且，事實上真的能產生的衝擊也並不大。我們有幾個library和framework，大致上就在近十年內持續維護著，或許是我們沒有用到什麼Java的精華功能，所以至今除了那enum之外，倒也沒出過什麼事。真的有人深受什麼大害的，我倒是願聞其詳。
所以，由於本篇一樣會寫的很長，都是文字完全沒有插圖，而且行距很窄、段距也不清楚，讀者讀起來會很費力，讀了前面忘了後面，所以我要再重覆一下我的論點：Java語言本身的改版並不頻繁（事實上，你只要看Thinking In Java這本書版本的變化，就知道Java大改版的情況和改版的時間點），而且語言本身的功能新增，向下相容的情況，並沒有什麼顯著的問題，就算有，天下本來也就沒有什麼白吃的午餐。所以，我們再把焦點移到bug fixing這件事上頭。
Mr. Saturday說到：「當你發現舊版本的 bug 可能會引（註：應為影）響你的產品…你必須去考慮升級，確保日後的相容性和穩定性．」這句話當然沒錯，但是，在這種情況下，你會去昇級的是Maintenance或Update類型的release，這和你去昇級Feature這種的release其意義又不盡相同。我是不知道Mr. Saturday任職的公司究竟有多大，規模大到每個小改版會涉及「數千個產品，數千位工程師」，但是，我想一來大多數的人的例子皆非如此。我的Java工作在這麼多年來，所涉及的projects恐怕還不到100個，所以算是管中窺天吧，對我們來說，在檢查每次的bug fixing所產生的副作用，Sun在各類型的測試上，應該會比我們自己能做的程度高上許多。在這麼多年來，真的中招過的經驗，也就真的只有一次在昇級某個Update後引發的SWING副作用所導致的問題。沒辦法，這就是難題所在。但我相信，Sun改code發生副作用的機會，還是遠低於我們自己改code發生副作用的機會。與其擔心Sun在下一次的Update中會誤中地雷，我還寧可多花時間擔心自己的code change會不會發生什麼災難。當然，這也是以我自己的經驗而言。
當你的公司有上千名（或甚至上萬名）工程師時（Google應該全球加在一起也沒有上萬名programmer吧），這真的代表你的公司生意做很大，再加上你的公司又如此深深的依賴Java時，setup一個叫做Java Infrastructure Team的team，那真的是一點也不為過，而且是應該要的投資。IBM甚至還自己做Java的compiler和VM呢！對你的公司來說，保持對Java的關心是絕對必要的，而且以這種公司的規模，本來就必須耗費這種等級的成本。看完這麼大的公司該做的事之後，想想自己的處境。我希望有人可以答有，就是你任職的公司必須要同步去協調一千名甚至一萬名Java programmer的，在本篇blog刻完24小時內來信者，我們有優待，贈送funP紅利積點一百點（請找大河馬索取，他不給我也沒辦法XD）。對大多數的programmer來說，會面臨到這個局面嗎？我想不會。我想表達的是，當我們在討論一個巨觀的問題時，其實不太適合套用一些特例來做為佐證。畢竟，我們更想討論的是它普遍性的影響。
為什麼我會在一開始就先將版本變化給拆開來，為的就是試著獨立去討論。當像Mr. Saturday文中所提到的是「在技術上：新版本的 performance 是否有差異是一個問題…在人員教育上：升級之後的磨合期也是一個問題」等問題時，這肯定都是大版本變化時才會發生的，光是個bug fixing的版本，會影響什麼performance，又會影響到什麼人員的教育訓練呢？所以，我會提到語言大改版其實並沒有多麼的頻繁，而且Sun在向下相容的誠意是很夠的。
如果我們談的是bug fixing的Maintenance或Update，那麼問題恐怕沒像牛毛那麼多，真的關鍵又需要考量的，大概就只有新版本是否會帶來新的bug這件事。但理論上，只要改code就有可能引發副作用，這就是命運。就算你們有一堆人很認真的看著release notes去評估，把所有手上的test case都跑過一遍（事實上，你的test cases不一定有Sun的多），都還是沒法子保證這件事。更何況，這種bug fixing的情況，如果不是release note中踩到你希望解決的bug，誰會急著要更換bug fix後的版本呢？
所以，在這邊我再次整理我的論點Mr. Saturday提到的這種規模的公司，我不知道全球有多少家，如果有達到這種規模，他們應該很賺錢，做這種投資是合理的，事實上，要coordinate這麼多programmers，付出的其他管理成本相信更高。Google甚至hire了一堆原先在Sun做JDK的高手，為的就是確保Google對Java的掌握。可是大多數人所面臨的情況都不是這樣子的特例，他們有必要苦苦追趕Java版本的變化嗎？軟體開發是現實的工程問題，你要考慮投資跟回收的C/P比。去關心任何一個update的版本，對你來說意義其實都微乎其微。以Google對Java的倚重之深，就算setup一個50人的team天天在看盯著JDK看也不為過，而且這投資也不算太多。但對絕大多數人來說，這樣子的例子一點意義都沒有。我們自己今天改寫的code，也許就無法通過明天自己daily build的unit testing的test case。如果我們要談的是一般人，就該更巨觀的來看整個現象，並不是每個人都在Google工作，使用Java是我們日常生活的一部份，就應該更務實一點的來看看我們每個人都可能面臨的局面。
Blogged with Flock
Posted at 12:57上午 一月 05, 2008 by Chien-Hsing Wang in General | 迴響[6]
不過就如 koji 說的, 基本上每個語言都有升級問題呀, 沒有人躲得過吧..
舉 qing 上一篇提到的 DDE dll, 在 windows 平台上也是翻過了三次, 從 win 16, win32, 到 .net..
當然這整個過程是 10 年多一點, 但這三次 windows 上的升級都是完全打掉重練, 甚至換語言..
這樣看來, Java 的升級真的是完全不算什麼呀..
而提到 library 相容性的問題, 我想我一生花在 windows 開發上遇到的不相容問題 (如 dll hell, .NET GAC, ...), 應該還是比 Java 多吧..
雖然 Java 很天真的不對版本做任何控管機制, 但也因為這樣的天真, 所以還滿容易 debug 的, 反正就是看過一次 classpath 就知道..
其他系統用複雜的方法解決這版本問題, 我覺得反而是增加除錯困難度, 而實際上還是會衍生出各式奇怪的問題讓你摸不著頭緒..
另外, qing 請不要因為那個 DDE dll 而記仇呀, 我相信它對你後來專救爛專案的職業生涯有很大的啟發作用..
由...發表 tempo on 一月 05, 2008 at 01:34 上午 CST #
...沒想到又引起筆戰了，實在非我本意 Orz
其實我一直覺得這種議題是沒有真理的，每個人都會因為自己的經驗而有不同的看法．我的確是在 qing 提到的 G 社工作就是了，所以會對版本升級有這樣的感受，並非要反駁誰，只是把自己小小的經驗拿出來講講而已．qing 應該也花了很多時間回文吧 ... 真是大感謝，從你的文章我也學到了不少，我想這就是討論帶來的最大好處吧．另外你的確是前輩沒錯，至少就年齡這一點我可以確定 XD，而且以你的功力，尊稱一聲前輩也不為過吧 :P
由...發表 Mr. Saturday on 一月 05, 2008 at 03:51 上午 CST #
我倒不覺得是筆戰，目前為止還都是理性的討論而已啊。。XD
由...發表 良葛格 on 一月 05, 2008 at 09:11 上午 CST #
我是來騙點數的
我有認識三家公司有足夠多的java programmer
TCS
Infosys
第三家 公司名字很難拼 也是印度公司
我有經歷過協調近百人的JAVA programmer的經驗
結論只有一句話
去死吧
跟那麼多人玩 先去擔心人力素質吧
談JDK版本？
對於把JAVA當TrueBasic用的人談JDK？
去死吧
話說 我好像要凹你上課 大濕
不過我有點想改凹C的課 你有上來或我有回去再談談
由...發表 orson on 一月 05, 2008 at 10:01 上午 CST #
我也要凹你來JUG耶大濕XD~
TWJUG的新竹行辦在三月怎樣哈哈
雖然我還沒問問大家能不能去新竹
由...發表 koji on 一月 05, 2008 at 10:47 上午 CST #
To Mr. Saturday,
你客氣啦, 沒的事啊, 怎麼會是筆戰呢? 這都是以文會友啊~
下回約你和PinTing一起去吃阿吉師啊 XD
由...發表 Qing on 一月 05, 2008 at 04:10 下午 CST #