我對相對論有些了解，但這個問題也是想了很久，以下請指正。

以五千萬光年距離的星體來說，其後退速度應該也蠻接近光速的，由地球上看該星體，星體的時間會走得會非常慢。意思是說，雖然在地球上過了三十年，但現在看到的光並不是誕生後三十年時發出的，也許是誕生後一年發出的，也就是現在可能看到的是一歲時的樣子。

但上面分析只考慮狹義相對論與哈柏常數的效應。這個例子又扯到必須用廣義相對論來解釋的黑洞。

黑洞本身不發光，或者說發射的光都會落回黑洞。因此我們看不見黑洞本體。而在黑洞事相地平面之外的光，是可以來到地球，但越接近事相地平面的光，必須花越久時間脫離 (趨近於事相地平面上的光，則要花趨近於永遠的時間才能脫離)。

因此除了超新星爆炸所產生的強光外，我們僅能看到中心星體蹋陷當中，且位於事相地平面之外的部份所發出的光。而且由外界看，其蹋陷過程是無限久 (因為越近的光要花越久的時間才能到達外界觀察者)。這也導致其波長很快被拉長，紅移至非常非常微弱的程度。

也就是說，即使位在該黑洞旁，比如說一光年的位置觀察，不用考慮狹義相對論與哈柏常數之效應。三十年後所看到的光，仍然是處於蹋陷當中，事相地平面之外的光，也就是看起來該星體仍緩慢地蹋陷當中…

狹義與廣義相對論的結果都是看起來時間變慢，因此結論是，現在所能「看到」的並不是黑洞本體三十歲的樣子，而是仍在誕生之初，也許幾秒、幾分鐘內，形成貨真價實之黑洞之前蹋陷中的樣子。

再論實際的天文觀測。上述所謂蹋陷中樣子的光，很快就變得微弱地偵測不到，技術上能偵測到的是周圍吸積圓盤，周圍物質被吸入黑洞前，被強大潮汐力撕碎時發出的強烈光線，也就是原文中的 X 光。

所謂潮汐力，就是不同距離所感受到的重力不相等所產生的拉力。最直接的例子就是地球海水因月球 (及太陽) 重力而有面向月球及背向月球處有海水升高的潮汐現象。黑洞端處的引力大於背對端處的引力，而且引力之差大到足以撕碎任何大小與質量的物質，包括原子、原子核在內。所以雖然有可能「通過黑洞/蟲洞」到達「另一世界」，但在到達前，太空船與太空人都已化為基本粒子，原本的樣子都不復存在了，怎麼可能活著見到另一世界呢?

而吸積圓盤，則是因廣義相對論的重力拖曳效應，也就是質量的移動會拉扯，扭曲四維時空。中子星都可以每秒旋轉數十圈，黑洞只會旋轉得更快 (旋轉這麼快是因為角動量守恆原理，如同溜冰選手縮手，旋轉會加快的道理一樣。高質量縮在極小半徑，轉速當然變得難以想像的快)，導致周圍物質也會被引力拖曳，一起旋轉。好像水中漩渦一樣，越近轉越快，越無法脫身。旋轉最快的地方自然是赤道，因此物質漩渦會向赤道平面靠近，看起來就成為如土星環，但更為大面積，越靠近越密集、扁平的「吸積圓盤」了。

當然，就外界觀察者而言，周圍物質吸入黑洞的過程，一樣是無限久。越接近越慢、越暗、越紅移、越旋轉、越壓扁 (因為靠近端「看起來」向黑洞前進得比遠離端更慢，故「看起來」越來越扁，事實上，潮汐力會讓靠近端向黑洞前進得比遠離端更快，所以實際上是前後拉長)。

因為個人因素，這個網站以及 Ning 網站一直沒有好好灌溉。沒想到 Ning 準備要全面收費了…Windows Live Spaces 也一直沒改善…看來是該換新據點的時候了…我也不知道要換到哪裡比較適合…暫時先轉到我的 FaceBook 帳號 Chris Torng，仍然想追蹤我的消息的人，就加入好友一下吧…

另外我推薦 Scrum Community in Taiwan、David Ko 的學習之旅與 Teddy Chen 搞笑談軟工。我有很多觀念都是向他們學習的。

MOQ The simplest mocking library for .NET 3.5 and Silverlight with deep C# 3.0 integration 看起來還蠻有趣的，想寫 Mock 的人可以參考一下。

我自己先前也有為了測 Exception 而使用了 lambda expression，覺得 lambda expression 是個全新的寫程式方法，一開始看起來會比較難理解，但有時可以減少很多程式碼…減少程式碼又會讓程式碼較易讀…

標準的測試寫法，在待測函式會丟出預期中的例外時，要使用 [ExpetationException]，但只能一個 TestMethod 測一個例外。我寫的這個功能，是為了在同一個 TestMethod 中可以測試多個會丟出例外的目標函式。

程式碼很短，貼出來供參考:

[TestMethod]
public void TestThrowExceptions()
{
    Foo foo = new Foo();

    try
    {
        foo.ThrowArgumentException();
        Assert.Fail();
    }
    catch (Exception ex)
    {
        if (ex.GetType() != typeof(ArgumentException))
            Assert.Fail();
    }

    try
    {
        foo.ThrowArgumentNullException();
        Assert.Fail();
    }
    catch (ArgumentException ex)
    {
        if (ex.GetType() != typeof(ArgumentNullException))
            Assert.Fail();
    }
}

非常地長…而且重覆的地方很多…但 try/catch 樣式又沒辦法包在共用的子函式中重覆呼叫，因為裡面有 foo.xxx() 會每次都不一樣…這就令我想到: 匿名函式可以上場了…

以下是可以重覆使用的測試函式:

public static void Throws(Type exceptionType, Action action)
{
    if (exceptionType == null)
    {
        throw new ArgumentNullException("exceptionType");
    }

測試的寫法為:
AssertExtension.Throws(typeof(ArgumentNullException),() => foo.Bar());

public static void Throws<T>(Action action) where T : Exception
{
    try
    {
        action();
    }
    catch (Exception actualException)
    {
        if (actualException.GetType() != typeof(T))
        {
            Assert.Fail("預期要丟出例外 {0}，但卻丟出例外 {1}。此例外之內容為: {2}", typeof(T).ToString(), actualException.GetType(), actualException.ToString());
        }

測試的寫法為:
AssertExtension.Throws<ArgumentNullException>(() => foo.Bar());

因為在原來的寫法，丟入 exceptionType 有可能不是 Exception 類別，因此要在執行時期做檢查。新的寫法，若是不正確的類別，會無法通過編譯…因此就不必做執行期檢查。而且測試的寫法也更精簡一點。

所以連續測試丟出例外的 TestMethod 可能是這樣:
[TestMethod]
public void TestFooToInt()
{
    Foo foo = new Foo();
    AssertExtension.Throws<ArgumentNullException>(() => foo.ToInt(null));
    AssertExtension.Throws<ArgumentOutOfRangeException>(() => foo.ToInt("a"));
    Assert.AreEqual(1, foo.ToInt("1"));
    Assert.AreEqual(-1, foo.ToInt("-1"));
}
這樣就可以在同一個 TestMethod 用很簡單的寫法測會丟出例外的函式了。

一開始寫 MOQ，到後面全部是寫我自己的東西，跟 MOQ 沒什麼關係…

在 ZDNet 中 [網路部落格]瀏覽器只要快就好？我所寫的回應，轉來此處與大家分享。

Chrome 可以搶得到的佔有率，主要應該是 IE 以外的 FF/Opera/Safari 等，因為用 IE 的人還是繼續會用 IE，會想用 FF/Opera/Safari 等其他瀏覽器的人，也才會想試用 Chrome，而可能被它吸引。最該緊張的應該是 FF 吧。

FF 之前才拿到三年的 Google 合約，可見 Google 並沒有想要吃掉 FF，而是希望 FF 繼續侵蝕 IE 市場。

如果真想要搶 IE 的佔有率，最簡單的做法不是遵循標準，而是完全支援 IE 的所有語法…Chrome 沒有這麼做…

Google 自己都講了，它並不在乎 Chrome 的市佔率。它的推出，更重要的任務是逼迫其他瀏覽器的速度也要加快，最好也加上防當、應用程式捷徑等讓一般網站變得像本機應用軟體的特性。所有的瀏覽器速度加快了，執行速度變得跟本機應用程式相當，使用者就會更喜歡使用網路應用程式，而不喜歡自行安裝本機軟體了。

因此，免費開放原始碼的 Chrome 市佔率即使是 0%，只要大家都喜歡使用網站服務，Google 的目的就達到了。Google 想賺的錢是來自線上流量/廣告，而 Google 網站使用 JavaScript 的量又特別大。加速 JavaScript 這個環節，讓網站服務執行速度與本機一樣快，這就是 Google 所要的。

使用者習慣上網處理工作，而不是在本機安裝軟體後，裝置/OS 的重要性就日漸降低，不在乎你用什麼裝置、OS、瀏覽器，反正只要一上網，什麼工作都可以做。不必再搞防毒、備份、一堆 Windows 更新又得重開等麻煩的事情。

IE 為了保住佔有率，也得加把勁加速 JavaScript 及其他部份的執行速度，這也讓自己的 OS 版本變得不重要 (大家就不必再吵需不需要升級 OS 了)，自己打敗自己。這就是 Google 對抗微軟的絕招，Chrome 成功失敗都無所謂，反正 Google 只要專心做第一名的線上服務提供者即可。

Google 更想藉由 Chrome 表達的，是「你們的瀏覽器都太複雜了」，在一堆華而不實的功能上做文章，卻沒有把核心執行速度放在第一位。他想要證明：「你們瀏覽器裡的那一堆功能，我可以全部搬到網路上來做。」

因此， Google 瀏覽器真的只是一個很簡單的窗口，窗口不必做什麼花樣，只要窗外的世界更美好就夠了。

我只好奇一點，Google 瀏覽器為何沒有全螢幕顯示的功能。就是完全蓋住工作列，只用瀏覽器執行日常工作，瀏覽器的 Tab 就可以切換各個「應用程式」，完全取代工作列了…

更甚者， Google OS 也可以推出來，只需要比 Linux 更更簡單的硬體，只有瀏覽器一個功能，一切只要上網都可以解決。(當然我知道這個可能講得太誇張了，但，是否可能是將來的趨勢?)

上線費用太貴? 沒問題，只要你願意看廣告，一切都是免費的。電腦可以送給你，GPhone 也可以送給你。免月租費，免連線費，一切全部免費。所有的活動都由廣告商支付，換個方式講是所有想賣商品給消費者的廠商，將支付一切的線上活動費用，只求你上它的網站進行消費。

微軟已經被逼得要走上相容於標準之路，將來所有網站撰寫者的工作將會更容易，可以寫一套全部都能跑。

還想要撰寫本機軟體嗎? 還想下載、安裝、破解，與莫名奇妙的問題奮鬥、防毒、備份嗎?

還想學各種程式語言與技術嗎? 何不把 HTML/CSS/JavaScript 這一套徹底搞通就好?

越加越多功能的 Windows 還賣得出去嗎? 偏偏那些功能上網就有免費的…
.
.
.
.
.
.
你所要付出的代價，就是隱私。

Google 在隱私這方面是一直受爭議的。是的，廣告要賺錢，第一就是掌握客戶資訊，才能精準行銷。

Google 的策略，資料與軟體都在它的伺服器上，一切上網都能解決，你就是相信它，把你的一切都交給它。它如果關了，你的一切也就沒了。

再來還可以扯到 Live Mesh。Live Mesh 是微軟仍然要讓裝置很重要，讓你所屬的所有裝置，任何現有既成的軟體，都能很輕易地互相同步 (這樣你就不需要依賴線上服務來達成到處皆可取得的特性)，沒有自己所屬裝置時還有 Live Desktop，其上的使用經驗與本機 Vista 完全相同。但這也限制了它的使用族群，基本上只在 Windows 使用者裡。Google 的策略則針對所有使用者，而且管道是大家早都有也用得很習慣的各式瀏覽器 (Google 並沒有期待你要用 Chrome 上網!)，而不是目前還在 Tech Preview 的全新軟體 Live Mesh。依我個人目前看起來，Google 的策略贏面較大。

由 Live Mesh 來看微軟的策略，軟體可以安裝在你的電腦上，資料也可以本機處理，每一個裝置之間自動同步資料也可以完全點對點完成 (目前還不行，將來的版本才行)，根本不會到微軟手上。微軟伺服器只用作當你不在自己的電腦上網時，還有最後一個備用方案。你想放全部資料進去也可以，完全沒有也沒關係，只是有時會不太方便。

企業會比較不願意把資料交給外人管理。但它也不想沒事被逼著簽軟體合約，兩三年就換一版 Windows、Office 或 IE，把本來用得好好的資訊系統給搞砸，又得花額外的人力去處理多餘的問題。

我也在推測，微軟在 Windows 7 之後，何去何從? 我公司內的網站/軟體，到現在連 IE7/Vista 都還沒辦法完全相容，還有可能去買 Windows 8/Office 201x ??????

Windows 8/Office 201x 可能沒人要買了…微軟怎麼辦? 要針對全網路時代，重新發明新的網路 OS??? 那過去一切的優勢都歸 0 了? 但現有優勢也一直在流失中…不做是不是等死?

Google 瀏覽器不會對瀏覽器市場的佔有率分配有多少影響。但它的釋出，將影響所有的瀏覽器，把核心功能做得更快，提高一切線上服務的可用性，降低作業系統與裝置的重要性。

Google 將會大大得利，微軟則會陷入「要不要以自己的線上服務 打自己的本機軟體」的矛盾苦戰。

你要選擇將自己的一切交給一家公司，完全相信它會好好保管你寶貴 (也許其中許多根本就不寶貴，只不過因為免錢，沒必要留的垃圾也全放進去) 的資料，將來有格式轉換時，一定會幫你轉換到最新的平台? 至於資料放在它那兒，它要怎麼運用，就相信它的隱私權說明了，雖然你從來也沒看過裡面寫些什麼…

還是選擇把隱私、資料放在自己的裝置上，自己想辦法維持電腦正常運作，克服一切的麻煩問題，任何的格式轉換、備份也自己包辦?

感謝 Tony 提醒，告知 ChrisTorng 樣式訊息記錄在 Vista 下無法儲存設定的問題，另我也發現刪除對話階段功能亦有問題。慚愧的是，雖然我自己也使用 Vista，但卻從未用過自己的訊息記錄工具。目前我仍不確定問題是 Vista 造成還是 IE7 造成，若有朋友有 XP 已安裝 IE7 可回報一下是否正常。

刪除對話階段之問題目前仍不知如何解決。而儲存設定的問題，追查了一下，遇到兩個問題，一個是檔案路徑分隔字元原本是 "\"，現在變成 "/"。這個問題倒容易解決。另一個問題，不支援中文檔案路徑。目前會遇到的中文檔案路徑，包括「我已接收的檔案」及「記錄」兩者。我試了一下，找不到方法可以正確讀寫中文檔案路徑，只試出來純英文路徑是正常的。因此必須要將訊息記錄移至純英文路徑上才能正確讀寫設定檔。

也就是說，就目前來說，要修正儲存設定的問題，我想到兩個方法：「改程式＋改路徑」與「直接改設定檔」。

方法一：改程式＋改路徑

這個方法可以解決無法儲存設定的問題，適合於常常修改設定的人。
以記事本開啟 ".\ChrisTorngStyle\SettingProcess.xsl"，找到：
function GetCurrentPath()
{
    var Path = decodeURI(location.pathname.substr(1));
    return Path.substring(0, Path.lastIndexOf("\\") + 1);
}
將這段代換成：
function GetCurrentPath()
{
    var Path = decodeURI(location.pathname.substr(1));
    var LastSlashPos = Path.lastIndexOf("\\");
    if (LastSlashPos < 0)
    { LastShashPos = Path.lastIndexOf("/"); }
    return Path.substring(0, LastShashPos + 1);
}
即可修復路徑分隔字元問題。
再來要把訊息記錄路徑上所有非英文字換成英文，在繁體中文版中包括「我已接收的檔案」及「記錄」兩者。可換成英文版的 "My Received Files" 及 "History"。然後在 Windows Live Messenger 中亦需設定新的訊息路徑：「工具 – 選項 – 訊息 – 將我的對話內容儲存在此資料夾」。

方法二：直接改設定檔

如果只需要設為繁體中文，不需要常常改設定值的話，建議用這個比較簡單的方法。
設定檔位於訊息記錄資料夾內 ".\ChrisTorngStyle\CurrentSetting.xsl"，以記事本開啟，將其中的 "Language_en-us.xsl" 代換成 "Language_zh-cht.xsl" 存檔後即可。
所有可用的語言檔名列在 ".\ChrisTorngStyle\AllSetting.xml" 中之 "AllSettings\Languages\Language\File" 段落，可以任選其一。其他 "CurrentSetting.xsl" 中的設定值，只要看得懂一些英文，相信不會太難看懂，如果有需要的話可自行修改，只要小心別動到 9/30/true/false 這些設定值以外的字元即可。

ChrisTorng 說 (上午 12:45):
其實我很想推動反 cmmi 運動
ChrisTorng 說 (上午 12:45):
妳有聽我談過 cmmi vs agile 嗎？
Timi 說 (上午 12:45):
哈
Timi 說 (上午 12:45):
沒
ChrisTorng 說 (上午 12:45):
有看過我的 agile 簡報嗎？
Timi 說 (上午 12:45):
嗯我剛下載了
ChrisTorng 說 (上午 12:45):
那妳了解 agile 嗎？
Timi 說 (上午 12:45):
嗯 我會把我之前的經驗一起分享
ChrisTorng 說 (上午 12:46):
那是去年寫的報告了，我現在覺得有更深的想法
Timi 說 (上午 12:46):
算是後輩的一點小見解
Timi 說 (上午 12:46):
嗯了解
ChrisTorng 說 (上午 12:46):
妳是我 space 中看的嗎？
Timi 說 (上午 12:47):
嗯
Timi 說 (上午 12:47):
事啊
ChrisTorng 說 (上午 12:47):
就是下載「團隊開發報告投影片」那個檔案吧
Timi 說 (上午 12:48):
對啊
ChrisTorng 說 (上午 12:48):
然後妳也看了「CMMI：軟體業的紅海漩渦」這篇吧
ChrisTorng 說 (上午 12:48):
我還有寫更多，但真的沒時間去完成它們
Timi 說 (上午 12:48):
事啊
ChrisTorng 說 (上午 12:48):
我把尚未完成的文章傳給妳
Timi 說 (上午 12:49):
我覺得 所謂的新標準就制只有對制定者有意的才較標準
Timi 說 (上午 12:49):
OK
Timi 說 (上午 12:49):
我之前也有根 SONY TOSHIBA 等新標準制定者聯繫
Timi 說 (上午 12:50):
有一些小的經驗
ChrisTorng 說 (上午 12:52):
總之我認為 cmmi 是符合美國國防部的要求的產物，但台灣的案子，我認為即使到一億，跟美國國防部的規模仍然不能比
ChrisTorng 說 (上午 12:52):
寫 100 行的程式當然不可能用 cmmi
Timi 說 (上午 12:52):
我就直接講我的港售就是新標準的制定是為了讓很多人陷入惡性的循環之中 ,因為新標準就像是蓋大樓一樣
ChrisTorng 說 (上午 12:52):
寫 1000 行也不用
Timi 說 (上午 12:52):
對啊
Timi 說 (上午 12:52):
嗯
ChrisTorng 說 (上午 12:52):
一萬很可能還是不需要
Timi 說 (上午 12:53):
嗯
Timi 說 (上午 12:53):
我同意
ChrisTorng 說 (上午 12:53):
它也許是對付一千萬行適合
ChrisTorng 說 (上午 12:53):
但如果是 一百億行的程式，那 cmmi 就鐵定不夠用
Timi 說 (上午 12:53):
例如像甲骨文的那一種 ERP
ChrisTorng 說 (上午 12:53):
台灣很多軟體開發的規模根本不到 cmmi 的等級
ChrisTorng 說 (上午 12:53):
但所有的人都搶著要用
Timi 說 (上午 12:53):
我覺得只有那一種大型的使用者介面才會用的上
ChrisTorng 說 (上午 12:53):
盲從
Timi 說 (上午 12:53):
對啊
ChrisTorng 說 (上午 12:54):
我公司就是這樣，我認為是亂搞
ChrisTorng 說 (上午 12:54):
最知名的洪顧問，就帶頭做假
Timi 說 (上午 12:54):
哈
ChrisTorng 說 (上午 12:54):
古人說削足適履，我認為我們是打腫足去適履
ChrisTorng 說 (上午 12:55):
cmmi 好像有很多 process area，一個團隊好像至少要 18 個人才有辦法把角色分工完
Timi 說 (上午 12:55):
以前的認證機制就是出現了問題所以舊直接使用新的標準來想要一切重頭
ChrisTorng 說 (上午 12:55):
我們公司的團隊大都十人左右或更少
ChrisTorng 說 (上午 12:56):
因為人數不夠 cmmi 要求，所以顧問要我們併案
Timi 說 (上午 12:56):
一般而言RD 團隊都不會太多
ChrisTorng 說 (上午 12:56):
也就是好幾個案子併在一起，還是各做各的案子，但合在一起報告
ChrisTorng 說 (上午 12:56):
併案因此可以滿足 cmmi 要求
ChrisTorng 說 (上午 12:56):
但還是各做各的
ChrisTorng 說 (上午 12:56):
這不是公然造假嗎？
Timi 說 (上午 12:56):
對啊
ChrisTorng 說 (上午 12:56):
顧問自己帶頭偽造文書
Timi 說 (上午 12:57):
哈說的好
ChrisTorng 說 (上午 12:57):
如果你照著 cmmi 要求，認真把所有環節做好，那你可能可以得到 cmmi 承諾你的好處
ChrisTorng 說 (上午 12:57):
但如果產出的內容是假的話，那麼這個文件的產出根本沒有意義
ChrisTorng 說 (上午 12:58):
level 5 是要做 optimize，但如果根據造假的文件，如何做出正確的 optimize 決策？
ChrisTorng 說 (上午 12:58):
所以我說是浪費所有的人的時間
ChrisTorng 說 (上午 12:58):
即使通過 level 5 認證，軟體品質還會越來越低落
ChrisTorng 說 (上午 12:59):
高鐵售票就是最好的例子
Timi 說 (上午 12:59):
不過你想一下一個案件不是只有淪入文稿 , 因為整個 RD 力量的投入 , 相對的要去頻估許多的東西 , 時間 相對成本 以及事後的報酬率
ChrisTorng 說 (上午 12:59):
我還有另一段文章，但現在這裡沒有
Timi 說 (上午 12:59):
嗯
ChrisTorng 說 (上午 12:59):
所以 agile 就是反其道而行
Timi 說 (上午 12:59):
嗯
ChrisTorng 說 (上午 01:00):
cmmi 是由管理者的角度，他想要做完善的管理
ChrisTorng 說 (上午 01:00):
agile 是由開發者的角度，他想要做真正優良的程式
ChrisTorng 說 (上午 01:01):
我想寫一篇文章，列出 cmmi 理論上行不通，實務上行不通，結局是註定失敗
Timi 說 (上午 01:01):
嗯是啊 因為是不對等的觀念 所以出發的方向相反 我認為絕果必然會是反項
ChrisTorng 說 (上午 01:01):
剛傳給妳的是實務上行不通的文章，也還沒完成
Timi 說 (上午 01:01):
嗯
Timi 說 (上午 01:01):
覺得
ChrisTorng 說 (上午 01:01):
理論上行不通的話，大體上包含幾點
Timi 說 (上午 01:01):
嗯
ChrisTorng 說 (上午 01:02):
軟體開發不是大量生產
ChrisTorng 說 (上午 01:02):
大量生產的話妳要有正確的設計圖，要不然大量生產錯誤的產品是嚴重的浪費
ChrisTorng 說 (上午 01:02):
軟體開發我只要做出第一套就可以了
Timi 說 (上午 01:02):
嗯
Timi 說 (上午 01:02):
事啊
ChrisTorng 說 (上午 01:03):
所以正確的設計對軟體開發而言，並不需要一開始完全確定
ChrisTorng 說 (上午 01:03):
反而應該是先把軟體寫好，驗證是優良的軟體，那麼最後的實作所呈現的架構，才是正確的設計
Timi 說 (上午 01:03):
嗯 其實妳這想法你就把它想成硬體也會改版
ChrisTorng 說 (上午 01:03):
程式寫出來，驗證正確的程式，才會是正確的設計
Timi 說 (上午 01:04):
對啊
ChrisTorng 說 (上午 01:04):
寫軟體比較像做工程樣品，原型
Timi 說 (上午 01:04):
嗯是啊
ChrisTorng 說 (上午 01:04):
實驗室做第一個時，一定知道自己會做出很多份原型，然後反覆修改，最後才能確定完整的設計
Timi 說 (上午 01:04):
對啊
ChrisTorng 說 (上午 01:05):
確認完成的原型，反推出它的設計，這才能交付大量生產
ChrisTorng 說 (上午 01:05):
軟體開發只需要把原型做出來即可
Timi 說 (上午 01:05):
因為走出實驗室一直是我在輔導新公失的重點
ChrisTorng 說 (上午 01:05):
所以先完成設計，再來程式實作，是完全錯誤的流程
Timi 說 (上午 01:05):
對
ChrisTorng 說 (上午 01:06):
如果是打造世上唯一的跑車，一定是幾個專業技工，先有初步的草圖
Timi 說 (上午 01:06):
我的認為是直接把所謂的80 分的產品走入市場
ChrisTorng 說 (上午 01:06):
然後就開始動手做，裝起來不滿意再改，改改改最後就完成滿意的跑車
Timi 說 (上午 01:06):
之後市場會慢慢的回饋你較為貼切的看法與需求
ChrisTorng 說 (上午 01:07):
所以第二點是軟體開發是不斷地修改而成
Timi 說 (上午 01:07):
相對的你會完成 120 分的產品\
Timi 說 (上午 01:07):
嗯是啊
ChrisTorng 說 (上午 01:07):
cmmi 這種的，你一開始要完成設計，然後寫程式就一次寫完
Timi 說 (上午 01:07):
哈那是笑話
Timi 說 (上午 01:07):
就像是雞生蛋的問題
ChrisTorng 說 (上午 01:07):
如果我有完全正確的設計，那麼妳可以依據該設計，開始寫程式
Timi 說 (上午 01:07):
這是我的認為
Timi 說 (上午 01:07):
嗯
ChrisTorng 說 (上午 01:08):
從第一行寫到第一百萬行，都不用編譯測試
ChrisTorng 說 (上午 01:08):
然後妳期待寫完後程式就會跑了，而且跑得很棒
Timi 說 (上午 01:08):
咚
ChrisTorng 說 (上午 01:08):
根本就是不可能的事
Timi 說 (上午 01:08):
能這樣就不需要 DEBUG TEM
Timi 說 (上午 01:09):
FAE 也不需要了
ChrisTorng 說 (上午 01:10):
如果是建築，妳不可能做一個橋墩橋面，然後就做一個上下的交流道，車子上去跑跑看確認這一小段沒問題，然後拆掉交流道再做下一個橋面，然後再做新的交流道去測它
Timi 說 (上午 01:11):
嗯
ChrisTorng 說 (上午 01:12):
以建築來講，一開始的確需要完全的設計，要不然等建到十層樓，才想到還沒做地下停車場
ChrisTorng 說 (上午 01:12):
建築的修改太耗成本
ChrisTorng 說 (上午 01:12):
但軟體是不斷修改中而產生
Timi 說 (上午 01:12):
事啊
ChrisTorng 說 (上午 01:12):
妳寫了一百行，就得做一個收尾，讓整個程式可編譯，可執行，可以看這一百行的結果是不是正確
ChrisTorng 說 (上午 01:13):
正確以後，然後繼續做 method，加 class，做一小段，又得「收尾」讓它能編譯能跑
ChrisTorng 說 (上午 01:13):
所以我說程式撰寫是在不斷修改中完成，不可能從頭到尾一次寫對
ChrisTorng 說 (上午 01:14):
所以需求分析/設計/實作/測試，應該是在很小的循環，不斷反覆
ChrisTorng 說 (上午 01:14):
而不是像 cmmi 說的，先完成分析，再來完成設計，接下來依設計來實作，最後才測試
ChrisTorng 說 (上午 01:14):
這是絕對不可能的
Timi 說 (上午 01:15):
你知道嗎  , 一個程式集 就是因為不斷的把有用的小程式集合在一起 這樣才能匯百成大川成大海
Timi 說 (上午 01:16):
不過 cmmi 卻是到過來
ChrisTorng 說 (上午 01:16):
我那些文章妳看完了嗎
Timi 說 (上午 01:16):
看完了
ChrisTorng 說 (上午 01:17):
是還沒完成啦
ChrisTorng 說 (上午 01:17):
我覺得最大的問題就是設計認證的人，自己不寫程式
Timi 說 (上午 01:18):
哈說的好
ChrisTorng 說 (上午 01:18):
以管理學的角度，他看得懂文件看不懂程式
ChrisTorng 說 (上午 01:18):
他認為照著一步步做程式當然會寫得好
Timi 說 (上午 01:18):
嗯是啊
ChrisTorng 說 (上午 01:19):
如果一個專案的結束，有一大堆很棒的文件，但軟體執行五分鐘就當，那客戶得到的價值可能是 0 分
ChrisTorng 說 (上午 01:19):
如果是得到一個很棒又符合需求的軟體，卻沒有任何文件，那他的價值可能還有 90 分
Timi 說 (上午 01:19):
你知道嗎 一個學管理學重大學出來的人 , 筆不上一個經歷過 EMBA 的人 那是位啥 , 就是實務經驗
ChrisTorng 說 (上午 01:19):
反正程式很好，連維護都不用，因為它會自己自動化工作
Timi 說 (上午 01:20):
嗯
ChrisTorng 說 (上午 01:20):
只有那一天機器掛了，你需要重灌時，才會發現需要安裝手冊
Timi 說 (上午 01:20):
對啊’
ChrisTorng 說 (上午 01:20):
文件有一些是必要的，那就應該要給客戶，有很多文件是沒有任何意義，寫完後就沒有任何人會去看它
ChrisTorng 說 (上午 01:21):
他們會說留下記錄很重要，我會說留下的記錄全都是假記錄，留之何用？
Timi 說 (上午 01:21):
哈說的好
ChrisTorng 說 (上午 01:21):
我先前的案子，是接手以前別的廠商的案子
ChrisTorng 說 (上午 01:21):
他們就有一堆文件
ChrisTorng 說 (上午 01:21):
但現場的人說，那堆文件都不可靠，最後還是看程式碼才是真的
ChrisTorng 說 (上午 01:22):
這就是沒有用的文件
ChrisTorng 說 (上午 01:22):
如果專案時程真的充裕的話，是有可能把文件一一完成
ChrisTorng 說 (上午 01:22):
但這要有高價的標金支持
Timi 說 (上午 01:23):
事啊
ChrisTorng 說 (上午 01:23):
才能讓開發團隊好好做所有的事，花很多時間很多人力把事情做好
ChrisTorng 說 (上午 01:23):
如果沒有高價標金，那他也不想耗在上面，結果就是隨便做一做了事
ChrisTorng 說 (上午 01:23):
美國國防部出得起錢，他要得到真的好的東西
Timi 說 (上午 01:24):
對啊
ChrisTorng 說 (上午 01:24):
台灣的，金額一樣，時程一樣，但政府現在要 cmmi l3，以後就要 l5
ChrisTorng 說 (上午 01:24):
價錢還是不便
ChrisTorng 說 (上午 01:24):
變
ChrisTorng 說 (上午 01:24):
你說做出來的東西是什麼？
ChrisTorng 說 (上午 01:24):
以前沒 cmmi 一樣價錢一樣時程，現在要 cmmi 也是一樣
Timi 說 (上午 01:24):
哈
ChrisTorng 說 (上午 01:24):
所以我的結論是，cmmi 必定失敗
Timi 說 (上午 01:25):
哈
ChrisTorng 說 (上午 01:25):
認證制度還是會繼續，因為無知的客戶還是會在合約上寫要求 cmmi
Timi 說 (上午 01:26):
哈
ChrisTorng 說 (上午 01:26):
但開發團隊終究會了解到，做 cmmi 並不可能得到好處，只能做假應付客戶而已
Timi 說 (上午 01:26):
說的好
ChrisTorng 說 (上午 01:26):
所以就像 iso 一樣，大家都另外做一套，但公司還是得拿出「我們通過iso認證」來做文章
ChrisTorng 說 (上午 01:27):
看兩三年後，會不會又有新的認證出來
Timi 說 (上午 01:27):
哈
Timi 說 (上午 01:27):
一定會
ChrisTorng 說 (上午 01:27):
然後大家又把 cmmi 丟一邊，像 iso 一樣
ChrisTorng 說 (上午 01:27):
去追求新的認證
ChrisTorng 說 (上午 01:28):
或者有人會發現到，越來越大的流程，根本就不合用
Timi 說 (上午 01:28):
嗯
ChrisTorng 說 (上午 01:28):
反正新的認證一定會有更多的要求，不可能會少的啦
ChrisTorng 說 (上午 01:28):
講 cmmi 的就是會發明一堆新名詞，讓你看起來好像很厲害
ChrisTorng 說 (上午 01:29):
說穿了全部都是廢物
ChrisTorng 說 (上午 01:29):
所以我說外行領導內行
Timi 說 (上午 01:29):
哈
ChrisTorng 說 (上午 01:29):
真正在 coding 的人，沒辦法跟主管說明 cmmi 沒用，他不敢說自己做的文件都是假的
ChrisTorng 說 (上午 01:30):
主管不寫程式，他只知道通過認證的話，他可以多拿到一些案子
ChrisTorng 說 (上午 01:30):
管它下面加班做得要死要活，他就是要這個頭銜
ChrisTorng 說 (上午 01:30):
底下是做假他也心知肚明，但反正能通過認證就好了
ChrisTorng 說 (上午 01:31):
就像那個顧問帶頭做假一樣
Timi 說 (上午 01:31):
嗯
ChrisTorng 說 (上午 01:31):
如果要做真的，結論是我們的團隊人數都不足，無法做 cmmi
ChrisTorng 說 (上午 01:31):
於是他就收不到我們的認證的錢了
ChrisTorng 說 (上午 01:32):
但他要賺錢啊，於是帶頭做假，教我們如何做假應付 cmmi 的要求
ChrisTorng 說 (上午 01:32):
因此他拿錢發認證給你
Timi 說 (上午 01:32):
哈
Timi 說 (上午 01:33):
這樣子我就清楚了
ChrisTorng 說 (上午 01:33):
所以設計認證的是聰明人，跟著照做的是笨蛋
Timi 說 (上午 01:33):
哈
ChrisTorng 說 (上午 01:34):
客戶想說，反正寫一個 cmmi 在合約上，我就有了認證機構的保證，反正我的價錢不加時程也不延，何樂而不為？
ChrisTorng 說 (上午 01:34):
但可笑的是，不寫 cmmi 可能還會得到一個比較好的軟體，寫上去的話會得到一堆符合認證的文件，加一個爛軟體
Timi 說 (上午 01:34):
哈
ChrisTorng 說 (上午 01:35):
看看有沒有人能戳破認證的事實，教大家趁早認清認證無用
ChrisTorng 說 (上午 01:35):
所以我說我很想推動反 cmmi 運動
ChrisTorng 說 (上午 01:36):
其實我是不懂 cmmi
ChrisTorng 說 (上午 01:36):
但我知道在台灣 cmmi 鐵定失敗，因為案子規模都太小
ChrisTorng 說 (上午 01:36):
絕對不可能做真的
Timi 說 (上午 01:36):
嗯除非是跨國案件
Timi 說 (上午 01:36):
以及世界前百大公司
ChrisTorng 說 (上午 01:37):
cmmi 是有其適用範圍，我不是完全的反對
Timi 說 (上午 01:37):
嗯 事啊
ChrisTorng 說 (上午 01:37):
只不過大多數案子根本就不適用，用了反正更慘
ChrisTorng 說 (上午 01:37):
所以我想推動的就是認清台灣現實環境，不要再盲從
Timi 說 (上午 01:37):
因為恐龍塞不進汽車啊
Timi 說 (上午 01:38):
嗯
ChrisTorng 說 (上午 01:38):
有些超大案子也許適合 cmmi，但前提是客戶要拿出更多的錢，有更長的時程，這樣才能做真的 cmmi
Timi 說 (上午 01:38):
對啊
ChrisTorng 說 (上午 01:39):
我是很想推動，不過一定得花不少時間，現在我連一篇完整講論 cmmi 之錯誤的文章都還寫不完
ChrisTorng 說 (上午 01:39):
我覺得 cmmi 真的是紅海，地獄
Timi 說 (上午 01:39):
哈
ChrisTorng 說 (上午 01:39):
所以我會覺得我先前想推的團隊開發，還不如反 cmmi 重要
Timi 說 (上午 01:39):
清楚了
ChrisTorng 說 (上午 01:40):
我們學到很多技術，但還沒辦法發揮，就被 cmmi 搞死了
Timi 說 (上午 01:40):
哈
ChrisTorng 說 (上午 01:40):
沒有先破除錯誤的觀念的話，我們談一切的技術都是沒有用的
ChrisTorng 說 (上午 01:40):
cmmi 不重視技術
Timi 說 (上午 01:41):
嗯 他只重視流程
ChrisTorng 說 (上午 01:41):
你只要雇乖乖準時寫文件的專科生，就好了
ChrisTorng 說 (上午 01:41):
高薪但不怎麼聽話寫文件，意見一堆的人，對通過認證有阻礙，不要他了
Timi 說 (上午 01:42):
哈
ChrisTorng 說 (上午 01:42):
反正 cmmi 不需要英雄，一堆庸才也能做好訥證
ChrisTorng 說 (上午 01:42):
認證
Timi 說 (上午 01:42):
嗯
ChrisTorng 說 (上午 01:42):
又加上我公司也正在帶 agile，所以先前團隊開發的也停了
Timi 說 (上午 01:43):
清楚了
ChrisTorng 說 (上午 01:43):
即使我文章寫好發出去，得到很多人迴響
ChrisTorng 說 (上午 01:44):
但那也只有懂技術的人會認同
ChrisTorng 說 (上午 01:44):
主管只會聽那些滿口專有名詞的人的話，哪會理我？
Timi 說 (上午 01:45):
那你就只要寫當新的標準化成為標準時那下一個標準呢 ???
ChrisTorng 說 (上午 01:45):
另外，我的文章只會說 cmmi 的錯誤，但我沒辦法再說明，不要 cmmi 的話那要怎麼做
Timi 說 (上午 01:45):
就是剛剛我在打的
ChrisTorng 說 (上午 01:45):
當然我是偏 agile，但我認為純粹的 agile 也不符合企業的需要
Timi 說 (上午 01:45):
嗯
ChrisTorng 說 (上午 01:46):
我認為應該還要有個比較中庸的流程，這個我就沒有能力了，畢竟我也才剛剛開始帶團隊開發而已
ChrisTorng 說 (上午 01:46):
微軟的 msf for agile/cmmi 我認為比較中庸，我認為是真正可行又符合企業需要的
Timi 說 (上午 01:47):
嗯 清楚
ChrisTorng 說 (上午 01:47):
那就得看微軟行銷 msf 的能力了，看能不能憾動 cmmi 的勢力
ChrisTorng 說 (上午 01:47):
但 msf 是微軟的東西，很多團隊走 java/linux 的人不會理他
ChrisTorng 說 (上午 01:48):
而且 msf 又沒有認證
Timi 說 (上午 01:48):
哈說到重點
Timi 說 (上午 01:48):
嗯是啊
ChrisTorng 說 (上午 01:48):
你沒有辦法向客戶說，我們是使用 msf 開發流程，然後客戶就覺得你是很棒的團隊
ChrisTorng 說 (上午 01:48):
認證就是客戶喜歡的東西
ChrisTorng 說 (上午 01:49):
但是推動任何一種認證的結果，多半都是造假
Timi 說 (上午 01:49):
哈
ChrisTorng 說 (上午 01:49):
如果把 cmmi 拿掉認證，稽核，剩下的東西仍然是開發的好方法，但不可能有人在沒有認證與稽核的情況下，還會想好好做 cmmi 的
Timi 說 (上午 01:50):
哈
ChrisTorng 說 (上午 01:50):
就是要有人強迫你做不想做的事，你只是為了得那個客戶看得懂的頭銜而已
ChrisTorng 說 (上午 01:51):
好吧也夠晚了，我想講的重點也都講了，剩下的就是如何運用 agile，看能不能打敗 cmmi
Timi 說 (上午 01:51):
哈
Timi 說 (上午 01:51):
嗯
Timi 說 (上午 01:51):
我們可以開專題討論
Timi 說 (上午 01:51):
晚安摟
ChrisTorng 說 (上午 01:51):
謝謝妳陪我讓我講一堆
Timi 說 (上午 01:51):
部用客氣啦
Timi 說 (上午 01:51):
就互相交流
ChrisTorng 說 (上午 01:52):
滿肚想法，不過沒地方發
ChrisTorng 說 (上午 01:52):
想發文章，又不想隨便寫寫，想要把反 cmmi 的論點好好的說清楚
ChrisTorng 說 (上午 01:52):
然後就寫不完了
Timi 說 (上午 01:52):
嗯
Timi 說 (上午 01:52):
哈
]]> http://christorng1.wordpress.com/2007/03/14/%e8%81%8a-cmmi-%e4%b9%8b%e9%8c%af%e8%aa%a4/feed/ 1 christorng1 http://christorng1.wordpress.com/2007/01/10/windows-vista-%e6%96%b0%e7%b6%b2%e7%ab%99/ http://christorng1.wordpress.com/2007/01/10/windows-vista-%e6%96%b0%e7%b6%b2%e7%ab%99/#comments Wed, 10 Jan 2007 01:43:21 +0000 christorng1 http://christorng1.wordpress.com/2007/01/10/windows-vista-%e6%96%b0%e7%b6%b2%e7%ab%99 ]]>