最近看一本書(shū)叫《改善java程序的151個(gè)建議》，發(fā)現(xiàn)這么一個(gè)方法。 public static int max(int[] data) {
Arrays.sort(data.clone()); //秒處
return data[data.length - 1]
}這個(gè)方法的意圖是找到數(shù)組中最大的一個(gè)數(shù)，為什么排序的是克隆對(duì)象呢，因?yàn)檫@個(gè)方法的目的是取最大數(shù)，通過(guò)克隆對(duì)象去取的話，不改變?cè)袛?shù)組的結(jié)構(gòu)，可是讀者發(fā)現(xiàn)這個(gè)方法有問(wèn)題，排序的是克隆對(duì)象，取值卻還是從原來(lái)的數(shù)組中取.請(qǐng)教大家，這個(gè)方法應(yīng)該到底怎么寫(xiě)。
2 回答
拉丁的傳說(shuō)
TA貢獻(xiàn)1789條經(jīng)驗(yàn) 獲得超8個(gè)贊
首先我要解釋一點(diǎn)，就是，保持程序的正確性，維持程序的簡(jiǎn)潔性，是作為程序員的第一要?jiǎng)?wù)
Don’t Cut Yourself: Code Optimization as a Double-Edged Sword。中文翻譯：過(guò)早優(yōu)化是萬(wàn)惡之源。
代碼優(yōu)化的好處多多，但是這并不意味著所有的代碼都需要進(jìn)行優(yōu)化，有時(shí)過(guò)度的優(yōu)化反而適得其反——費(fèi)時(shí)、費(fèi)力、不討好。
“現(xiàn)代計(jì)算機(jī)科學(xué)的鼻祖”Donald Knuth曾說(shuō)過(guò)“過(guò)早的優(yōu)化是萬(wàn)惡之源”，因?yàn)椋鹤屨_的程序更快，要比讓快速的程序正確容易得多。文中講了7個(gè)原則，簡(jiǎn)單羅列如下：
1. 究竟要優(yōu)化什么？
2. 選擇一個(gè)正確的優(yōu)化指標(biāo)
3. 優(yōu)化在刀刃上
4. 優(yōu)化層次越高越好
5. 不要過(guò)早優(yōu)化
6. 依賴性能分析，而不是直覺(jué)
7. 優(yōu)化不是萬(wàn)金油
因此脫離了上下文，不要去討論代碼的效率。
以你的程序?yàn)槔?，我們首先要搞清楚的是，這個(gè)尋找最大數(shù)的代碼，在整個(gè)程序中是否是在熱區(qū)上。所謂熱區(qū)，就是說(shuō)，這個(gè)函數(shù)是頻繁被調(diào)用么？或者是程序中耗時(shí)最多的代碼么？大多數(shù)情況下，你寫(xiě)了一個(gè)程序（我說(shuō)的是有一定規(guī)模的商業(yè)軟件），90%的代碼，其實(shí)都是幾乎不被調(diào)用的，而只有10%的代碼是反復(fù)調(diào)用，耗時(shí)巨大的。在不是熱區(qū)的代碼上“優(yōu)化”，哪怕程序性能提高了1億倍，但是程序的運(yùn)行時(shí)間也只能壓縮10%。
然而這么做付出的代價(jià)是，程序變得面目全非，到處都是各種奇怪的技巧，難以修改。項(xiàng)目開(kāi)發(fā)進(jìn)度大大增加。甚至為了性能，引入bug，連正確性都沒(méi)有辦法保證。
我沒(méi)有你說(shuō)的那本書(shū)，也沒(méi)有看到你代碼的上下文。
但是如果這個(gè)代碼不位于熱區(qū)，并不需要苛求性能的話，我覺(jué)得這么寫(xiě)很清晰，體現(xiàn)了作者明白的意圖，就是尋找最大數(shù)，并且通過(guò)克隆避免對(duì)原始數(shù)據(jù)的順序的修改嘛。當(dāng)然，我們有更快的做法，問(wèn)題是一個(gè)會(huì)武功的人，需要在吃飯的時(shí)候也把筷子當(dāng)作武器耍弄一番么？
添加回答
舉報(bào)
0/150
提交
取消