Perspectives from cubicle

跟親朋戚友談及自己的工作，當我告訴他們我在某家銀行工作的時候，他們接著的問題不是問我在哪個部門上班，反而是問我在哪家分行工作。每次我也得費一番唇舌跟他們解釋銀行除了接觸一般市民的「門市」以外，還有一大批後勤人員在背後工作，支援前線人員，或是負責製訂市場策略和宣傳方針等等，人數說不定比前線的還要多。

兩年前我在另一家銀行實習的時候，有位太太便聲稱在辦公室附近的分行看見我站在門口，頭戴聖誔帽，站在櫃位外服務顧客。雖然早就告訴過她了，但她仍堅持自己沒看錯，令我哭笑不得。不知道在其他公司任職 in house 的 IT 同業有沒有類似的經驗？

近來另一種關於我工作的誤解，來自一位同年朋友的口中。她從男朋友那邊聽說，以為銀行的電腦程式都是老舊到不用維護的地步，所謂銀行業 IT 只需要照顧老舊的機器，不時維護一下那樣，無聊得發慌。志願還說要當記者啊，有這種可怕的誤解說不定會鬧出大笑話。我來告訴大家吧，不是，絕對不是。各行各業為傲視同儕，不斷推陳出新，在產品、服務到工序上不斷尋求突破。在銀行上的例子俯拾即是，好像支援新型的投資產品，由記錄帳戶，計算風險，到統計淨值和算出盈虧也由電腦一手包辦，十年前我想根本就不可能有這種程度的自動化。另一個例子，便是自助銀行，好像某銀行近日推出透過電視處理銀行業務，五年前又會有這種東西嗎？

在這些突破的背後，要確保除去人手處理導致犯錯和延誤的可能性，最後還得靠電腦系統。所以，銀行 IT 可能真的很「悶」，但一定不是陳舊的「夕陽工業」。

難怪現在大公司都喜歡外判公司內部的系統支援服務了，因為支援自己開發的 WordPress 插件還真是意外的累人。首先你要回應問題，不管在網誌留言還是直接送信，最好要快別讓人家等著，不然有些性子急的人的通知會排山倒海的壓過來，而且良心不停譴責自己真有夠難受。

好了，支援問題千奇百怪，有些是要求加進新功能，有些則是 bugfix – 但問題是大家 WordPress 用的主題，版本也不盡相同，要支援各種不同搭配難度真高。再加上瀏覽器的問題，天呀，這明明是 TinyMCE 的問題呢，竟然要我想辦法解決。不同瀏覽器，要分別支援 IE 跟 Firefox 就有夠頭痛了(證明 Opera/Safari 市場還小，或者他們對 TinyMCE 的支援很棒)，而且還有對不同版本的支援，由 IE5 到 FF 1.0 的支援請求也有。

加上自己有一份正職，這些東西已經成為了一種… 夢魘了。不不，千萬別誤會我討厭大家傳來支援請求，更不要以為我會將服務外判，只是我會慢一點而且可能不會再搞新插件而已(畢竟 WP 功能越來越完美，插件量也越來越多)，況且爛攤子是自己搞出來的，收拾的當然也是自己啊！:-)

昨夜學系請了某電訊公司的高層講香港 IT 勞動市場的模式以及她對 IT 市場，IT 人才價值的看法。雖然時間稍為長一點，不過內容真的很充實，我全程可是沒有睡著呢。

講者提到，香港的 IT 市場挺奇怪的，寫程式碼的編程員是整個階層最低的工作者，人工低而且無實權，要靠不斷工作而晉升到 AP/PM 直至管理層。她說，外國明明有些有天份的人會一直當死編程員，而且有豐薪厚祿呢，相反香港這邊待遇如此這般，要靠跳升到毫不相關的職業去發展。

說的也是，一個 PM 的工作和一個 AP 的工作應該沒有關係，每個職位應由相關的專才來擔當，但為甚麼我們會有這種 career path 呢？可能是東亞地區(特別是中國)存在著「權力大於一切」的思維吧？你在勞動市場的價值，取決於你管理著多少個人，而不是個人專長或才華。

也難怪香港沒有外國所謂的「明星編程員」，表現好的編程員全部統統去當管理層，再也不會回到底部重操舊業啦。

因為近來用 Spring 的緣故，順道也接觸了一點關於 AOP (觀點導向編程) 的知識。

傳統 OOP，就拿 MVC 這套 pattern 來說吧–例如我們要建立一個留言板的話，Controller 的結構大概是這樣的：

class MsgBoard implements Controller {
private void post(name, title, content) {
Validator.isSpam(getIP());
Validator.sanityCheck(name);
Validator.sanityCheck(title);
Validator.sanityCheck(content);
Post p = new Post(name, title, content);
post_id = DB.store(p);
Logger.log(getIP(), post_id);
displayView('result');
}
private void reply(post_id, name, title, content) {
Validator.isSpam(getIP());
if (!DB.exists(post_id)) displayError();
Validator.sanityCheck(name);
Validator.sanityCheck(title);
Validator.sanityCheck(content);
Post p = new Post(post_id, name, title, content);
reply_id = DB.store(p);
Logger.log(getIP(), reply_id);
displayView('result');
}
void handleRequest() {
if (IS_POST) post();
if (IS_REPLY) reply();
}
...
}

以上的結構，有兩個問題：

1. 程式碼混亂
   一件簡單的動作，因為不同方面的要求(例如怕留言者破壞皮面而檢查留言有沒有不合規的 HTML tag，檢查來源是不是垃圾郵件黑名單，IP 記錄等等)而使程式碼穿插多個不相關的模組/類別，修改上來得穿插多個不同模組逐個修改，費時得很。
2. 程式結構鬆散
   同時是 post，reply，性質上不太相近但卻要進行多項同類的檢查和記錄，但又不是完全相同可以簡單到用一個程序包著(例如 post() 不用檢查原post的存在)，修改某部份之時很可能會忽略其餘地方而造成錯誤，難以維護。

於是研究人員向「分離不同關注點」這個方向下手，AOP 是。AOP 的規劃可以分為三個部份，包括「觀點分離」(Aspectual Decomposition)，「關連實作」(Concern Implementation) 和「觀點重組」(Aspectual Recomposition)。

譬如上述例子，真正的工作是把新文章儲存到資料庫裏去，其他檢查，記錄等等分散在不同程序，位於外部的附加工作，在 AOP 的世界裏被稱之為橫切關注點 (cross-cutting concern)。為了有效可以管理這堆散漫在程式結構裏的步驟，便有了觀點 (Aspect) 這個容器。每一個 Aspect 可以對某個工作的不同階段(AOP 稱之為 Pointcut)附上不同的關注點工作。例如：

public aspect storePost {
pointcut sanityCheck(name, title, content) : call (Post.new(name, title, content)) && args(name, title, content) {
if (Validator.sanityCheck(name) && Validator.sanityCheck(title) && Validator.sanityCheck(content)) proceed(p);
}
pointcut log(*) : call (* DB.store(Post p)) && args(*) {
Logger.log(getIP(), *);
}
}

每一個觀點限定了在程式執行到某一個pointcut 的時候(例如某個封包裏某個方法被執行，又或是某個類別的實體被當作傳回值)，定義的 pointcut (可以當作執行條件) 內容便會被執行。諸如上面，每當 Post (文章)物件的建構子被呼叫的時候，便會先執行 Validator.sanityCheck()檢查每項參數，通過才可以繼續。資料庫儲存部份亦一樣(我不太跟語法了)，每當儲存指令被執行的時候(無論是甚麼地方也好)，Logger 便會將一切記錄在案。

AOP 可以簡化程式的邏輯，達到不用修改源程式碼而添加功能。不但如此，AOP 也可透過設立不同的 point cut 來限制條件(Design by Contract)，而限制程式碼不會跟真正工作的程式碼糾纏在一起。

我們且看看 AOP 會否流行起來吧。

延伸閱讀：
Javaworld: I want my AOP!
AspectJ – Java AOP Implementation
Wikipedia – Aspect-Oriented Programming – Implementations on various languages

本來八月是這樣分配的…

本來… 本來是這樣分配的… 4/9 要向老闆呈上 Progress Report，這些東西便要在 4/9 出現吧？哈哈… 難不倒我的。

From Slashdot:

Open source means you can read the source, much like an “open book exam” means you can read the book. The correct term for software that belongs to the community is Free Software. With Free Software, you are guarenteed to have the four fundamental software freedoms. With “Open Source”, there is no such guarentee.

By my definition, even Windows is Open Source. In principle, I can view the source code to Windows. It’s difficult and I have to sign a whole bunch of documents but I could do it with sufficient patience. This is why I don’t like Open Source as a term; it is far too misleading. In fact, it doesn’t actually mean anything other than the fact there is a mechanism by which you can see the source code that doesn’t involve getting a court-order.

In contrast, the term Free Software has a very precise meaning and really should be trade-marked by the FSF. Then the FSF could only issue licenses to se the trade-mark where the software is licensed that protects the four freedoms. This way, companies couldn’t profit from the name unless they labelled their products correctly.

經常開源跟自由軟件搞亂，要知道能看源碼不代表擁有修改，發放等種種不同的權利啊！

最困難的地方，莫過於你不知道手上要開發系統的作用！

「沒可能吧？哪有理由不知道自己在寫甚麼呢？每套系統也有清楚和明確的文件吧！」當然這些都是清楚的系統，只不過對新來沒經驗的隊員來說，吞這堆東西實在很痛苦。

比如說，我在這幾個星期，上過幾個 requirement meeting，看過點點 document，才得了個大概(而我待在這裏已超過半年了)。而且晚上還要到我以前絕不會有興趣到訪的網站，找些在文件裏摸不著頭腦名詞的意思。解釋是找到了，不過卻帶來更多更深的生字。

難怪，人有求知慾才會懂向上爬的，有道理。