【51CTO.com原創(chuàng)稿件】“朋友，你還會修電腦啊？”這是小史在朋友中聽到過的最多的一句話。每當(dāng)聽到這句話時，他也很無奈。難道程序猿就一定要會修電腦嘛？但是沒辦法，在朋友眼中，編程是一個很高深的工作。可能動動手指，哪邊就會出什么事，生活十分精彩。嗯，電影看多了。作為一名不會修電腦但努力想學(xué)習(xí)修電腦的程序猿來說，除了修電腦的技能，也還要具備大部分其他程序猿共有的特質(zhì)。比如：宅、悶。可能也具備獨有的特質(zhì)，喜歡陪老婆逛街。。。

[[193566]]

小史·Java開發(fā)

嚴(yán)肅的簡單介紹下本期主人公小史童鞋，從事Java后臺開發(fā)工作已經(jīng)三年有余，目前服務(wù)于一家創(chuàng)業(yè)公司做駐場開發(fā)。期間經(jīng)歷過kafka，大數(shù)據(jù)等領(lǐng)域的開發(fā)。作為程序猿，大家應(yīng)該每天都在和26個字母做著你死我活的斗爭，對于編程應(yīng)該也都有自己獨到的見解。借著這個機會，小史拋個磚頭，粗淺的和大家聊聊關(guān)于代碼的一些事。

一、對復(fù)制/粘貼說NO

小史看過一篇文章《程序員的進步從每一天少寫一點代碼開始》里面提到說Google與網(wǎng)絡(luò)的幫助可以讓你寫出一行又一行的代碼。這句話不禁讓小史想起大學(xué)實習(xí)，面試工作時候，測試主管對他說的一句話：“寫代碼沒什么難的，不就是復(fù)制、粘貼嘛”。當(dāng)聽到這句話的時候，他的腦海中不禁又浮現(xiàn)出了同學(xué)對他說的話：“我現(xiàn)在在公司里整天干的活就是復(fù)制、粘貼”。當(dāng)時小史不經(jīng)意間產(chǎn)生一種疑問，難道程序猿的工作這么簡單和枯燥嘛？帶著這個疑問，他踏入了程序開發(fā)的大軍中。

小史參加工作的***天，他的領(lǐng)導(dǎo)就反復(fù)強調(diào)一句話：“寫代碼不要復(fù)制、粘貼”。這對于剛參加工作的他不是太能理解這句話的含義。當(dāng)時，他一心就是為了工作效率，工作趕緊完成，讓領(lǐng)導(dǎo)知道自己的能力。這就導(dǎo)致了功能代碼的命名、結(jié)構(gòu)差勁，后來返工反而浪費了更多的時間。現(xiàn)在他回頭想想，當(dāng)時的行為是多么的幼稚，如果只是復(fù)制粘貼，并沒有嘗試了解背后的運作機制，充其量代表了工作完成而已。

二、碼農(nóng)的追求——高品質(zhì)代碼

“你的代碼像一坨翔”。相信這句話大家或多或少的在平時工作中都有聽過。曾經(jīng)在網(wǎng)絡(luò)上看見過一個帖子是這樣說的：“相信很多人都認(rèn)為自己的代碼是最棒的，別人的代碼都是很糟糕的，因為看不懂”。畢竟程序猿都有一顆工程師的心，所以當(dāng)他們到新的場地想做的***件事就是，將舊的一切推倒重來。是的，他們決不會滿足于簡單的增量勞動。或許這種微妙的心理定位可以解釋：為什么程序猿進入新項目組后寧愿丟掉舊代碼重新寫，也不愿意修修補補。他們認(rèn)為舊代碼簡直一團糟。

好的代碼，就像是好的笑話，無須解釋就能讓人輕易明白；壞的代碼，就像是古文言，即使寫滿了注解，也不一定能輕易看懂；好的代碼，就像是一本寫作技巧高超的人所寫的書，它容易理解、分章明確；壞的代碼，就像是剛剛學(xué)會寫字的人所寫的書，它錯亂復(fù)雜，自我推翻。

那么，如何寫出一段好代碼呢？小史曾經(jīng)看過一篇文章，覺得解釋的很好，它是這樣說的：

• 可讀性——你所寫出的代碼，不僅你自己要明白，你身邊合作的開發(fā)者也要能在最短的時間內(nèi)看懂。（這個尤其要注意）
• 可維護性——讓你的代碼在修改的時候很簡單。
• 簡潔性——不要讓你的代碼看上去毫無必要的復(fù)雜。
• 效率性——盡可能的讓你的代碼獲得最快的運行速度。
• 明確性——類的命令、方法的命名要清楚的表達出具體動作的含義。

三、代碼優(yōu)化很有必要

代碼優(yōu)化，一個很重要的課題。可能有些人覺得沒用，一些細小的地方有什么好修改的，改與不改對于代碼的運行效率有什么影響呢？關(guān)于這個問題，小史有深刻的體會。舉個例子，之前他寫過一個功能用到redis的排序。本著有輪子不造輪子原則，毅然決然的使用了redis提供的排序方法。寫完之后，他還挺高興的，對redis的學(xué)習(xí)又深了一點。然而，事與愿違，當(dāng)代碼放到生產(chǎn)環(huán)境上運行出來的結(jié)果直接把他干懵逼了，在大規(guī)模的數(shù)據(jù)洗禮下，完全跑不動。那晚，小史一行一行打著日志，分析慢的原因，***定位到了redis的排序上（具體代碼細節(jié)不作闡述），然后寫了一個算法代替了redis排序。

關(guān)于代碼優(yōu)化，小史做了很多筆記，如：

1、盡量指定類的final修飾符帶有final修飾符的類是不可派生的。

2、盡量重用對象。特別是String 對象的使用中，出現(xiàn)字符串連接情況時應(yīng)用StringBuffer 代替。

3、盡量使用局部變量，調(diào)用方法時傳遞的參數(shù)以及在調(diào)用中創(chuàng)建的臨時變量都保存在棧（Stack）中，速度較快。其他變量，如靜態(tài)變量、實例變量等，都在堆（Heap）中創(chuàng)建，速度較慢。另外，依賴于具體的編譯器/JVM，局部變量還可能得到進一步優(yōu)化。

4、在Java+ ORACLE 的應(yīng)用系統(tǒng)開發(fā)中，Java中內(nèi)嵌的SQL語句盡量使用大寫的形式，以減輕ORACLE解析器的解析負擔(dān)。

5、盡量減少對變量的重復(fù)計算
例如：for(int i = 0;i < list.size; i ++) {
             …
}
應(yīng)替換為：
for(int i = 0,int len = list.size();i < len; i ++) {
             …
}

6、盡量采用lazy loading的策略，即在需要的時候才開始創(chuàng)建。
     例如：     String str = “aaa”;
             if(i == 1) {
                 list.add(str);
}
應(yīng)替換為：
             if(i == 1) {
String str = “aaa”;
                 list.add(str);
}

等等……

四、書籍很重要

Web行業(yè)知識更新特別快，今天一個框架的新版本，明天又是另一個新框架，有時往往根據(jù)項目的需要來不斷學(xué)習(xí)新東西。所以，我們大家在平時閑暇的時候不妨多看兩本好書，如果實在沒時間看的話，也建議大家去找一些看過這本書的大牛寫的博客。因為，這上面可能就是整本書的精華所在。

以上觀點來自51CTO社群核心開發(fā)者小史的個人見解，歡迎加群（群號312724475）共同交流學(xué)習(xí)~

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】