06年5月9日在拉斯韋加斯舉辦了ServerSide Java 會(huì)議。會(huì)上，Gregor Hohpe對(duì)一位Java高手說(shuō)，每個(gè)軟件開發(fā)團(tuán)隊(duì)只雇傭最好的最優(yōu)秀的程序員，這肯定是對(duì)的。Google公司軟件架構(gòu)師Hohpe問(wèn)道:“又有哪家公司會(huì)說(shuō)我們要雇用不聰明的工程師呢?”他認(rèn)為不好的程序員肯定是在計(jì)算機(jī)科學(xué)領(lǐng)域中受罪。

不過(guò)，Hohpe質(zhì)疑，假如所有的應(yīng)用開發(fā)項(xiàng)目都使用首回合的草案，他如何才能發(fā)現(xiàn)代碼中的缺陷。當(dāng)他發(fā)現(xiàn)代碼中存在“這是個(gè)錯(cuò)誤”或者“需要進(jìn)行核查”等注釋時(shí)，他很不滿意。最佳的最優(yōu)秀的程序員怎么能夠?qū)懗鲞@樣的代碼和注釋呢?

他一邊不斷重復(fù)著自己的關(guān)鍵詞，一邊問(wèn):“所有漂亮的代碼跑哪里去了?”他用開玩笑的語(yǔ)氣這樣調(diào)侃軟件開發(fā):“大概是門衛(wèi)在半夜進(jìn)來(lái)把我們的代碼搞得亂七八糟吧?！?br />
就像Hohpe所見(jiàn)到的情況一樣，代碼很多時(shí)候是被很一般的可以防止的原因搞亂的。其中的首要原因就是拙劣的代碼引起更多拙劣的代碼。他的理論是，如果某個(gè)應(yīng)用程序的最初的開發(fā)人員不自己的代碼規(guī)劃清晰，讓任何程序員都可以理解，那么潘多拉的盒子就會(huì)被打開。

接下來(lái)的事情從開發(fā)人員編寫代碼開始，即使代碼可以運(yùn)行，但是代碼本身是很難讓其他程序員理解的。接著，在應(yīng)用上馬之后，某個(gè)程序員要做一年的維護(hù)。代碼變成了一堆亂七八糟的東西。

所以，可能第二個(gè)做維護(hù)的程序員在修改時(shí)，會(huì)對(duì)自己說(shuō):“我只在這里添加我的代碼。它不會(huì)壞到哪里去的?！?br />
但經(jīng)過(guò)上面這樣的幾輪修改后，原先由最優(yōu)秀的人編寫的特性代碼，終于變得越來(lái)越糟糕。

他向出席ServerSide會(huì)議的聽眾提供了一些避免以上事情發(fā)生的幾點(diǎn)建議。他說(shuō):“被強(qiáng)迫寫出的代碼不會(huì)好到哪里去。要讓下一個(gè)人覺(jué)得你是在花大力氣編寫優(yōu)雅的代碼?！弊鳛橐粋€(gè)架構(gòu)師，他首先要懂得建模對(duì)應(yīng)用程序的價(jià)值。他說(shuō)，這并不需要很復(fù)雜的建模工具，甚至在一張紙上的畫模型都可以有很好的效果。

Hohpe反復(fù)強(qiáng)調(diào)程序員應(yīng)該是為人寫代碼，而不是為機(jī)器寫代碼。他說(shuō):“要對(duì)人們交互行為進(jìn)行建模。當(dāng)涉及用戶界面時(shí)，這一點(diǎn)尤其重要?！彼ㄗh向非程序員展示應(yīng)用程序，來(lái)觀察程序員對(duì)于程序工作的理解對(duì)于潛在的最終用戶是否正確。

他提醒道，所謂的業(yè)務(wù)邏輯并非總是和程序員所想的一樣。他說(shuō):“假如業(yè)務(wù)邏輯真的和程序員想的一樣，那么就不會(huì)這么困難了。這也是為什么說(shuō)找到最終用戶究竟如何與應(yīng)用程序交互非常重要的原因?！?br />
他敦促Java程序員利用Java的經(jīng)驗(yàn)來(lái)編寫設(shè)計(jì)好的代碼，讓其他程序員覺(jué)得優(yōu)雅?！盀槿硕皇菣C(jī)器編寫代碼”是Hohpe思想的核心。他建議，如果程序員僅僅只為機(jī)器寫代碼，那么他們就不需要Java，他們可以回到匯編代碼的時(shí)代。