程序員面臨的最痛苦之事，莫過于修改舊代碼；如果還有比這更痛苦的，就是修改糟糕透頂，亂得一團(tuán)糟的爛代碼。最近因?yàn)槭值紫乱粠统绦騿T都在忙，市場(chǎng)部正好又反饋過來一個(gè)要命的bug，一時(shí)手癢，就領(lǐng)下了這個(gè)任務(wù)。我們這個(gè)產(chǎn)品是針對(duì)教育行業(yè)的，它是在好幾年前開發(fā)，然后不斷完善和維護(hù)。這些階段都是在我來到這家公司之前完成的。所以，我對(duì)于產(chǎn)品的代碼并不熟悉。

　　原來的需求是假定客戶設(shè)置分?jǐn)?shù)段時(shí)，不同的分?jǐn)?shù)段有不同的有效分，對(duì)應(yīng)著也就有不同的名次。這些數(shù)據(jù)都是經(jīng)過分析器分析獲得，并持久化到數(shù)據(jù)庫中。當(dāng)我們需要生成學(xué)生報(bào)告時(shí)，再從數(shù)據(jù)庫中獲取，并將數(shù)據(jù)填充到iReport設(shè)置好的模板中，一個(gè)是二維表，一個(gè)是柱狀和曲線圖。

　　現(xiàn)在，我們發(fā)現(xiàn)某些學(xué)校需要給不同的分?jǐn)?shù)段設(shè)置完全相同的有效分，以及相同的名次。報(bào)告打印出來，二維表沒有錯(cuò)，曲線圖卻出現(xiàn)了“缺斤少兩”的現(xiàn)象。例如設(shè)置五個(gè)分?jǐn)?shù)段，卻可能只顯示了四條曲線。

　　閱讀代碼，我明白了原因。在原來的實(shí)現(xiàn)中，由于默認(rèn)不同分?jǐn)?shù)段有不同名次，因此，在獲取這些分?jǐn)?shù)段的值時(shí)，是將它們放入到一個(gè)Map<Subject, Map<Integer, Double>>中。這個(gè)Map是根據(jù)科目進(jìn)行分類的，子Map的key值為Integer類型，其實(shí)就是分?jǐn)?shù)段對(duì)應(yīng)的名次，value則是設(shè)置的有效分。由于現(xiàn)在的名次存在重復(fù)，導(dǎo)致Map中的元素存在偏差。這就是五個(gè)分?jǐn)?shù)段只顯示四條曲線的緣由。

　　事實(shí)上，在我看到這樣的Map時(shí)，就明白這種“超級(jí)強(qiáng)大”的容器，事實(shí)上往往會(huì)成為壞代碼的泥沼。當(dāng)我們將這樣的對(duì)象作為參數(shù)，在方法之間傳來傳去的時(shí)候，會(huì)帶來諸多問題：
　　1）性能影響。這種可能比較龐大的容器對(duì)象，有可能會(huì)形成性能瓶頸；
　　2）強(qiáng)類型。雖然這里使用了泛型，但泛型類型卻使用了基本類型；
　　3）封裝性不夠好。這樣的容器對(duì)象暴露了太多的數(shù)據(jù)細(xì)節(jié)，且不利于為其定義職責(zé)行為。
　　4）可讀性差。看到這樣的Map，你并不會(huì)在第一時(shí)間明白它到底存放了什么。
　　5）可擴(kuò)展性差：當(dāng)這個(gè)Map作為方法的參數(shù)時(shí)，相當(dāng)于這個(gè)參數(shù)沒有被對(duì)象化。如果擁有這個(gè)參數(shù)的方法被公開，且廣泛調(diào)用，一旦需要改變參數(shù)，牽連到的代碼就會(huì)非常多。

　　事實(shí)正是如此。當(dāng)我在分析我們的遺留代碼時(shí)，發(fā)現(xiàn)很多地方都在重復(fù)獲取這個(gè)Map對(duì)象，并且這個(gè)Map對(duì)象也在多個(gè)方法之間傳遞。因?yàn)檫@種容器對(duì)象自身的缺陷，為我的bug修復(fù)帶來了很多阻礙。要解決這個(gè)Bug，就不能再將名次作為Map的key值。查看相關(guān)的數(shù)據(jù)表，事實(shí)上我們還給出了一個(gè)分?jǐn)?shù)段的名稱。當(dāng)名次和有效分存在重復(fù)的情況下，結(jié)合分?jǐn)?shù)段名稱就能確定唯一值。因此，一個(gè)簡(jiǎn)單地做法就是將Map的key修改為名次加名稱的組合，即將Integer修改為String。

　　現(xiàn)在，我需要決策。如果希望一勞永逸，就應(yīng)該摒棄這種Map的做法。我們應(yīng)該利用封裝來實(shí)現(xiàn)這一目標(biāo)。例如定義ValidScore和ValidScoreRange。后者相當(dāng)于之前的Map<Integer, Double>。ValidScore則包含屬性：Rank, LineName, Score。事實(shí)上，ValidScoreRange正是ValidScore的集合。我們還可以在ValidScore和ValidScoreRange中定義許多與該領(lǐng)域相關(guān)的行為。通過這樣的封裝，問題會(huì)變得簡(jiǎn)單許多。

　　然而，思考良久，我卻放棄了這個(gè)符合OO原則的做法。原因在于，遺留代碼中使用Map<Subject, Map<Integer, Double>>的類和方法有很多，特別讓人煩惱的是在這些方法中，有很多還定義在某些公共類中，被系統(tǒng)的大多數(shù)Client所調(diào)用。例如這樣的代碼：

public static JFreeChart createEliteTotalChart(Grade grade, String partial,
        ExamSet es, Student stu, Map subToStuTotalMap,
        Map<Subject, Map<Integer, Double>> subToValidScoreMap,
        List subList,long stuRank,
        String[] validLineSeries,double barWidth,Color barColor) {
    if (subToStuTotalMap == null || subList == null) {
        return null;
    }
    Color[] color = {Color.RED,Color.BLUE,Color.GREEN,
                     Color.CYAN,Color.BLACK,Color.MAGENTA};
    CategoryDataset[] dataset = EIDatasetFactory.createEliteTotalDataset(
            subToStuTotalMap, subToValidScoreMap, subList,validLineSeries);

　　//......為清晰起見，其余代碼略
}        

        

        
        
      
        
it知識(shí)庫：精益求精，抑或得過且過，轉(zhuǎn)載需保留來源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。