如果什麼 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)