Garbage In Garbage Out

　　今天一整天參加了 微軟 Windows Server 2008 & VisualStudio 2008 的聯合上市發表會 。這是個規模媲美要收幾千塊門票錢的 TechEd 的免費大型活動，看到微軟現場所動用的資源，可見這兩個組合真是微軟的心肝寶貝。 　　　　照例， 早上 Session Openning 一樣有精心拍攝不輸美國影集製作水準的宣傳廣告片，以及話劇演出。 　　每次看到這些，就會興起我幻想的念頭，將來我自己開的公司也要搞這些宣傳影片...。看來也許我跟李安一樣鍾愛的是拍電影、而不是寫程式做軟體。 　　縱然我從小就是喝微軟的奶水長大的，但心底總是對其他平台與技術心生嚮往，例如，Java & Linux。總希望有朝一日可以脫離微軟的束縛，我想那應該是件很有成就感的事。 　　但是看過這次微軟這兩款與我工作高度相關的重量級產品發表會，我越來越不能堅定這個願望。 　　加上這次透露今年九月後，微軟將會模仿當年 JavaApplet 的做法，推出真正可以跨平台、可以依附相容在所有各家瀏覽器的 mini CLR engine。這個重要的宣示意義，代表日後我們都可以直接使用原生的 .NET 語言來開發各種平台瀏覽器端的應用程式，如果這個願望成真，不但從此擺脫不同瀏覽器對 JavaScript 支援度不一致的惡夢，且可以在一個舒適一致的環境下盡情高速開發所有的網際網路應用程式，最重要的是，各個不同的作業系統，甚至 Linux 上都可以執行我使用 .NET 開發的軟體。 　　有這樣的願景，更加動搖我原本打算學習 Java 的想法 ( 因為當初就是為了跨平台 )。 　　當然，這種仿 JApplet 的做法所使用的 mini CLR engine，應該能做的事情程度不會超過 .NET Compact Framework 就是了。 　　另外關於 Visual Studio 2008，算是把 VS 2005 成熟化，基本上令人驚艷的東西都和 VS 2005 差不多，只是搭配 .NET 3.5 把原本需要另外下載的 Libraries 變成內建功能。 　　不過整合 TeamSystem 的專案管理 Feature 的開發環境真的還是非常吸引人呢！

        趁今天結束之前，趕緊補一篇湊數的文章 ^_^。         上回談到 程式鬼打牆，測不準原理 ，這一篇就讓我來用淺顯易懂的白話文來抓鬼揭秘吧。         其實程式會出現這樣結果不一致的落差，來自於 Performance 考量的思維 --          只要當你真正要看運算結果的時後才進行運算，否則你只是要我運算，我還是可以先偷懶擺爛。

　　最近這兩天都遇到鬼打牆事件，明明預估很簡單輕鬆，可以提早下班的工作，卻連兩天都遇到當場傻眼無法解釋的現象，弄到加班都差點搞不定。 　　其實軟體開發就像是堆疊黑盒子的積木，你很難確定一個函式呼叫後，底層到底是怎樣運作才生出你所渴望的回傳值？ 　　今天我遇到一個鬼打牆的狀態，那現象就像是你要學生背英文單字，要求他邊寫邊大聲地唸出來。你看他唸得字正腔圓，紙上書寫的單字也拼得正確極了，於是乎你放心的說： 這些單字你都會了，默寫就好，不用唸出聲 。但結果你回頭檢查紙上默寫的單字，卻每個全都拼錯！？ 　　大驚之下，你又要求學生邊寫邊唸，結果又是全都正確，但是等下默寫 、 又全拼錯了...。 　　如果你是老師，八成這時候已經認定這個學生性格乖戾在惡搞你，恨得心癢癢拿起教鞭痛扁這劣徒一頓。但是，我這次所遇到的這個學生，卻是一支 .NET Framework 標準 Class Library 內的標準 API。 　　上面寫的，是給不懂程式開發的朋友理解我所遇到的鬼打牆狀況。這種現象，像極了我物理界背景的朋友耳熟能詳的量子物理現象，測不準原理。 　　先聲明，這是一個單一處理程序與單一執行緒簡單到不行的程式。 　　整件事就是開發時期，為了仔細觀察資料的變化，我會不斷把資料每個步驟後的狀態都輸出到螢幕上 ( Debug.WriteLine( ... ) )，確定他的變化如我預期。等到確定資料的每個狀態都正確後，我唯一做的事情就是把輸出到螢幕上的程式全部移除，交給客戶測試。沒想到資料結果怎麼測怎麼錯，連我自己機器上也跑不出正常預期的結果，我在客戶面前簡直是傻眼變成張口結舌的阿呆，五分鐘前那句 「 我都測過，絕對沒問題。 」 無疑是當場賞兩巴掌讓我信用破產。 　　我不敢吭聲地趕緊把剛剛移掉的那些 、 用來把資料輸出到螢幕上的程式復原回來 (  就只是單純的把註解掉的 Debug.WriteLine( ... ) 回復， 絕沒有 更多多餘的動作 )，準備開始除錯找出問題，結果一切又都正常了。 　　「 可能我剛剛版本更新沒有成功吧？ 」 我心想，然後又把那些輸出螢幕的程式移掉再更新一次，靠！程式一跑資料又全錯？ 　　這件事真的是反反覆覆搞了我快一小時那麼久，客戶在旁看我這跳樑的小丑都快打嗑睡了。當然，這件事我最後找出可以理解的原因，也避開了這個問題，不過理解原因後，不免要對微軟的 .NET ...

　　友人突然提到三個字，「 格子趣 」。說她有同事辭職要在南陽街那邊開一家加盟店。 　　上網查了一下，才知道原來是走日式精緻風的一種寄賣店鋪，詳細的介紹資料 看這裡 。 　　這基本上，就是網拍的經營模式走上街頭實體化。然而網拍其實已經走到完全的紅海與價格戰了，如果沒有獨家商品，網頁輕輕一點「依價格排序」，幾乎沒有利潤空間。而能夠享有較高利潤的商家，都是因為已經長期累積交易評價、早已攻占山頭、大者恆大，讓使用者願意多花點錢買到交易的信賴感，後進者其實幾乎沒有插入的空間。 　　這時候回歸實體店鋪，優勢在哪裡？以下是我的分析： 實體店鋪比價不易，如果 單價不高 的商品，可以產生 衝動性購物 的機率較高。 實體店鋪可以讓消費者親自觸摸到商品與鑑賞，對商家來說，沒有承擔七天鑑賞期的退貨風險與成本。 呈上，若所賣商品經得起觸摸與鑑賞的考驗，而不是只有賣相卻敗絮其中，其實比起網拍更能引起 衝動性購物 。 不用等待，一手交錢一手交貨，不但 滿足衝動性購物 ，更能讓消費者信賴與安心。 實體商店與地點特色整合的商品。例如當地名產，新竹貢丸就是要在新竹買，雖然你家樓下的巷子也有一家新竹貢丸。各地的風景旅遊明信片就一定要在各個觀光地點買，就算再貴也值得。你不會覺得去樓下金石堂或是文具店買到的風景明信片有何意義。這就是充分利用「到此一遊」的地區性 衝動性購物 。 人情味是網拍永遠無法取代的東西。儘管專業的網拍業者再怎麼畢恭畢敬回覆客戶，那仍是只有文字的一封電子郵件，親切的笑容與 即時的商品解說 產生的愉悅購物經驗，這是實體店鋪的殺手級優勢。 　　面對網拍的強力競爭，以上是實體店鋪「有機會做到」的優勢 ( 因為太多店鋪可以做卻沒做、或是做得很差，例如店員老是尾隨在後，讓客戶感覺被當成小偷產生壓力而寧可去網拍上購物... )。 　　當然，我們聽到太多例子，客戶在音響店試聽高級音響，回家上網訂購，無辜浪費實體店鋪店員寶貴的時間為人作嫁，業績算在他人頭上...，這代表面對高單價商品，消費者的精打細算的理智仍會壓抑購物衝動。 　　所以，面對網拍的競爭，實體店鋪決勝的優勢戰場就在「衝動性購物」這個超級重點 ( 上面六項優勢有四項都是跟此有關，我特地用我的血淚標示出來，所以是紅色的 )。 　　格子趣是個出租小型分割的商品架空間的實體店鋪，本身沒有任何商品，完全是走寄賣方式，從每週格子空間的出租費用和成...

　　今天是四年一次的閏年 Feb 29。 　　不約而同地，許多地方的不同系統都在這一個特別的日子開始作怪，這是就算 乖乖 也沒辦法保佑的災難。 　　我手上 CXBC 的通知平台系統，在這一天發出給客戶的交易通知，所有從西元年轉換成民國年的資料全部錯誤，顯示民國 97 年 2 月 28 日，讓客戶把今天和昨天的帳務全搞混在一起，客訴電話直逼服務人員腦門。 　　朋友在國 X 會負責的人資系統，也發現請假單開不出來，畢竟很多人會在今天請個假和 228 與週末湊個連續假期，不過幸運的是，請假作業是提前進行所以及早發現這個系統的毛病。但是另一個營運主系統則當得很慘，死機好幾個小時才搞清楚原來是閏年計算錯誤的問題。 　　 【 用民國年計算閏年是不行的！要用西元年，西元年！】 　　 【這不是學校老師都會出的作業習題嗎？小小毛病鬧這麼大？】 　　( 這凸顯我這種非正統科班出身的程式員的訓練不足與悲哀 ) 　　 【你們這些廠商程式都不好好寫。】 　　透過 MSN ，我彷彿看到身為 MIS 的朋友難以置信地咆哮著...。 　　我遇到的問題呢，則是西元轉民國年，使用系統底層萬年曆運算，直接減去 1911 年所造成的，這種寫法的意思相當於，1911年前 ( 西元 97 年 ) 的今天的日期是幾月幾號。這樣的結果，找出的那一天當然不是閏年的二月 29 日。 　　聽到這樣做法的 MIS 朋友，簡直不可思議地直叫： 見鬼了！ 　　要在最短的時間內 ( 今天營業日之前 ) 緊急搶救這個問題，我採用最 dirty 的方法，直接字串取代的方式硬生生幹掉，不過這並不能完整地解決此問題，只是暫時性的規避。我發現，要完整的解決此問題還不是件容易的事呢！因為程式允許使用者傳入 DateTime Format String 來自訂日期格式，我是先知道使用者會使用 "yyy/MM/dd" 的格式然後在程式中硬生生地針對這種 Case 作 Replace，若真要完整解決，我還得自己撰寫完整的 FomatString Parser 才行，工程實在不小。 　　總之，先過今天再慢慢想完整的解法。 　　像這樣的 bug 四年出現一次，當初做再多測試也不太可能事前測出這樣的 bug，只能說要寫出個沒有 bug 的系統真是不太可能。 　　處理閏年的問題，就留個不會遺忘的慘痛經驗來記起教訓吧。

前情提要點此 　　原先我喜歡當工程師, 獨自躲在安靜的角落, 把上級交代的事做完後, 就天馬行空想新點子, 上網找資料看論文, 然後動手實作出來. 坦白說, 軟體工程師是蠻幸福的, 只需一台 PC, 有上網環境, 就可以實踐創意. 不需像硬體工程師需要一堆設備跟很多單位配合, 才能動手. 　　然而經歷過 6 年不受重視被冰凍的職場生涯後, 我的態度改變了. 　　公司規模變很大後, 一些事情都慢慢變複雜, 日後能給我自由空間發揮的直屬高級主管恐怕也不多見. 而且遇上一些案子, 高層會先考量需求的研發/維護人力, 來交給一個 team, 而非一個人來執行. 　　工程師的我永遠是邊緣人, 只有發生問題解不掉時, 才會想到我. 而論功行賞, 封官加爵時, 根本忘記我的存在, 鐵定沒我的份. 　　成立有戰鬥力的研發團隊, 是很費時費力, 還要靠運氣(產品大賣).但要摧毀它, 只需派個只會打嘴砲的主管, 不出半年, 很快就搞定. 　　與其如此, 倒不如自己出任管理階層, 參與高層主管決策, 來爭取預算, 在自己業務範圍內, 營造出良好軟體開發環境, 吸引志同道合的 RD, 將所學 10 幾年的軟體經驗承傳下去, 為公司培養具執行能力的中階幹部, 來擔任士官長的角色. 只要具工程師性格, 有創意跟執行力的中階主管, 越來越多時, 我在公司內部, 才不會到處被視為麻煩製造者. 　　若 EeePC 打算要衝出 500 百萬台的大量, 需要成立更多課級單位, 應付現階段出貨需求, 著手開發未來次代機種, 以及研發新軟體技術, 拉高技術競爭門檻, 降低生產成本. 到時候就急需一群能獨立作戰, 充分授權的士官長來貫測執行. 　　軟體產業不是比人多, 而是比頭腦好的產業. 派個沒實務經驗的軟體主管, 馬上去大陸找一堆 2, 3 百個軟體人員來成立軟體部門, 沒有 20 幾個中階幹部來有組織規劃, 落實執行, 鐵定是一場災難. 　　我原本打算只成立小型團隊, 從 2007 年 7 月時慢慢找, 才找到一些合適人員. 但因接下來 EeePC 的延生機種, 系統客制化, 以及相關軟體的開發, 讓高層一直催促我要儲備更多的軟體人才, 來應付未來的產品規劃. 　　要加人可以, 但我要高層先答應, 以後分 Bonus 時, 是要看部門績效, 而不是數人頭. 如果我夠厲害, 其他軟體部門要用 10 ...

　　這兩天，我因為要解絕某個燙手山芋、大家避之唯恐不及、鬼魅般難解的系統與網路問題，勤跑某金控的機房...到門口如下圖，有沒有察覺什麼不對嗎？ 　　轉頭看向另一邊，似乎機櫃上有某種降頭壓在上面... 　　靠！乖乖病毒已經徹底感染佔據某金控機房！( 噓~~不要說出去是哪一家... ) 　　滿坑滿谷在機房繁殖的乖乖.... 　　銀行資訊人員的心聲：『乖，小的我今年能否安心回鄉過年就靠您了。眾資訊系統請慢用，吾等絕不敢怠慢，請高抬貴手。』 　　來個乖乖供養系統大神的合照吧。 　　等等，這邊是...？ 　　靠！連空調冷氣機也要吃乖乖啊！是啊，要是大小眼惹得空調大神不爽，空調大神一罷工，可是會連帶牽連資訊系統大神跟著不爽，然後集體罷工...有道理，說得過去。 　　離開前看著這滿坑滿谷的乖乖，沒想到以往和同事間的玩笑話竟然在這邊親眼所見血淋淋地上演著，哪天我是否會遇到一個客戶的機房，所有的機櫃外都貼上『 勒令禁止當機 』道士黃符？我相信在某個角落一定有這樣的機房存在。高科技人士的迷信程度其實並沒有比較低啊...