2011年5月25日 星期三

如果什麼 framework 都不用的情況下

作者: askeing (星塵) 看板: Soft_Job
標題: Re: [請益] java的效能!?
時間: Mon May 23 12:17:06 2011

※ 引述《Lordaeron (Terry)》之銘言:
: 隨非案子指定用什麼framework, 否則我什麼鬼framework 都不用, 反正用framework
: 打的字也沒比較少.
: 要怎麼丟到頁面, 你就ResultSet 的 getString 直接印出去不就好了?
: 非得要copy 到bean 中(成本=copy 的time 和bean 的memory overhead),
: 再透過method 取出(成本=function call 的overhead), 請問是為了什麼?
: 最後structs 真的哪麼神? 哪個taglib?
: ※ 編輯: Lordaeron       來自: 114.45.242.45        (05/22 02:16)

→ Lordaeron:http://en.wikipedia.org/wiki/Software_framework       05/23 06:36
→ Lordaeron:只要對英文有點了解的人,都會解framework 就是在一個框   05/23 06:37
→ Lordaeron:裏工作,適合的也就是哪個frame的範圍內的工作            05/23 06:38

正因為我理解的 framework 就是在框架中利用定義好的 API 開發,
所以看到最上面那段才覺得有些疑惑。

在開發過程中,一般來講怕的就是不一致、重工、維護困難,
至於效能通常都是在已經有的基礎上,進行調整(v2 比 v1快多少多少…之類的)

基於自己刻出來的 framework 也是 framework 的前提下,
如果什麼 framework 都不用的情況下,
我想像到一些情況:

    一、
    一位RD X寫了這樣的東西:
        f1() 撈A > 進行B處理 > 進行C處理 > 呈現為D
    同時另一位RD Y也需要類似的功能,但是顯示方式不一樣,所以Y決定自己寫:
        f2() 撈A' > 進行B處理' > 進行C處理' > 呈現為E
    理應撈出同樣的資料,只是呈現不同。
    但因為底下的動作是各自天馬行空寫出來的,
    所以就很可能使兩者呈現並不一致。

    二、
    續上例,
    來了一位新的RD Z,他需要一個新的功能,
    有點類似RD X之前寫的功能,但後續處理不一樣,
    所以他就參考了RD X的程式碼,改寫成為:
        f3() 撈A > 進行B處理 > 撈H > 進行F處理 > 呈現為G

    很不幸的,X發現進行B處理這邊有點小問題,所以對自己的程式做了調整,
    程式變成了:
        f1() 撈A > 進行B處理'' > 進行C處理 > 呈現為D
    但是Z已經著手在其他工作上了,並不知道X改了B部份…

    三、
    最後,不幸的 XYZ 三位RD都決定離開了!
    來了一位 W ,他發現有
        f1() 撈A > 進行B處理'' > 進行C處理 > 呈現為D
        f2() 撈A' > 進行B處理' > 進行C處理' > 呈現為E
        f3() 撈A > 進行B處理 > 撈H > 進行F處理 > 呈現為G
    這時候他發現要加入第四個功能了,
    前面的步驟也是很類似,但無法理解為什麼有好多種不同作法,
    所以只好自己又寫了一個新的:
        f4() 撈A'' > 進行B處理''' > 進行C處理'' > 進行F處理' > 呈現為G'


以上這些是我簡單想到的可能情況,
或許使用一套定義好的框架,讓開發團隊在其中開發,
能降低開發時重工的程度,也可以避免許多的不一致,後續維護也比較容易。
當然也許有團隊充滿了高人,都能互相理解並且有著高超的技巧,
但一般來說,團隊中有高手也會有新手,程度也不盡相同。

當然,
我同意並非一定要使用某些 framework,或必須大量使用 framework,
避免使用不適當的 framework ,也是很重要的課題,
否則只為了一些小功能,使用了龐大的 framework,反而浪費了許多資源;
甚至使用了根本就不適用的 framework,那也只會礙手礙腳;
這時自己訂出一套適當的 framework 也許會比較恰當。


回到效能部份,
一份不易理解、不好維護、更改困難,往往乾脆重寫的程式碼,
要從散落各地的邏輯中找出效能瓶頸,個人經驗是滿困難的…

反而一份容易閱讀、容易維護、容易更改擴充的程式碼,
相對比較容易找出效能瓶頸,
此時再針對瓶頸去最佳化會比較容易。


無論工具多好用,
也該在充分瞭解之後、用在適當的地方。
拿螺絲起子去吃火鍋、拿筷子去裝電腦,都是很奇怪的事情。

--
好像跟標題討論的 Java效能 有點不一致
變成在講 framework 相關的東西了 XD

--
                   星塵|http://askeing.blogspot.com/
                   噗浪|http://plurk.com/Askeing/invite

                jPlurk  - Plurk Official API Binding in Java
                        http://jplurk.googlecode.com/

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.87.142.18
※ 編輯: askeing         來自: 219.87.142.18        (05/23 12:19)

沒有留言:

張貼留言

您好.本資料庫並非第一手資料.如果你有對文章作者的詢問,意見與需求,請自行找尋文章作者並提供意見,謝謝.