Re: [站內] 找工作真難
※ 引述《Lordaeron (Terry)》之銘言：
: ※ 引述《E04urmom (KO)》之銘言：
: : 各位高手~~晚上好
: : 先跳出來承認, 之前問 Hibernate 吃記憶體的始作俑者是我 -.-/
: : 先跟各位說抱歉, 那篇文章我清成空白文 (被銀行的鄉民發現, 給我告狀害我被高層約談)
: : 不知道有沒有違反版規, 有的話請水桶我, 我很抱歉 m_._m
: : 說實話,我已經n年沒有自己寫程式 (n>10), 關於各位提出的問題,我有不同的看法與解釋
: 我比較好奇的是, 最後有解嗎?
: framework 已經很明顯顯的跟user 講了, 在我的frame 中work.
: but 台灣人還是愛盲從, 而不是理性對待. 總希望有一個救世主
: 可以打遍天下無敵手, 讓自己無往而不利.
: 而讓自己忘記基礎的重要.
你所謂的framework難道只是針對hibernate?
通常每種framework都是針對特定條件或特定問題而設計的吧
如果你覺得hibernate很爛,那就不要用阿
自己搞一套ORMapping(or DBUtil, DBHelper)也行阿
只要你搞出來的東西,經得起實戰的考驗
你在公司的地位夠有份量
可以說服大家follow你設計的腳步
你愛怎麼搞就怎麼搞
沒有人說會使用framework就可以說話大聲,忽略基本功吧?
真正能夠巧妙運用各種framework的強者,基本功夫會差嗎?
光是framework的整合,效能調教就是一門學問吧
使用framework跟駕馭framework本來就是兩回事
什麼framework都不用,什麼thirdparty library都不import
就是你所謂的基本功嗎?
套句老師說的話
選對framework可以讓你上天堂
選錯則....
hibernate說實在的,我只會用一些基本的功能
撇開效能的問題不談,
當資料庫schema變動頻率跟幅度很大的時候
透過hibernate + middlegen,可以很快的重建所有POJO
快速修正所有被影響的程式,加上適當的UnitTest
這樣應該可以比較保證程式的品質吧
不然照小弟之前寫native SQL的方式
資料庫只要一改欄位,一定會提心吊膽好一陣子
深怕有什麼地方沒寫好,沒改到,一旦跑到就跳出那種很難看的Exception..
從這個角度來看,我覺得hibernate還蠻好用的
只要你能搞一套類似的東西,可以保證schema變動的時候
程式依然可以維持一定的品質
不用hibernate當然是無所謂的
我也看過有人搞過類似的東西
不過說實在的,maintain這種高手寫出來的東西,實在一點也不輕鬆
hibernate好歹網路上有一堆的文件可以查
高手寫的東西搞不好還會暗慷一些自己的小玩意兒
變成你必須先了解前人的想法,才有辦法維護他的程式
這樣對公司來說是好是壞,見仁見智吧
熱門的framework,某種程度來說算是業界的隱藏標準吧
摸過學過碰過一些問題,好歹可以比較一下優缺點
不用這些framework or thirdparty的元件,靠自己就會學到真功夫?
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 125.224.193.25
討論串 (同標題文章)