2011年8月22日

程式設計師小心別被框架給「框」住了...

Are Frameworks Making Developers Dumb? 這是一位印度軟體工程師 K. Siva Prasad Reddy 撰寫的文章,內容有關他面試「五年資歷 Java 開發人員」的觀察,結論是程式設計師應該「內外兼修」。

現在有太多的程式設計師只練「外功」,因此履歷表寫起來洋洋灑灑。一位資深 Java 軟體開發工作的求職者,不難發現他說自己會 Spring 、 Hibernate 還懂 Web Services 等等等。

一位求職者說,他最近的專案用了 Spring,瞭解如何在 XML 中設定 Beans,也知道 Dependency Injection 這個 design pattern。但這位求職者並沒有真正清楚他為何需要這麼做,他認為透過 DI 可以在需求改變時,不需要變動 Java 類別和重新編譯,只要修改 XML 設定即可。

儘管不必變動和編譯 Java 類別,但 XML 還是必須要修改,99%的情況下仍必須用 Ant 重新打包 WAR 或 EAR 檔案。對整個專案開發流程來說,用 Spring 到底能幫助些什麼?這位求職者只說 design pattern 建議這麼做。

盡信書不如無書

當然,這位求職者的下場就是:「我們的人資部門會再跟您回覆。」(意思就是:謝謝再聯絡!)

另一位求職的老兄也很高竿,他最近做的專案用上 Spring 、 Hibernate 以及 REST Web Services。既然都這樣說了,面試時當然會被問到,是不是能解釋 RESTful 架構呢?

這位厲害的求職老兄,對語法夠熟悉,不需要開發工具的幫忙,能回答「@RequestMapping(value="/url", method="POST")」這行 Annotation。可是他似乎聽不懂面試官想問的是「Concept」不是「Syntax」。

於是他又被問到:「用 Hibernate 帶來什麼好處呢?」

這位求職者已經用 Hibernate 兩年,很清楚地說明:「用了 Hibernate 我們不用寫任何東西去跟資料庫互動,Hibernate 會把這些事情搞定。」

面試官:「那 Hibernate 要怎麼知道你的專案需求呢?」

求職者:「如果我們用 Hibernate 它就會幫忙處理資料庫儲存、修改或取得資料。」

面試官:「呃...呃... OK... 你平常是否閱讀任何技術相關部落格呢?」

求職者:「當然啦!這就是我深入學習 Hibernate 的方法!」

面試官:「非常好!討論愉快!我們的人資部門會再跟您回覆!」

將場景拉回台灣的軟體開發現場,如果你問 Java 職缺的求職者懂不懂:「Spring、Hibernate 或 Web Services。」若求職者都認為自己瞭解,而且面試官「自己也真的懂」,那很好,至少貴公司不是拿長矛對抗船堅炮利。

但如果要發展成「卓越」的軟體公司或開發團隊,絕對不能只練「外功」而捨棄「內功」。

我們先假設最低為 B 級,就是 Java 軟體開發者,知道怎麼開發 JSP 和 Servlet;但是根本搞不清楚 Scriptless,也不知道自己用的 Tag 就是 JSTL,更不用說什麼 MVC 架構。這種情況下,整個專案的程式碼像是從書本範例抄下來。但只要耗費足夠的人月(man-month),還是可以讓整個專案能動。

好一點的就列為 B+ 級,可能某位高階主管或前人(先烈)決定採用 Struts 等,接下來的十年、二十年大家就照著這遊戲規則走,即使這些框架逐漸令開發者詬病,但沒人在乎或不需要管這件事。

如果一個 Java 軟體開發團隊,擁有足夠的熱誠,就會持續學習研究新技術。例如清楚知道 Spring 帶來的好處,也知道如何利用 Spring 開發架構更好的 J2EE 應用,在重構或開發新專案時,使用 Hibernate 設計 ORM 架構,已經算是 A 級,能夠善用合適的新技術及選擇更好的架構。

學習新技術並非追逐流行,也沒人希望用不成熟的東西加速專案滅亡。而是在 IT 的世界裡,一切都還太年輕,現在看似美好的架構,遲早會變成過時的包袱。因此軟體開發者必須有決心,在從事這個行業時,不斷更新自己的知識庫。

例如 RoR (Ruby-on-Rails) 對軟體開發者來說,是個很棒的禮物!它很棒的原因,並非你真的能用它取代現有的技術,雖然有許多 RoR 的開發者真的做出很棒的應用,但那不見得適合你的公司。但是它清楚示範了 MVC 架構如何幫助軟體專案開發,如果你對 J2EE 的架構熟悉,就會更清楚知道 JSP/Servlet 也可以設計良好的 View/Controller 分離。

優秀的 Java 開發團隊,可能早就使用 Groovy 簡化專案的建置及測試流程,也正研究著如何利用 Scala 開發專案,不必改變現有的 JVM 平台及專案,就能利用更棒的程式語言進行開發。還有許多 Java EE 開發框架,如 Grails 、 Play 及 Lift 等,能提供開發者幫助。

毫無疑問,在 Java 的世界中,Spring 及 Hibernate 早已成為主流技術。瞭解這些技術,並適當地運用在專案開發,對資深 Java EE 開發者來說,幾乎是必修學分。

但是從 A 到 A+ 是一條漫長又艱苦的路。

不管採用什麼技術,其實真正需要運用在專案的,可能只有少數的20%,甚至更少。所以當一位開發者用 Hibernate 開發專案 2 年,很可能只是當初用 2 星期或 2 個月時間,翻了幾頁書或上網 copy&paste 幾個範例,之後就重覆使用長達 2 年之久,只要不出現問題,幾乎不需要多研究些什麼。

每次被問到會不會某項技術,大多數只能說「有寫過」、「有用過」。因為大部分開發專案需要的技術,甚至大部分問題的解決方案,只要掌握 Google 搜尋的技巧,至少就能解決 80% 以上。對於工作來說,必須用最少的時間將問題解決,為了討生活只能如此。

知道如何善用 Google 搜尋的工作者,心裡都明白一件事,有很多工作需要的技術,其實只要關鍵字組合得好,認真找來幾篇資料,也許是網誌或教學文件,或者是官方的幾篇指南,認真吸收消化一下,不花多少時間就能滿足工作需要。甚至在高手雲集的公司,只要肯問、人緣別太差,就能得到答案。

但是在工作之外,若成為「程式設計師」如果是志業,不只是職業,就必須對自己的專業再要求更多一點,對學習的渴望必須比老闆對你工作的要求更高一些。

Spring 再好,它還是用 Java 寫成。Hibernate 再棒,它還是用 JDBC 存取資料庫。MVC 框架再優雅,底層還是運用 JSP/Servlet 等這些 Java EE 標準的機制。

如果一位「資深」的 Java 程式設計師,在過去 3-5 年間在專案中應用這些技術,可是不深入瞭解這些框架解決了甚麼問題、用什麼方法實作、底層如何運作以及如何擴充或調校,就很難有真正屬於自己的 Know-how。

一知半解比無知更可怕。

從事軟體開發的工作,不管做幾年或晉升什麼位階,必須捨棄「老鳥」心態,永遠把自己當作是「菜鳥」。老鳥總是認為自己接觸 XXX 技術已經 N 年,反正遇到 X 問題就是用 Y 方法解決就對了!而菜鳥總是想知道 X 問題有沒有更好的 Y' 解法,遇到 X' 問題時又該怎麼辦,而其他鳥(不管老鳥或菜鳥),也會樂於告訴你更多。

補充:關於 Hibernate 該如何回答才不會被打槍?!

老實說,我也覺得那位求職者的回答是「正解」,講的並「沒錯」。但是原文作者對面試結果不甚滿意,我的猜測是:

(1) 面試時不能啞(dumb)

面試官拋出一道問題,並非就是要針對該問題回答「標準答案」。雖然原文是發生在印度的故事,但是拿到台灣應該也是差不多狀況,病態的教育制度下,可能相當多人都習慣:用標準答案回答問題。 (看看那些研究所及公職考試的教科書就知道嚴重到什麼程度)

如果今天面試的程序,是給每位面試者一張試卷:

簡答第一題:請說明 Hibernate 的主要用途?
簡答第二題:請列出 Hibernate 具有哪三項優點?
申論第一題:請說明先前專案使用 Hibernate 時遇到哪些困難?
                        ‧‧‧

並且依據回答與標準答案的差異,給予 0-100 的評分標準,相信很多人都能拿高分。 (不久後就會出現一本面試教戰大全)

但實際上企業不可能這樣找人才,因為「軟實力」也是很重要的考量因素。

也許求職者真的徹底瞭解關於 Hibernate 的一切,但面試官怎麼會知道呢?

面試官提出一個問題,表示對求職者履歷寫的某項 skill 感興趣,只是點出一個「方向」,讓求職者可以往這個方向多 promote 自己。因為在求職面試時,自己就是一個產品,能把自己成功行銷是很重要的關鍵。講出來的答案固然重要,但是「熱誠」、「思考邏輯」及「談吐舉止」都會影響面試官對這個人的看法。

用 Hibernate 帶來的一些優點,是很顯而易見的答案,在書本前幾章一定都有介紹,通常訓練 3-5 的月的新人也能瞭解與感受。

BUT...

對於一個已經從事 Java 開發 3-5 年的人來說,應該要有很多「好玩、有趣、酷炫」的故事可以講吧?

假設今天要賣的產品不是自己,而是一支神奇拖把。

在人來人往的夜市,路過的人不下千個,每位都可能變成你的顧客。他們對招牌上寫的「快速清潔溜溜、脫地毫不費力」感興趣,願意浪費一分鐘的逛街時間,聽看看你能講些什麼。

你賣的是拖把,你有五年的拖把行銷專業訓練,對拖把的構造、用途、使用方法及行銷話術滾瓜爛熟,公司也編寫五大本拖把神奇功效指南;但同時你也有五年做家事、每天花五小時拖地的實戰經驗。

你有兩種選擇:(1)像工程師一樣正確地告訴顧客這拖把有哪五大功能;(2)像大賣場歐巴桑一樣讓顧客感受到這支拖把可以從此改變你的人生。

回到 Hibernate 的主題。

也許可以和面試官分享,實戰 Hibernate 時遇到最大的難題及用什麼方法解決,或者知道什麼做法可以讓 Hibernate 架構的系統效率更高,如果新公司尚未導入 Hibernate,也可以談如何用 Hibernate 改善公司既有的系統。

把自己當產品行銷,是讓新公司相信你帶來的是過去 3-5 年的寶貴經驗,而不是書本上 3-5 頁就交代完的內容。

當然也可能是遇到一位沉默寡言的宅宅工程師當面試官,但如果這是一份自己想要的工作,就必須認知「機會」是別人願意施捨、自己努力爭取才能得到,不能總是等對方發球才回應,因為 3-5 句話就結束的一次面談,不可能讓面試官真正認識你以及感受到你對工作及專業的熱情。

台灣有相當多優秀的技術人才,可是需要 promote 自己時,千萬別像文中這位印度的求職者一樣「啞」了。

(2) 技術學習是無止盡的漫漫長路

先撇開那些根本不想認真學習技術,只想著要早日從一線開發人員變主管的「熱血缺乏偽程式設計師」不談。因為有些人在不太情願地幹了 3-5 年 Java 開發工作後,就想要著要變成 SA / PM 以求升遷加薪,這些人不會帶著 3-5 年 Programming 經驗再去找一個資深的 Programming 工作,除非他們升級失敗了。

對一位熱情洋溢的 Passionate Programmer 來說,也許前 3-5 月剛進公司接觸 Hibernate 開發,就只熟悉 Hibernate 的語法與 ORM 的方法,熟悉工作所需要的技能是必要也是應該。但是對於 3-5 年的資深 Java 開發者來說,如果還是跟 3-5 個月差異不大,那就需要拖出去鞭打五十大板了。

一位熟悉 Hibernate / HQL / ORM 的工程師,卻不熟 JDBC / SQL / RDBMS 是非常危險的事!簡直比從火星跑到地球更危險!

為什麼要 ORM ?是因為我們用 OOA / OOD / OOP 方式開發軟體,如果不是如此,又為何要 ORM?有許多公司開發軟體的方式,可能連OO的概念都很缺乏,如果只是為了 Hibernate 存取資料庫語法好寫就用它,似乎弄亂了次序。

資料庫儲存的原理,多年來並沒有太大改變,即使 NOSQL 興起也沒有讓 RDBMS 立刻下台。瞭解 ORM 的方法很重要,可是只要 Hibernate 最後處理資料時,仍然是對 RDBMS 操作,就不能只學 Hibernate。

舉例來說,在不同的資料庫系統,原生的分頁(Pagging Results)做法也不相同,以 Oracle 來說,分頁使用的語法甚至大幅影響查詢時間。但是 Hibernate 提供 setFirstResult() 、 setMaxResults() 方法,讓查詢結果可以簡單的做分頁。

此時就面臨原文作者問到的問題:「Hibernate 怎麼知道你的專案需求呢?」

當一個資料表在開發、上線測試的一個月內,也許只有不超過1萬筆資料,但未來半年內可能快速增加到1億筆。如果不清楚或不知道如何控制 Hibernate 產生的資料庫 Schema 結構,不清楚實際在資料庫中的索引及關聯如何建立,也不明白 Hibernate 在查詢資料時,進行分頁、排序等最後所產生的 SQL 語法,就像是在系統中埋入定時炸彈。

也許有人會說,用簡潔好開發的語法,讓系統早日上線,之後再針對效能瓶頸逐步改善就好。其實這就是 3-5 年的資深開發者應該有的經歷,除非系統從來沒上線也沒人用,否則再持續改善、重構的過程中,勢必會更深入瞭解底層的運作機制、原理,也會更廣泛瞭解有關的技術及其他解決方案,在深度、廣度都有著墨。

不僅要追求深度、廣度,對 3-5 年的資深開發者來說,若想在軟體開發的漫漫長路走得更遠,另一個需要培養的是「高度」。

即使已經深入鑽研、廣泛學習很多技術,但是仍有可能「見樹不見林」。在一片樹海裡,活蹦亂跳的松鼠很有活力,擁有高超的爬樹技能,每天爬上爬下,見識過千百棵樹,但牠可能窮其一生也不知道這整片樹林長什麼樣子。一隻老鷹乘著上升氣流翱翔,對抗地心引力來到千尺高空,牠只需要飛個幾次,就知道河水如何流經這片樹林、那些地方已經遭到人類濫墾。

以原文提到的面試情形,求職者如果站在 Architect 的「高度」談論問題,講到細節時又能展現多年鑽研成就的「深度」,同時又懂其他技術、不同解決方案甚至跨領域的知識,展現出「廣度」,也許就不會成為面試官PO文抱怨的題材了。

順便推薦一本新書《學徒模式:優秀軟體開發者的養成之路》。如果你也把軟體開發當作志業;而不是短暫的職業。你不在乎是否能加薪升遷;只在乎是否可以一輩子從事自己熱愛的程式設計。也許可以從書中找到一些職涯規劃、維持熱情的方法。

12 則留言:

  1. 蠻有同感 很多人只會用 不懂底層 出問題其實都還是歸到最基本的java /___\ 前陣子有個在專案公司數年的JAVA"資深工程師" 卻過不了我們的試用期 原因就是被養壞了的工作習慣/態度 QQ

    回覆刪除
  2. 看到原文標題,其實我心裡想的是,至少 Java 程式設計師還願意學習各種 Framework,已經算很用功的工程師,所以諸如 Ant 等技術,即使不解釋,大家也都用過也能看懂;不像 NAnt : )

    回覆刪除
  3. 我也很好奇應該要回答什麼比較好,
    已試著將我的想法補充在這篇網誌,
    歡迎大家分享更多不同觀點,
    也許最後可以整理成一封信詢問原作者 : )

    回覆刪除
  4. hibernate 效能有夠差
    不如用connection pool就好
    說它能快速切到 資料庫 也是假的
    不同資料庫 難道sql語法 真的不用修改

    回覆刪除
  5. 我遇過 幾個大型專案 我追根究底
    效能問題 究竟出在那裡
    一猜就中 就是hibernate

    回覆刪除
  6. 多了 ORM 效能肯定不會比 native sql 好,使用了 hibernate,切換資料庫肯定還是需要依照不同資料庫進行最佳化(DDL等);hibernate 不過是 ORM 的一種選項,它並不是用來取代 native sql/jdbc/db pool 的方案。

    回覆刪除
  7. 我也覺得 hibernate 效能不好,所以只要需要效能的專案,我都強烈建議不用 hibernate,甚至也不考慮 Java EE,畢竟記憶體的耗用量就很驚人;不清楚您遇到的"大型專案"當初是怎麼決定要用 hibernate 以及如何用它?但個人覺得如果一個大型系統的瓶頸,只是因為 hibernate 造成,那其實 architect 設計者應該為此負責,因為大型系統的 db 及 app server 應該要可以 scale out,怎麼會因為一個 framework/middleware 就造成效能問題@@

    想請問您猜中問題是 hibernate 之後,如何著手解決呢?

    回覆刪除
  8. 每當學習完一個新技術..數年後又會有新技術取代....即使深入硏究後...並不一定有所作為的....而且人生的時間有限.....要什麼spring,strut,hibernate,jsf什麼什麼的也要出神入化.....何不想想老闆給的工資是不是也是如此.....要專案多好..就看出什麼價錢......這個作者該是老闆來的......要馬兒好..又不給馬兒多點草

    回覆刪除
  9. 請說明先前專案使用 Hibernate 時遇到哪些困難?
    個人經驗是hibernate產生sql不如預期, 以致效能不佳. 這部份只能找Google大神幫忙, 調整所產生的sql. 有些join的查詢得改用native sql撰寫. 至於大量資料處理的部份, 就不要用hibernate處理, 可改用jdbc或寫成stored Procedure來處理. 同時若非必要, 別在線上作業處理大量資料, 最好定時用批次作業執行.
    不知這樣答覆如何?

    回覆刪除
  10. 台灣工程師、教授平均薪水40,000 NT$
    歐美日工程師、教授平均薪水100,000 NT$
    歐美日的工程師工時還比台灣少很多
    給我兩倍薪水,一半工時
    別說是了解架構了
    我寫個RoR2都沒問題

    回覆刪除
  11. 只會開發 不會省錢賺錢,也是沒三小路用的!

    回覆刪除

lyhcode by lyhcode
歡迎轉載,請務必註明出處!