Saturday, November 15th, 2008
在某窩上有鳥友問到 ESB 這個東西，剛好最近比較閒可以來講點訐古，大家就湊和著看看吧。故事是從一家小不拉幾的銀行開始的，我們姑且就稱它為斯摩銀行好了。斯摩銀行小本經營，分行只開了 8 個，台幣系統這種大傢伙當然還是乖乖的去交 IBM 稅吧，沒人會因為用了 IBM 而被炒魷魚的。最近景氣不好，個金的貸款逾期的很多。直接包給外面的催收公司嘛，他們的趴數要的實在有點高，而且據說對企業形象不好。所以呢，摳門的老闆想要自己弄個催收的功能，每個行員每天撥一個小時的時間去打電話，但是 IBM 催收模組好貴，那就試試看 PC-based 的催收系統好了。
催收系統是很簡單的系統，資料從台幣主機撈下來，秀在行員的螢幕上讓他們去打電話，行員記一下通話摘要，系統要自動 follow 客戶有沒有履行承諾，沒有的話要做一些必要的措施。夠簡單了吧? 不過是個簡單的資料庫加上流程處理，還有一點 UI，這很久以前就有人做，用 client-server 就可以解決了，後台跑資料庫，流程處理切開，一半在資料庫跑批次，一半在前台 VB 寫的軟體中內建流程，一塊小蛋糕沒什麼大學問的。
解法好像可行，它的成本夠低嗎? 讓我們來想一想。資料庫軟體是按 seat 來收錢的 (呃，至少我那個美好的年代是如此)，八個分行加總行至少 100 個 user，這個 license 好貴啊。VB 軟體要灌在 100 台電腦上，雖然說可以拗廠商來裝機，但是裝機的時候行員一定去打茫的，隱性人事成本很高。如果軟體有 bug，全部 100 台都得 patch 過，又是個打茫的好藉口，對摳門的斯摩銀行老闆而言，這似乎不是什麼高明的主意。另外要是資料不小心給他有點多，好像現有的網路流量不夠用要再想辦法升級，這又是一筆開銷啊。
所以聰明的廠商想出了一個好辦法: multi-tier 架構，名字聴起來夠威，應該是不錯的。我們架個中介軟體，把所有資料存取集中，所以資料庫 license 可以買便宜一點的。架個網站，把前台的程式做成網頁，所以行員只要知道網址，直接用瀏覽器就可以開始工作了，不必裝機，不讓他們有打茫的藉口。最後想辦法把工作流程通通集中放到 application server 上，再把 app server、web server 和 DB server 通通串好，搞定收工走路有風。
不過呢，時機實在太壞了，有沒有辦法再省錢一點? 斯摩銀行的本業是玩錢不是玩電腦耶，你看看，為了養這個催收系統，我們要有自己的機房，要買一堆設備和軟體，要花錢布建專線網路，要養一批專門的 IT 員工來搞定這些東西，每一様全部都要錢! [...]
技術文章, 無責任評論, 軟體工程 |
Friday, August 8th, 2008
線上遇到學弟，他現在正為要選哪種方案來做他的專案很苦惱。其實這問題說難也不難，因為答案很清楚，出來賺錢嘛，選擇獲利最高 (通常也等同於成本最低) 的開發方式就對了，真正麻煩的是怎麼去算獲利。
以我學弟的例子而言，他的狀況是客戶開預算案，他們公司承包，這種最好算:
獲利 = 工程款 - 開發成本 - 維護成本 - 固定成本
算這種東西的時候，工時是最多專案經理拿來算成本的工具，不過呢，它只代表小小的一部份成本而已。如果今天做的東西驗收不過的話，工時少只代表虧的少，所以選擇的第一要件就是要確保你可以用它做出你想要的東西。以他的情況來講，大部份的 team member 只會 Java 和 PHP，所以在程式語言上，他沒什麼選擇，若是 Java 加上 PHP 都做不出他要的東西，那最好的選擇就是閃人先。
接下來是平台，平台直接影響固定成本，所以很多老闆看見你用微軟的方案會直接否決，因為帳面上這些是要付錢的。不過呢，若這個平台可以幫助你減少開發成本和維護成本，那最好還是精算一下再決定比較好。以我學弟的情形，他的客戶的 SA 熟 Windows 和 Solaris，不過他的團隊除了他之外沒人碰過 Solaris，這種情形下很容易可以算出來用 Windows 的成本會比較低些，因為可以買比較便宜一點的 x86 伺服器，而且不必付出讓團隊去熟悉 Solaris 的工時成本。兩個最主要的東西決定下來，CM (Configuration Management) 的主軸也就定了，接下來就是用需求訪談得來的情報去擬定整個 project 的 execution plan，那就是他自己的事了哇哈哈 …
對了，為什麼不用 Linux 呢? Linux 和 Solaris 的差異不至於大到太誇張啊? 這是好問題，去問你客戶的 SA 要不要幫 Linux 掛保證，如果他不要，那就是你要掛保證了，客戶給的錢足不足以讓你去兼做維護 OS 的事，那就是你自己要衡量了。你老闆愛出嘴炮反微軟挺 Linux，那叫他自己去和對方的 [...]
技術文章, 無責任評論, 軟體工程 |
Sunday, July 27th, 2008
在約爾大神的文章裡，他老兄把微軟的那票 architect (架構設計師? 104 翻的不是我啊 …) 好好地損了一下，幫他們取了個響亮的綽號：architect astronaut (架構太空人設計師)，順便也好好地損了一下同步 (synchronization) 這個概念。好吧，這裡就有點怪怪的了，微軟並不是唯一押寶在同步上的笨蛋，如果「同步」這個概念不賺錢，為什麼有這麼多攀子要燒錢?
我個人的看法是，「同步檔案」這玩意兒當然不賺錢，它只是一個大布局的基礎棋子罷了，這個布局是為了簡化資訊共享和協力工作的難度。就像下棋吧，直砍直殺未必是好，有時得要繞個彎設個套才能贏。今天的手機了不起只有 VGA 解析度，當然搞不出什麼大風大浪來，但若等到手機都是 XGA 傳輸速度都很猛時才要進場，那就只能揀別人吃剩的了。
其實「同步」這個詞並不精確，它其實就是最近很夯的「雲端運算」的一種附加功能而已。因為資訊都存在網路上，也都在網路上分享操作，當然它會是同步的。好吧，雲端運算是不是又是那票太空人弄出來唬弄普羅大眾的呢? 我個人認為他們還不至於這麼閒。就像約爾問的: 誰會需要同步檔案? 如果這只是一個包套方案中的某一點小小的附加功能，我想也不會有人拒絕使用才對。
無責任評論, 軟體工程 |
Sunday, January 27th, 2008
搞軟體的常常遇到的問題就是，程式寫好之後，客戶嫌它跑的慢，所以不爽付錢。爽，是一件很重要的事情，所以師程工多半都會被要求無論如何要調到客戶爽為止。不過說真的，效能調校是件很有趣的事情，小弟來分享一些曾遇過的趣事好了。
關於時間方面的效能調校大致上可以分成兩種：縮短執行的時間，或是縮短等待的時間。前者多半出現在後台用的程式，例如小弟以前做過的某個銀行專案，一個批次跑下來要十九個半小時，基本上這等於叫客戶不要開門做生意 經過一個多月的調教校，批次執行時間變成十九分鐘。這麼歡樂的情形也許不常見，不過我倒是從中學到不少有趣的東西：
資料庫的 table design 非常重要，我所做過大部份的專案都是以客戶現有的資料結構下去設計，但客戶的資料結構往往不符合效能最佳化的需求。在一開始設計時就應找出最常用或最關鍵的 query path，針對這個 path 下去設計才對。
Stored procedure 的設計必須把握「先細篩後粗篩」的原則，cursor 指向的 data set 越小，跑起來越快。像上面的例子中，我只是把兩個 select 的順序換一下，時間就從十九個半小時變成六小時。
注意一下 team member 的實際能力，雖然這有些傷感情或 micro-management 的嫌疑，不過卻太常見了。一個很有效的鑑別方式是和你的隊友聊天，看看他打算用什麼方法解決問題，若是沒有方法，或是方法的執行上實在不怎麼樣，那就該想想 plan B 了。
擴充性迷思：客戶通常會要求高於他們業務量所需的規格以備未來的擴充，或是要求要有種種神奇的擴充能力。如何委婉的讓他們知道有多少錢玩多大的車是很重要的事情，很多時候系統只打算用五年卻做了十年的規劃，這樣做起來累驗收也累，爽的只有 sales。
注意客戶的真實需求：很多時候程式跑的慢並不是技術上有問題，而是管理面或協調面上出紕漏。比方說奧客亂拗碰上軟腳 sales PM，或是客戶自己都搞不清楚自己要什麼，或是客戶自己山頭林立一人一把號各吹各的調。這種情形下除了等五年後摩爾定律打敗客戶需求之外，找個很會喬夠力喬的高層才是明智之舉。
很多學校都灌輸「演算法改進會優於程式本身改進」這個概念，不過呢，請務必確認您的隊友都了解這個原則是基於「程式本身已經寫的很好」的假設。我看過不少同行花好多好多的時間想要去生出一個更好更棒的演算法，卻沒有去檢查原有程式的品質。爛程式可以很有效地搞砸好的演算法！
如果 team 很大，程式慢就幾乎是必然的，因為程式往往會遷就組織架構而做許多不必要的取捨，例如過度模組化或不必要的流程。這時候通常我們會需要一點來自上層的助力和自己的勇氣才行。
縮短等待時間一般牽扯到的問題反而都不是技術面的，除非一開始設計就很爛，或是很幸運的遇到網路基礎架構很爛的客戶，不然很少會需要什麼技術面的調整。大部份的調整都是屬於心理層面的，所謂 perceptual performance 的東西。比方說，跑一個報表產生的程式，50 頁用了 5 分鐘，客人嫌太慢等很久，放了一個 dialog 上面跑個 progress bar 外加一堆文字閃來閃去顯示報表產生的步驟和進度，50 頁共用了 7 分鐘，客人反而很滿意覺得程式很讚跑的很快 訣竅很簡單：UI 有在動不會卡住，客人的爽度一般而言比較高。
此外，像拙文記憶體用量的迷思中所寫的現象，雖然與縮短等待時間沒關係，但其實也是 perceptual performance 的另一種表現形式。這種心理層面的效能要怎麼調，得靠 usability 方面做好功課，不然就得和客人拉關係哈啦來補補課學經驗囉。
技術文章, 無責任評論, 狀況排解, 軟體工程 |
Tuesday, April 3rd, 2007
乃特大有一篇 SOA 的觀念問題，難得正經地寫一下 comment，就把我寫的 comment co 回家留底了 …
ccc … SOA 小弟認為不應該當成軟體工程的 concept 來看，而應該當成 business model 的 concept。傳統上開門要賺錢，首先要能找出獲利模式，確定獲利模式之後，就必須根據公司的獲利模式來建構 supporting infrastructure。
傳統傳統有夠傳統的 supporting infrastructure 又可稱為強百樂架構，公司要喝牛奶就得養頭牛，要喝羊奶就得養頭羊。問題是負責養這些東西的費用太可觀了，如果今天可以把這些 infrastructure componentize 之後由專業公司代包，只要成本較自己做低，功能不要太遜，那就是很好的東西。
換到 IT 的角度來講，大部份公司的 IT infrastructure 也只是 supporting infrastructure，若能從這個角度出發，把它整個 componentize 後包出去，成本應該是可以降低，而且也是很好的商業模式。這東西個人認為遠在 requirement 之前，因為它是用來 generate requirement 的。
*** 以下是沒有寫出來的謎之聲 ***
<謎之聲>
商業流程 componentize 的先決條件是要有人可以真的搞清楚這些流程的全貌和細項，對於大部份的企業來說，這是天方夜譚，不然 requirement analysis 也不成為一門可以出書的學問了 …
</謎之聲>
軟體工程 |
Thursday, September 21st, 2006
剛才在 Wired blog 上看到一篇文章，大意是這樣的：在美國維吉尼亞州發生了一件竊盜案件，嫌犯從網路上獲取商店中 ATM 提款機的操作手冊，他老兄便到某加油站的提款機去，從鍵盤輸入特別操作碼以及預設密碼，進入該 ATM 的管理模式。美國的 ATM 提款機一般都是提供 20 元美鈔供客人提領，接下來，嫌犯將該 ATM 給鈔盒設定其存鈔面額為 5 元，然後利用預付信用卡提領現鈔，機器吐的張數是以 5 元來計數，但實際吐的是 20 元的鈔票，於是嫌犯當場海噱一頓揚長而去。
這件事本來可以做的很漂亮的，但嫌犯忘了將機器設定回去。於是機器就繼續努力地發鈔，直到有一天終於有個誠實的人向加油站舉報，這整件事才被爆破出來。(謎之聲：可見那台提款機還真的是很少人用 …)
這個事件可以說是個典型的軟體工程負面教材，隨便都可以列出許多缺失：
進入管理模式除密碼之外，應該要有第二道防線，例如 POS 系統常用的鑰匙，或是刷卡機
設定存鈔面額後，應偵測給鈔盒是否有開啟過再讓變更生效
進入管理模式時應連線到控制中心進行記錄 (ATM 不可能沒有網路連線)，要不然也該閃個警示燈讓店員知道吧
機器出廠後，第一次使用時應強制更改密碼 (提款卡不就是這樣的？)
機密的使用手冊未經控管直接在網路上流傳
這些都可以由簡易的 STRIDE 分析找出對應的防制措施才對，可見當初設計時根本沒做 (或是不知道要做)。現在就等等看其他國家的提款機什麼時候會傳出災情吧
軟體工程 |
Thursday, June 23rd, 2005
根據 MacWorld 的報導，Sony 新任大老闆在股東會上透露他與英國女王伊莉莎白二世會餐時得到的消息，女王覺得 Sony 的東西太過複雜很難用，她老人家現在是 iPod 的愛用者，正享受著 Apple 當世無雙的防呆介面。
這讓我想起當初去敗的那台 iRiver MP3。拿到機器時很興奮，學了一陣子用的很開心，後來老婆大人拿去玩，一個月後我拿回來想錄音時，我已完全忘記要如何操作了。
這件事告訴我們任何人機介面最好都遵守 KISS 原則：Keep It Simple & Stupid。
無責任評論, 軟體工程 |