http://www.javaeye.com/topic/8007?page=1
andyyehoo:
比較一下下面的兩段代碼，說真的，雖然說Java效率低一點(diǎn)可以原諒，不過比較一下這兩段代碼的效率，真是..............雖然java效率比C低n個等級大家都接受了，可是不意味著就可以把系統(tǒng)效率丟到爪哇國去了啊
第一個是直接new一個對象，接著調(diào)用一個方法。
第二個是首先getApplicationContext，這個過程就首先不知道耗費(fèi)多少了。然后是間接的getBean，創(chuàng)建一個對象。接著通過調(diào)用3個比reflaction更低效率的方法，設(shè)置各個參數(shù)，最后是調(diào)用。
純粹的比較方法數(shù)，已經(jīng)是第一個的3倍了，更不提每個方法的效率比第一個還慢多少。
當(dāng)然，第二段的靈活性可能是高很多，但是這樣的靈活性真的需要嘛？在大部分系統(tǒng)的大部分區(qū)域，我們需要大量的在EJB,JMS 或者 WEB SERVICE 里面切換嘛？
我們公司的答案不是，所以這個也是我們到現(xiàn)在還不普遍使用spring，而是部分使用spring的原因，也是spring的好處。系統(tǒng)小部分的靈活性需要非常高的部分，我們才利用spring的beanfactory功能，事務(wù)控制要求嚴(yán)格部分，才使用它的事務(wù)管理功能。但是絕大部分，我們不使用。可以說是剛?cè)岵?jì)吧，不靈活的部分是剛，靈活部分是柔，系統(tǒng)如果全部是柔的話，那就軟綿綿無力了，如果全部是剛的話，那么就太脆而易斷，作為一個真正實用的系統(tǒng)，剛?cè)徇€是按80/20原則的好。
引用
UserManager userManager = new UserManager();
String userIDRetured = userManager.addUser("John Smith")
引用
ServiceRequest bsr = this.getApplicationContext().getBean("businessServiceRequest");
bsr.setServiceName("User Services");
bsr.setOperation("addUser");
bsr.addRequestInput("param1", "addUser");
String userIDRetured = (String) bsr.service();
gigix:
andyyehoo 寫道:
比較一下下面的兩段代碼，說真的，雖然說Java效率低一點(diǎn)可以原諒，不過比較一下這兩段代碼的效率，真是..............雖然java效率比C低n個等級大家都接受了，可是不意味著就可以把系統(tǒng)效率丟到爪哇國去了啊
第一個是直接new一個對象，接著調(diào)用一個方法。
第二個是首先getApplicationContext，這個過程就首先不知道耗費(fèi)多少了。然后是間接的getBean，創(chuàng)建一個對象。接著通過調(diào)用3個比reflaction更低效率的方法，設(shè)置各個參數(shù)，最后是調(diào)用。
純粹的比較方法數(shù)，已經(jīng)是第一個的3倍了，更不提每個方法的效率比第一個還慢多少。
當(dāng)然，第二段的靈活性可能是高很多，但是這樣的靈活性真的需要嘛？在大部分系統(tǒng)的大部分區(qū)域，我們需要大量的在EJB,JMS 或者 WEB SERVICE 里面切換嘛？
你講這么大一通，我說你純粹扯淡。只要addUser方法里面訪問一次數(shù)據(jù)庫，你所有那些性能考量全都是白費(fèi)。哪怕你節(jié)約一萬次對象創(chuàng)建和方法調(diào)用，連接數(shù)據(jù)庫的網(wǎng)絡(luò)開銷就足以讓你的整個努力化為烏有。你也知道80/20原則，按照80/20原則，J2EE應(yīng)用根本就不應(yīng)該考慮性能問題，除非涉及到RPC和I/O操作。你在內(nèi)存里優(yōu)化得再好，如果由于架構(gòu)上的原因多一次RPC調(diào)用，整個系統(tǒng)的性能立馬就掉下來了。與其追求這種毫無價值的、微秒級的性能提升，我寧可追求全面的靈活性。
andyyehoo:
gigix 寫道:
你講這么大一通，我說你純粹扯淡。只要addUser方法里面訪問一次數(shù)據(jù)庫，你所有那些性能考量全都是白費(fèi)。哪怕你節(jié)約一萬次對象創(chuàng)建和方法調(diào)用，連接數(shù)據(jù)庫的網(wǎng)絡(luò)開銷就足以讓你的整個努力化為烏有。你也知道80/20原則，按照80/20原則，J2EE應(yīng)用根本就不應(yīng)該考慮性能問題，除非涉及到RPC和I/O操作。你在內(nèi)存里優(yōu)化得再好，如果由于架構(gòu)上的原因多一次RPC調(diào)用，整個系統(tǒng)的性能立馬就掉下來了。與其追求這種毫無價值的、微秒級的性能提升，我寧可追求全面的靈活性。
addUser調(diào)用數(shù)據(jù)庫的時間，大家都是一樣的，為什么我不能考慮這里調(diào)優(yōu)？
這樣寫，并不會多出一次數(shù)據(jù)庫或者RPC的調(diào)用。除非是很復(fù)雜的部分，那么我會考慮局部使用。對于系統(tǒng)80％的代碼，簡單化處理是不會帶來任何問題的。
J2EE應(yīng)用根本就不應(yīng)該考慮性能問題？那我所有字符串連接都用+好不好？我做一步catch一次exception好不好？我所有Java方法的調(diào)用都通過reflection進(jìn)行好不好？“根本”這個詞用得太過了。
"我寧可追求全面的靈活性",這個正是問題所在，過分的追求靈活性，將降低效率，我們必須在靈活性和效率中間取得平衡點(diǎn)。xxx說了“添加多一個中間層，可以解決大部分的問題”。中間層越多，當(dāng)然靈活性約好，但是效率是低了。其實當(dāng)然，效率這個東西是兩頭大，中間小的一個東西，最耗費(fèi)時間的，往往是一開始的調(diào)用（用戶點(diǎn)擊傳到處理層）和最后的調(diào)用（調(diào)用數(shù)據(jù)庫，WEB service），但是這并不意味著，我們就可以無節(jié)制的，忽略中間的效率。
gigix:
andyyehoo 寫道
addUser調(diào)用數(shù)據(jù)庫的時間，大家都是一樣的，為什么我不能考慮這里調(diào)優(yōu)？
這樣寫，并不會多出一次數(shù)據(jù)庫或者RPC的調(diào)用。除非是很復(fù)雜的部分，那么我會考慮局部使用。對于系統(tǒng)80％的代碼，簡單化處理是不會帶來任何問題的。
你是真不明白呢還是故意抬杠？一次數(shù)據(jù)庫操作或者RPC的速度是十毫秒級的，通常一個J2EE業(yè)務(wù)操作包括幾次網(wǎng)絡(luò)傳輸和幾次數(shù)據(jù)庫操作，也就是說在最理想的情況下一個業(yè)務(wù)操作的速度是百毫秒級甚至秒級的。我請問你，你要節(jié)省多少次對象創(chuàng)建、多少次方法調(diào)用才能把響應(yīng)時間提升100毫秒？有個成語可以貼切地形容這種優(yōu)化：杯水車薪。
andyyehoo 寫道
J2EE應(yīng)用根本就不應(yīng)該考慮性能問題？那我所有字符串連接都用+好不好？我做一步catch一次exception好不好？我所有Java方法的調(diào)用都通過reflection進(jìn)行好不好？“根本”這個詞用得太過了。
你還真說對了。我所有字符串連接都是用+；我的業(yè)務(wù)對象外面有動態(tài)代理提供的AOP，也就是說所有方法調(diào)用都是通過reflection進(jìn)行的；我的動態(tài)代理里面對異常全部做了包裝，也就是說每個方法調(diào)用都有try...catch...的包裹。我得到的效果是什么？更清晰的代碼，更優(yōu)雅的架構(gòu)，以及，更容易找到系統(tǒng)的性能瓶頸，更容易優(yōu)化性能。有些事情也許你沒有聽說過，但不代表它不是真的。
andyyehoo 寫道
"我寧可追求全面的靈活性",這個正是問題所在，過分的追求靈活性，將降低效率，我們必須在靈活性和效率中間取得平衡點(diǎn)。xxx說了“添加多一個中間層，可以解決大部分的問題”。中間層越多，當(dāng)然靈活性約好，但是效率是低了。其實當(dāng)然，效率這個東西是兩頭大，中間小的一個東西，最耗費(fèi)時間的，往往是一開始的調(diào)用（用戶點(diǎn)擊傳到處理層）和最后的調(diào)用（調(diào)用數(shù)據(jù)庫，WEB service），但是這并不意味著，我們就可以無節(jié)制的，忽略中間的效率。
同樣一個問題，我換另一個角度來問你：你要做多少次字符串連接，才能浪費(fèi)100毫秒時間？你可以自己寫個程序，對比一下StringBuffer.append和String.+的性能差距，看看需要多大的字符串才能讓你損失100毫秒。如果你能告訴我這個結(jié)果，我一定很有興趣知道。別忘了，100毫秒僅僅是一次普通J2EE業(yè)務(wù)操作整體響應(yīng)時間的數(shù)十分之一而已。
andyyehoo:
引用：
你還真說對了。我所有字符串連接都是用+；我的業(yè)務(wù)對象外面有動態(tài)代理提供的AOP，也就是說所有方法調(diào)用都是通過reflection進(jìn)行的；我的動態(tài)代理里面對異常全部做了包裝，也就是說每個方法調(diào)用都有try...catch...的包裹。我得到的效果是什么？更清晰的代碼，更優(yōu)雅的架構(gòu)，以及，更容易找到系統(tǒng)的性能瓶頸，更容易優(yōu)化性能。有些事情也許你沒有聽說過，但不代表它不是真的。
lol: 我相信你的系統(tǒng)是這樣的，但是不代表所有的系統(tǒng)都需要象你這樣。對于很多中小型系統(tǒng)來說，如此優(yōu)雅的架構(gòu)并不都是必須的。
而且，你這樣對開發(fā)的效率有影響，代碼量又多啦，呵呵，對開發(fā)人員總體素質(zhì)的要求也高了不少，公司的成本又高囖。 這些都是需要考慮的。:evil:
當(dāng)然，我承認(rèn)后一種方法的先進(jìn)性和靈活性，但是，還是那個問題，不需要拿牛的殺雞，而現(xiàn)在的市場，雞還是比牛多一些。
gigix：這也是你的想當(dāng)然。如果采用一個優(yōu)雅的架構(gòu)，普通程序員只需要編寫面向?qū)ο蟮某绦蚓妥銐蛄?。他不需要考慮如何管理事務(wù)，他不需要考慮如何記錄日志，他甚至不需要考慮如何獲得和關(guān)閉數(shù)據(jù)庫連接，而且他寫的每個模塊都可以從系統(tǒng)中摘出來單獨(dú)測試。難道開發(fā)這樣的程序會更慢、寫更多的代碼、對開發(fā)人員要求更高？相反，如果做太多代碼級的優(yōu)化，勢必?fù)p害架構(gòu)的優(yōu)雅和靈活，會導(dǎo)致更多的重復(fù)代碼，會使得各個模塊耦合緊密而不能獨(dú)立測試，那樣的系統(tǒng)才是代碼量更多、對開發(fā)者要求更高的。
我只舉一個最簡單的例子。你認(rèn)為如果我們需要一個UserManager，那么就直接new UserManager()好了。但是這樣一來，開發(fā)client代碼的人就無法只測試他自己的業(yè)務(wù)邏輯，他的單元測試還必須同時兼顧UserManager的邏輯。我請問你，這是不是比寫一個mock來測試自己這一個模塊有更高的難度？一旦UserManager修改了實現(xiàn)，它的作者必須與所有使用者溝通，以保證這些人的單元測試不會失敗，這是不是增加了工作量降低了開發(fā)效率？如果client代碼能夠這樣寫：
[code:1]
public class MyClass {
private UserManager _um;
public void setUserManager(UserManager um) {
_um = um;
}
public void doSomething() {
_um.doSomething();
}
}
[/code:1]
編寫client的人不必考慮該創(chuàng)建UserManager的哪個實現(xiàn)類，也不必考慮如何創(chuàng)建，也不必關(guān)心這個對象的生命周期，也不用管它是本地對象還是RPC stub。難道這樣寫程序不是更輕松、代碼量更少、對程序員的要求更低嗎？
andyyehoo：
gigix寫道：
這也是你的想當(dāng)然。如果采用一個優(yōu)雅的架構(gòu)，普通程序員只需要編寫面向?qū)ο蟮某绦蚓妥銐蛄?。他不需要考慮如何管理事務(wù)，他不需要考慮如何記錄日志，他甚至不需要考慮如何獲得和關(guān)閉數(shù)據(jù)庫連接，而且他寫的每個模塊都可以從系統(tǒng)中摘出來單獨(dú)測試。難道開發(fā)這樣的程序會更慢、寫更多的代碼、對開發(fā)人員要求更高？相反，如果做太多代碼級的優(yōu)化，勢必?fù)p害架構(gòu)的優(yōu)雅和靈活，會導(dǎo)致更多的重復(fù)代碼，會使得各個模塊耦合緊密而不能獨(dú)立測試，那樣的系統(tǒng)才是代碼量更多、對開發(fā)者要求更高的。
在正規(guī)公司里面，分工明確的話，都是專人寫好架構(gòu)，普通程序員按照架構(gòu)往里面填代碼就是的啦。正常情況下，他也是不需要如何管理事務(wù)，記錄日志，獲得和關(guān)閉連接，每個模塊也可以單獨(dú)測試。
但是，程序調(diào)試出錯的時候，他們也需要自己查看日志，考慮一下各方各面的因素才能調(diào)試，按照第二種寫法，無疑，這些程序員的素質(zhì)要相對高一些，考慮的問題更多一些，才能進(jìn)行調(diào)試的。
gigix寫道：
我只舉一個最簡單的例子。你認(rèn)為如果我們需要一個UserManager，那么就直接new UserManager()好了。
這個是例子這么寫的，需要靈活的部分，我們自然會用其它方法寫。不過在最簡單的情況中，我們是會這么寫，更簡單的情況，直接還調(diào)用靜態(tài)方法，不會不給吧，呵呵
gigix：
andyyehoo 寫道
這個是例子這么寫的，需要靈活的部分，我們自然會用其它方法寫。不過在最簡單的情況中，我們是會這么寫，更簡單的情況，直接還調(diào)用靜態(tài)方法，不會不給吧，呵呵 :lol:
別的不多說，就說這一件事好了。我要求所有程序員嚴(yán)格遵循“針對接口編程”的原則，每個組件必須提供一個接口和一個實現(xiàn)，獲得組件必須以接口的形式、通過dependency injection獲得。而按照你的說法，你要求程序員在提供功能時有時針對接口編程，有時針對對象編程，有時靜態(tài)方法實現(xiàn)，也就是說你要求程序員清楚這三種設(shè)計的語義區(qū)別和利弊權(quán)衡。我想請問你，究竟是誰對程序員的要求更高呢？
andyyehoo：
引用
別的不多說，就說這一件事好了。我要求所有程序員嚴(yán)格遵循“針對接口編程”的原則，每個組件必須提供一個接口和一個實現(xiàn)，獲得組件必須以接口的形式、通過dependency injection獲得。
佩服佩服，沒有程序員抗議嘛？
引用
有時針對接口編程，有時針對對象編程，有時靜態(tài)方法實現(xiàn)，也就是說你要求程序員清楚這三種設(shè)計的語義區(qū)別和利弊權(quán)衡。
我們現(xiàn)在是這樣，不過，這個好像是JAVA程序員的基本功吧，雖然現(xiàn)在很多程序員基本功不好，那樣的話，還是我們要求高點(diǎn)，按照你那樣寫的話，都快可以機(jī)器產(chǎn)生代碼了，呵呵，可以考慮開始向自動產(chǎn)生代碼發(fā)展了。
不過嘛，還是那個問題，出了bug，你們調(diào)試還是比較困難點(diǎn)吧？
gigix：
andyyehoo 寫道
|
別的不多說，就說這一件事好了。我要求所有程序員嚴(yán)格遵循“針對接口編程”的原則，每個組件必須提供一個接口和一個實現(xiàn)，獲得組件必須以接口的形式、通過dependency
injection獲得。
|
有時針對接口編程，有時針對對象編程，有時靜態(tài)方法實現(xiàn)，也就是說你要求程序員清楚這三種設(shè)計的語義區(qū)別和利弊權(quán)衡。
|
我們現(xiàn)在是這樣，不過，這個好像是JAVA程序員的基本功吧，雖然現(xiàn)在很多程序員基本功不好，那樣的話，還是我們要求高點(diǎn)，按照你那樣寫的話，都快可以機(jī)器產(chǎn)生代碼了，呵呵，可以考慮開始向自動產(chǎn)生代碼發(fā)展了。
不過嘛，還是那個問題，出了bug，你們調(diào)試還是比較困難點(diǎn)吧？
對象怎么創(chuàng)建、對象的生命周期怎么管理，這些都是跟業(yè)務(wù)沒關(guān)系的infrastructure。讓程序員可以不操心這些infrastructure，一心關(guān)注自己的業(yè)務(wù)邏輯，怎么會有人抗議？
你說“調(diào)試比較困難”，我就真的很懷疑你究竟有多少經(jīng)驗了。任何一個有經(jīng)驗的J2EE開發(fā)者都會知道，OOD做得越好，debug越輕松。OOD做得好，你才可能做出完備的單元測試，然后用單元測試快速鎖定debug的范圍。我們調(diào)試比較困難嗎？我真的不知道該怎么回答這個問題，因為我已經(jīng)好久沒開過debugger了。
andyyehoo：
引用
你說“調(diào)試比較困難”，我就真的很懷疑你究竟有多少經(jīng)驗了。任何一個有經(jīng)驗的J2EE開發(fā)者都會知道，OOD做得越好，debug越輕松。OOD做得好，你才可能做出完備的單元測試，然后用單元測試快速鎖定debug的范圍。我們調(diào)試比較困難嗎？我真的不知道該怎么回答這個問題，因為我已經(jīng)好久沒開過debugger了。
所指的bug，是指需要在spring的配置，aop搭建的事務(wù)控制，日志中穿梭尋找的bug，不過這個對于你來說應(yīng)該是很熟了，所以沒什么感覺了，一樣快速鎖定了。應(yīng)該就是良好的架構(gòu)使這定位個過程很快的。反正有固定步法的話，走7步和走5步差不多吧，呵呵。
gigix：
andyyehoo 寫道
你說“調(diào)試比較困難”，我就真的很懷疑你究竟有多少經(jīng)驗了。任何一個有經(jīng)驗的J2EE開發(fā)者都會知道，OOD做得越好，debug越輕松。OOD做得好，你才可能做出完備的單元測試，然后用單元測試快速鎖定debug的范圍。我們調(diào)試比較困難嗎？我真的不知道該怎么回答這個問題，因為我已經(jīng)好久沒開過debugger了。
|
所指的bug，是指需要在spring的配置，aop搭建的事務(wù)控制，日志中穿梭尋找的bug，不過這個對于你來說應(yīng)該是很熟了，所以沒什么感覺了，一樣快速鎖定了。應(yīng)該就是良好的架構(gòu)使這定位個過程很快的。反正有固定步法的話，走7步和走5步差不多吧，呵呵。
這些事情更不需要debug，因為它們都在冒煙測試的范圍內(nèi)。只要一開始測試通過，你做了一件事以后變得不通過了，馬上就可以知道是你剛才的改動造成了破壞。這里沒有5步、7步的調(diào)試，只有1步：回退你上一分鐘做的修改。
說起來，好象你也開始贊成：OOD和良好的架構(gòu)才是真正重要的，而不是20毫秒的性能提升。
andyyehoo:
引用
說起來，好象你也開始贊成：OOD和良好的架構(gòu)才是真正重要的，而不是20毫秒的性能提升。
:lol: 我一直的觀點(diǎn)是，OOD和良好的架構(gòu)當(dāng)然很重要的，但是要根據(jù)項目選擇合適靈活的架構(gòu)，而不必全部采用最靈活的系統(tǒng)，而在這個基礎(chǔ)上，“20毫秒的性能提升”，也是需要考慮的事情之一，而不可以完全拋之腦后。
突然想到A計劃2成龍說的，我不能接受任何人，以國家民族利益的崇高名義，草菅任何無辜市民的生命。（記不太清，大概）哈哈，有點(diǎn)象