java編程經(jīng)常犯的錯(cuò)誤

1、軟件編程21法則（中文版） 任何一個(gè)有經(jīng)驗(yàn)的程序員都知道，軟件開(kāi)發(fā)遵循著一些不成文的法則。然而，如果你不遵循這些法則也并不意味著會(huì)受到懲罰；相反，有時(shí)你還會(huì)獲得意外的好處。下面的就是軟件編程中的21條法則： 1.任何程序一旦部署即顯陳舊。 2.修改需求規(guī)范來(lái)適應(yīng)程序比反過(guò)來(lái)做更容易。 3.一個(gè)程序如果很有用，那它注定要被改掉。 4.一個(gè)程序如果沒(méi)用，那它一定會(huì)有很好的文檔。 5.任何程序里都僅僅只有10%的代碼會(huì)被執(zhí)行到。 6.軟件會(huì)一直膨脹到耗盡所有資源為止。 7.任何一個(gè)有點(diǎn)價(jià)值的程序里都會(huì)有至少一個(gè)bug。 8.原型完美的程度跟審視的人數(shù)成反比，反比值會(huì)隨著涉及的資金數(shù)增大。 9.軟件直

2、到被變成產(chǎn)品運(yùn)行至少6個(gè)月后，它最嚴(yán)重的問(wèn)題才會(huì)被發(fā)現(xiàn)。 10.無(wú)法檢測(cè)到的錯(cuò)誤的形式無(wú)限多樣，而能被檢測(cè)到的正好相反，被定義了的十分有限。 11.修復(fù)一個(gè)錯(cuò)誤所需要投入的努力會(huì)隨著時(shí)間成指數(shù)級(jí)增加。 12.軟件的復(fù)雜度會(huì)一直增加，直到超出維護(hù)這個(gè)程序的人的承受能力。 13.任何自己的程序，幾個(gè)月不看，形同其他人寫(xiě)的。 14.任何一個(gè)小程序里面都有一個(gè)巨大的程序蠢蠢欲出。 15.編碼開(kāi)始的越早，花費(fèi)的時(shí)間越長(zhǎng)。 16.一個(gè)粗心的項(xiàng)目計(jì)劃會(huì)讓你多花3倍的時(shí)間去完成；一個(gè)細(xì)心的項(xiàng)目計(jì)劃只會(huì)讓你多花2倍的時(shí)間。 17.往大型項(xiàng)目里添加人手會(huì)使項(xiàng)目更延遲。 18.一個(gè)程序至少會(huì)完成90%，但永遠(yuǎn)完成不

3、了超過(guò)95%。 19.如果你想麻煩被自動(dòng)處理掉，你得到的是自動(dòng)產(chǎn)生的麻煩。 20.開(kāi)發(fā)一個(gè)傻瓜都會(huì)使用的軟件，只有傻瓜愿意使用它。 21.用戶(hù)不會(huì)真正的知道要在軟件里做些什么，除非使用過(guò)。 英文原版： 21 Laws of Computer Programming As any experienced computer programmer knows, there are unwritten laws that govern software development. However there are no penalties for breaking these laws; rather

4、, there is often a reward. Following are 21 Laws of Computer Programming: 1.Any given program, once deployed, is already obsolete. 2.It is easier to change the specification to fit the program than vice versa. 3.If a program is useful, it will have to be changed. 4.If a program is useless, it will h

5、ave to be documented. 5.Only ten percent of the code in any given program will ever execute. 6.Software expands to consume all available resources. 7.Any non-trivial program contains at least one error. 8.The probability of a flawless demo is inversely proportional to the number of people watching,

6、raised to the power of the amount of money involved. 9.Not until a program has been in production for at least six months will its most harmful error be discovered. 10.Undetectable errors are infinite in va riety, in contrast to detectable errors, which by definition are limited. 11.The effort requi

7、red to correct an error increases exponentially with time. 12.Program complexity grows until it exceeds the capabilities of the programmer who must maintain it. 13.Any code of your own that you havent looked at in months might as well have been written by someone else. 14.Inside every small program

8、is a large program struggling to get out. 15.The sooner you start coding a program, the longer it will take. 16.A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long. 17.Adding programmers to a late project makes it late

9、r. 18.A program is never less than 90% complete, and never more than 95% complete. 19.If you automate a mess, you get an automated mess. 20.Build a program that even a fool can use, and only a fool will want to use it. 21.Users truly dont know what they want in a program until they use it. 事實(shí)一： “今天（

10、2010-10-01）上午我們的某版本系統(tǒng)在某省出現(xiàn)了故障，該版本在這個(gè)省上線恰好將近6個(gè)月_，系統(tǒng)上線以來(lái)一直運(yùn)行良好，直到這次故障。故障現(xiàn)象為"掛死":所有進(jìn)程都掛死在某一把鎖的lock上。以前出現(xiàn)這種情況多為某個(gè)進(jìn)程加鎖后，在鎖內(nèi)異常退出，未能釋放鎖而導(dǎo)致其他進(jìn)程掛死。這種"掛死"多是代碼中訪問(wèn)非法內(nèi)存地址 導(dǎo)致的，一般都會(huì)有core文件dump出來(lái)。不過(guò)這次出現(xiàn)掛死后，我們并未找到core文件的影子。查看系統(tǒng)運(yùn)行日志也無(wú)果。通過(guò)腳本將所有該應(yīng)用的子進(jìn)程的運(yùn)行?？煺帐占揭粋€(gè)文件中，然后對(duì)這個(gè)數(shù)據(jù)龐大的文件進(jìn)行分析，以試圖找到一些蛛絲馬跡。 分析發(fā)

11、現(xiàn)絕大多數(shù)子進(jìn)程都掛起了，其運(yùn)行棧棧頂多為： lwp_mutex_timedlock (f1444c28, 0 不過(guò)只有一個(gè)進(jìn)程與眾不同，它的棧頂 是一個(gè)我們自己實(shí)現(xiàn)的函數(shù)，這里暫且稱(chēng)這個(gè)函數(shù)為foo_func吧。迅速查看foo_func的源碼實(shí)現(xiàn)，發(fā)現(xiàn)一個(gè)while循環(huán)，第一時(shí)間想到:是不是foo_func進(jìn)入while死循環(huán)了？在故障應(yīng)用主機(jī)上用top查看一下系統(tǒng)運(yùn)行狀態(tài)，發(fā)現(xiàn)確有一個(gè)進(jìn)程占用cpu很高，而且持續(xù)很高。pstack一下這個(gè)進(jìn)程，棧頂端果真就是foo_func，“死循環(huán)”的推論是正確的。 即使這個(gè)進(jìn)程死循環(huán)了，怎么會(huì)連累其他進(jìn)程也停止工作了呢？原因就在于這個(gè)死循環(huán)是在這個(gè)子進(jìn)

12、程獲得鎖之后發(fā)生的，因?yàn)樗姥h(huán)了，導(dǎo)致無(wú)法釋放這把鎖，其他子進(jìn)程干著急也無(wú)可奈何！ foo_func為何能進(jìn)入死循環(huán)？仔細(xì)斟酌一下foo_func的代碼也不難得出：代碼中混用了int和unsigned char，導(dǎo)致數(shù)組下標(biāo)值變?yōu)樨?fù)數(shù)，數(shù)組訪問(wèn)溢出，讀取到的值是隨機(jī)值，所以死循環(huán)也是隨機(jī)發(fā)生的（之前幾個(gè)月運(yùn)行都良好也是因?yàn)檫@個(gè)原因）?！?. . Java開(kāi)發(fā)最容易犯的21種錯(cuò)誤 url： 1.Duplicated Code 代碼重復(fù)幾乎是最常見(jiàn)的異味了。他也是Refactoring的主要目標(biāo)之一。代碼重復(fù)往往來(lái)自于copy-and-paste的編程風(fēng)格。與他相對(duì)應(yīng)OAOO是一個(gè)好系統(tǒng)的重要標(biāo)志

13、。 2.Long method 它是傳統(tǒng)結(jié)構(gòu)化的“遺毒”。一個(gè)方法應(yīng)當(dāng)具有自我獨(dú)立的意圖，不要把幾個(gè)意圖放在一起。 3.Large Class 大類(lèi)就是你把太多的責(zé)任交給了一個(gè)類(lèi)。這里的規(guī)則是One Class One Responsibility. 4.Divergent Change 一個(gè)類(lèi)里面的內(nèi)容變化率不同。某些狀態(tài)一個(gè)小時(shí)變一次，某些則幾個(gè)月一年才變一次；某些狀態(tài)因?yàn)檫@方面的原因發(fā)生變化，而另一些則因?yàn)槠渌矫娴脑蜃円淮巍Ｃ嫦驅(qū)ο蟮某橄缶褪前严鄬?duì)不變的和相對(duì)變化相隔離。把問(wèn)題變化的一方面和另一方面相隔離。這使得這些相對(duì)不變的可以重用。問(wèn)題變化的每個(gè)方面都可以單獨(dú)重用。這種相異變化的

14、共存使得重用非常困難。 5.Shotgun Surgery 這正好和上面相反。對(duì)系統(tǒng)一個(gè)地方的改變涉及到其他許多地方的相關(guān)改變。這些變化率和變化內(nèi)容相似的狀態(tài)和行為通常應(yīng)當(dāng)放在同一個(gè)類(lèi)中。 6.Feature Envy 對(duì)象的目的就是封裝狀態(tài)以及與這些狀態(tài)緊密相關(guān)的行為。如果一個(gè)類(lèi)的方法頻繁用get 方法存取其他類(lèi)的狀態(tài)進(jìn)行計(jì)算，那么你要考慮把行為移到涉及狀態(tài)數(shù)目最多的那個(gè)類(lèi)。 7.Data Clumps 某些數(shù)據(jù)通常像孩子一樣成群玩耍：一起出現(xiàn)在很多類(lèi)的成員變量中，一起出現(xiàn)在許多方法的參數(shù)中，這些數(shù)據(jù)或許應(yīng)該自己獨(dú)立形成對(duì)象。 8.Primitive Obsession 面向?qū)ο蟮男率滞ǔＡ?xí)

15、慣使用幾個(gè)原始類(lèi)型的數(shù)據(jù)來(lái)表示一個(gè)概念。譬如對(duì)于范圍，他們會(huì)使用兩個(gè)數(shù)字。對(duì)于Money，他們會(huì)用一個(gè)浮點(diǎn)數(shù)來(lái)表示。因?yàn)槟銢](méi)有使用對(duì)象來(lái)表達(dá)問(wèn)題中存在的概念，這使得代碼變的難以理解，解決問(wèn)題的難度大大增加。好的習(xí)慣是擴(kuò)充語(yǔ)言所能提供原始類(lèi)型，用小對(duì)象來(lái)表示范圍、金額、轉(zhuǎn)化率、郵政編碼等等。 9.Switch Statement 基于常量的開(kāi)關(guān)語(yǔ)句是OO 的大敵，你應(yīng)當(dāng)把他變?yōu)樽宇?lèi)、state或strategy. 10. Parallel Inheritance Hierarchies 并行的繼承層次是shotgun surgery的特殊情況。因?yàn)楫?dāng)你改變一個(gè)層次中的某一個(gè)類(lèi)時(shí)，你必須同時(shí)改變另

16、外一個(gè)層次的并行子類(lèi)。 11. Lazy Class 一個(gè)干活不多的類(lèi)。類(lèi)的維護(hù)需要額外的開(kāi)銷(xiāo)，如果一個(gè)類(lèi)承擔(dān) 了太少的責(zé)任，應(yīng)當(dāng)消除它。 12. Speculative Generality 一個(gè)類(lèi)實(shí)現(xiàn)了從未用到的功能和通用性。通常這樣的類(lèi)或方法唯一的用戶(hù)是testcase.不要猶豫，刪除它。 13. Temporary Field 一個(gè)對(duì)象的屬性可能只在某些情況下才有意義。這樣的代碼將難以理解。專(zhuān)門(mén)建立一個(gè)對(duì)象來(lái)持有這樣的孤兒屬性，把只和他相關(guān)的行為移到該類(lèi)。最常見(jiàn)的是一個(gè)特定的算法需要某些只有該算法才有用的變量。 14. Message Chain 消息鏈發(fā)生于當(dāng)一個(gè)客戶(hù)向一個(gè)對(duì)象要求另

17、一個(gè)對(duì)象，然后客戶(hù)又向這另一對(duì)象要求另一個(gè)對(duì)象，再向這另一個(gè)對(duì)象要求另一個(gè)對(duì)象，如此如此。這時(shí)，你需要隱藏分派。 15. Middle Man 對(duì)象的基本特性之一就是封裝，而你經(jīng)常會(huì)通過(guò)分派去實(shí)現(xiàn)封裝。但是這一步不能走得太遠(yuǎn)，如果你發(fā)現(xiàn)一個(gè)類(lèi)接口的一大半方法都在做分派，你可能需要移去這個(gè)中間人。 16. Inappropriate Intimacy 某些類(lèi)相互之間太親密，它們花費(fèi)了太多的時(shí)間去磚研別人的私有部分。對(duì)人類(lèi)而言，我們也許不應(yīng)該太假正經(jīng)，但我們應(yīng)當(dāng)讓自己的類(lèi)嚴(yán)格遵守禁欲主義。 17. Alternative Classes with Different Interfaces 做相同事情的方法有不同的函數(shù)signature，一致把它們往類(lèi)層次上移，直至協(xié)議一致。 18. Incomplete Library Class 要建立一個(gè)好的類(lèi)庫(kù)非常困難。我們大量的程序工作都基于類(lèi)庫(kù)實(shí)現(xiàn)。然而，如此廣泛而