我被要求重構下面這段代碼：
我被要求重構下面這段代碼：
/** * 該方法接收一個{@link Employee}物件的串列，并將。
* * 1- 過濾掉非活動的 {@link Employee} 物件
* * 2- 篩選出{@link Employee}物件的無效代碼
* * 3- 將剩余的{@link Employee}物件的所有工資加起來，并回傳 *
* @param employeeList 一個{@link Employee}物件的串列
* @return 一個{@link BigDecimal}，代表{@link Employee}物件的總工資。
* *沒有過期并且有有效的代碼 */
public BigDecimal getActiveAndValidEmployeesSalariesTotal(finalList<Employee> employeeList){
BigDecimal employeeSalaries = new BigDecimal（0）。
//1- 過濾掉非活動的{@link Employee}物件。
List<Employee> activeEmployees = employeeList.stream().filter(e -> e.active)
.collect(Collectors.toList())。
//2- 過濾掉無效代碼的{@link Employee}物件。
for (Employee employee : activeEmployees) {
List<Long> employeeInvalidCodes = employeeRepository.findInvalidCodesByEmployeeId（employee.id）。
if (employeeInvalidCodes.contains(employee.code)) {
activeEmployees.remove(employee)。
繼續。
}
employeeSalaries = employeeSalaries.add(employee.salary)。
}
return employeeSalaries;
}
我最好的嘗試是，雇員物體可能已經有了無效代碼的串列，這樣我們就不需要通過呼叫employeeRepository.findInvalidCodesByEmployeeId(employee.id)來尋找它們。我的另一個想法是，我們可以快取每個雇員的所有這些無效代碼。顯然，這不是一個好的答案。
從性能的角度來看，重構這段代碼的正確方法是什么？
uj5u.com熱心網友回復：
為什么具有無效代碼的雇員物件甚至可以存在？無效狀態的問題是，你必須找到一些默認行為（在這種情況下，把他們的工資算作零），這既令人厭煩/武斷，也是大量的腿部作業。遠更好的做法是將其設定為
Employee的一個實體根本不可能存在無效的狀態；例如，為任何 "code "使用一個列舉，只包含有效的代碼。如果你不能這樣做，那就做下一個最好的辦法：不要讓無效狀態的物件 "感染 "代碼庫的其他部分（也就是說，它甚至不應該出現在這個方法中），然后，當遇到它們時，拋出一個例外。
。BigDecimal對于salaris來說通常不是一個好主意；相反，使用long，并表示目標貨幣的原子單位。即一個月薪2000美元的人應該得到一個包含200000的long（那么多美分，這就是你的工資）。BD的問題是，它是令人難以置信的復雜，并沒有實際解決任何問題。例如，如果有人 "減薪"，失去了三分之一，那么BD只會拋出一個例外（你不能除以3而不失去精度）。你可以通過給BD一些任意的精度來解決這個問題，但是現在我們又回到了double所遭受的精度不足的問題上，所以通常在你每次需要做除法的時候都明確地編碼四舍五入行為會更好。(也就是說，不可能寫出應用1/3報酬的代碼。例如，只可能寫出應用1/3減法的代碼，然后向下舍入到最接近的美分）。) 一旦你對BigDecimal做了任何 "有趣 "的事情，比如實際將工資轉給雇員，銀行就不允許你轉移小數點。如果你愿意，可以使用一個代表金融金額的物件（它應該同時包含原子單位的金額，例如：美元、位元幣沙托什等，以及貨幣型別）。有一些庫可用于此，例如joda-money.你正在混合基于流的邏輯和for回圈，而最終的結果是過于冗長、混亂和低效。請選擇一個方向。要么[A]for回圈，在回圈內做所有的作業（而不是。"回圈，建立一個全新的串列，只包含活躍的員工，然后，拿著這個串列，回圈，等等"--只是回圈），或者[B]一個流，在一個單一的流操作中做所有的作業。 所以，
.filter()限制到活躍，然后不要呼叫collect(Collectors.toList())，相反，繼續。把它映射到一個物件，用.sum()結束這一切。你的代碼將為每個員工計算出無效的代碼，這聽起來效率相當低。不過，一旦你消除了長期無效狀態的概念，這就不重要了。
BigDecimal.ZERO是表示零的習慣性方法。但是一旦你重構到long或joda-money，就沒有意義了。
從性能的角度來看，重構這段代碼的正確方法是什么？
這真是......太傻了。客觀上正確的答案是，這是一個錯誤的問題，團隊中任何在這方面浪費超過 5 秒鐘的人都應該被送回初級職位。地球上沒有一家公司擁有超過幾萬名員工，所以任何試圖 "提高業績 "的做法都不會有任何結果。對于這樣微小的（幾萬個，用計算機術語來說是很小的）集合，性能不會像這樣作業。CPU快取和熱點變化無常是控制因素。即使是研究這些東西的JVM工程師也不能僅僅預測什么代碼在理論上會運行得更快（我們談論的是將運行時間從1納秒減少到0.999納秒--在任何情況下都完全不相關），指望非JVM工程師知道或應用它是crazy。在任何情況下，無論答案是什么，在不同的作業系統或不同的虛擬機或不同的版本上運行，答案都將是不同的，這進一步強調了在這里擔心這個問題是多么的愚蠢。
正確的做法是重構代碼，使其易于閱讀、易于除錯、易于測驗，并且是習以為常的（看起來像普通java程式員會寫的代碼）。這就是為什么你不應該每次都重新計算無效的代碼，這就是為什么你應該消除長期無效狀態的可能性。不是因為 "它使代碼運行得更快"--而是因為它使代碼更容易遵循，更容易測驗，更容易除錯，并且使它看起來更像標準的java。你想寫成語代碼，不僅僅是因為這意味著你的代碼最容易被別人讀懂，而且還因為JVM工程師在使JVM更有效率時，主要是為了迎合 "常見模式"。因此，寫成語代碼會給你帶來性能上的好處。讓我們把這稱為 "在羅馬時，要像羅馬人一樣 "的規則。
可能你在面試時被問到這個問題，但沒有得到這份作業。這里有三個合理的選擇：
[1]你誤解了這一規則，并沒有得到作業。
[1] 你誤解了面試官問你的內容。
[2] 面試官是一個被誤導的工程師，而且可能有些傲慢，他認為這些問題有正確的答案。他們沒有意識到自己的失敗，例如，他們沒有意識到硬體和JVM在這里植入了控制，從性能上講，而不是演算法。你最好的辦法是，要么變得非常有經驗，知道他們在尋找的錯誤答案，并給出這個答案，要么，最好是繼續前進。你不會想在這里作業的。
[3]面試官不是。像上面這樣的回答（"但是......為什么你要問我'性能更好的代碼'？假設員工的意思是我認為的那樣，現實中不可能超過幾萬個，所以任何可以優化這段代碼的時間顯然不應該花在這里！') -- 那會讓你得到作業。一個好的面試官不會像學校考試那樣問問題，那里有一個正確的答案。相反，他們問的問題會引出一個有趣的回答；他們問的問題會給你機會談論你知道的東西。他們是在檢查你是否能跳出框框，是否有觀點，是否比最低限度的作業要求多知道一點，是否愿意說出你的想法，并能以專業和有效的方式這樣做。如果你愿意，這是一個 "詭計 "問題，真正的測驗是你是否意識到這個問題對這個代碼不合適。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/321076.html
標籤：