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