2012年12月15日 星期六

2012 Java 認證日與會感


        其實除了我有利用 Java 開發過 Android 程式外,對於整個 Java 繁華萬千的世界,我可以說是個局外人。

        這次『2012 Java 認證日』從主題很明顯是個推廣 Oracle 版本的 Java 證照行銷活動,本來應該與我毫無關聯,但收到 eDM 的當下,不小心被我瞄到這場免費活動的議程其實有『置入性教學』。真是怪哉,別人都是藉教學之名做『置入性行銷』,Oracle 則是反其道而行。

失敗專案的得與失

        前幾個月和同事在業外接下一個稍具規模的專案。承接這專案其實背負著相當高的風險,其一為此案所需要的各項專業技能我們是完全付之闕如,能夠在什麼都不會的情況下接觸到這案件,完全是同事的人脈引薦所致。其二為對眼前這個合作夥伴的不熟悉,以及一些不信任因素。

        當初會考慮冒此風險,原因之一是此案的極高的報酬,再來是因為上過激勵課程,內心感覺要跳脫筐做冒險:若要如何,全憑自己。所以在工作規劃分配後,對於必須惡補的技術項目覺得有賭一賭的信心。


        如果是之前的我,只敢做有把握、會做的事,當看到實力和目標有如此懸殊的差距,一定會直接拒絕。



        當然,最終沒有成功完成此專案,但其實我一點都沒有難過的感受。因為這個挑戰的本來就是『失敗是應該,成功才奇怪』的任務,然而我從這個挑戰的過程看到自己的延展性和真正的弱點。若我承接的是個十拿九穩的案子,面對的可能就是『成功是應該,失敗卻難過到想不開』,而且什麼都沒學習與成長的結局。


        所以接下案子後,我們當務之急就是如何將技術落差產生的風險降到最低,並且爭取最多的工作時間作為克服技術障礙的緩衝之用。


        這次團隊組合的專精是在 Adobe Flash / .NET ( ASP.NET ) / MS-SQL,但客戶要的是 HTML + AJAX ( No Flash ) / Java ( JSP ) / PostgreSQL 。在最初幾次與客戶的會議討論,總算把其中一項置換為同事所宣稱熟悉的 PHP。客戶的網站除了少部分的特色項目,大多是一般網站都該有的常見功能,而 PHP 是出了名的有很多免費既存套件可以快速架站,因此我研究幾套自由免費的 CMS ( 內容管理系統 ) ,挑選了 Joomla 做為整個專案的開發基底。


        由於 Joomla 只支援 MySQL 和客戶需求不同,經過幾次強力說服客戶轉換資料庫平台無效後,我肩付起最難評估風險的任務:移植 JoomlaPostgreSQL 平台上。要深入這麼龐大的系統原始碼進行改寫,而且用的是我毫無所知的語言 PHP ,這過程只能用費神費力、艱辛刻苦來形容。利用 Joomla 可以大量節省我們刻後台管理的開發時間,並且解決掉一半前端頁面的工作量,等於把這些省下的時間全部賭在移植工作上,這真是一場生死一翻兩瞪眼的豪賭,若改寫移植失敗,將面臨沒有任何進度兩手空空去見客戶的窘境。

        這中間多少次,遇到 trace 細節內的魔鬼讓我挫折沮喪幾乎要舉白旗的當下,最後決定堅持不放棄。結果,竟然能在最短的時間內深入學習多項過去不曾碰觸的技術或應用:PHP / Zend Studio / Joomla / MySQL / PostgreSQL。若不是執意冒險承接這個案子,我敢說這輩子幾乎不會也沒有任何動機去接觸這些新玩具。


        然而最後案子的敗跡,竟然不是出在這些技術關卡上,而是團隊的合作出現間隙!


        首先是上半局,其中一位經由同事介紹認識的夥伴表現非常沉默被動,幾經詢問後才表達:因技能落差太大,也沒有想接觸新東西的想法,感覺這案子太硬、風險太高而決定離場。後期擇是當初介紹這個案子、宣稱很熟 PHP 並且負責前端使用者頁面與互動的同事,完全沒有進行任何有效的開發動作。我不斷請他給我進度上的承諾、不斷地在我心中設下停損、也不斷地看到進度一再地跳票。


        雖然離結案還有一段時間,但我心中已經認定這是艘救不起來的鐵達尼。與其在最後一天才兩手一攤,給上游客戶難堪,又讓自己獨自一人的努力白費,我選擇嚴守停損,斷尾求生提前主動告知退出這個案子,讓客戶還有另尋備案的機會。




        雖然拿不到半毛錢,這段時間花的力氣看起來像是平白損失了,但其實我卻有十分充實愉快地感受。因為這個案子進行過程的每一天,都在逼我學習許多全新的東西,也開啓了我對其他類型技術的視野。這個學習的過程,本身就是相當值得的回報,也讓我對跳出自己能力框框去接下任何可能的機會有了全新的想法

        而且回顧失敗的原因,其實也正反映出我一直以來的弱項如何真正有效地管理協同合作的夥伴?


        之前我本來想寫另一篇難產中的文章,反思我過去有三個失敗的創業合作案的體悟,連同這個外包案在內,恰恰好都遇到一模一樣的 Pattern,就是:我一個人一頭熱,夥伴卻都沒採取有效行動


        常常因此搞得我心情惡劣導致破局。既然要找到步調一致的夥伴太困難,我又沒有能力去管理夥伴的執行力,而且容易因此而惱怒到不爽幹,所以到底該怎麼解決這樣重複的模式而改寫結局呢?

        在我心中,答案似乎慢慢浮現了出來⋯⋯。




關於 SQL timeout 的錯誤判別

        今天看到網路上一篇討論 SQL Timeout 原因的探討文章。         由於那篇文章的結論和我過去經驗完全不同,所以我懷疑是不是我過去仰賴的長期判斷經驗有誤,特別寫了個 TestCase 作為比較。         首先我先引用該文章作為調查起點的 Ex...