今天有個新聞說米國有程序員因爲沒寫註釋被殺事件。新聞沒細看，後來說是假新聞。
不過即使是假新聞，也着實把人們嚇得夠嗆。爲此，我試圖理了十個實用動作給大家保平安。
1、一個方法不要寫得太長。
很多重構的書中都講到，讓你代碼不要寫得太長。方法裏的功能要高度內聚，一個方法你感覺超過一屏，就想着怎麼把代碼中的獨立的功能給抽成一個方法。
2、不要再用eclipse了。
這條也許會招來還在使用eclipse兄弟的罵聲。但我發自內心的告訴你們，idea真的可以幫你搞定很多重構和代碼結構的優化的很多事情。雖然現在用ecplise的人真的不多了，但還是有些兄弟在用。不多說，試着開始用idea吧。
工具真的蠻重要的。就好比打仗的武器一樣。縱使是設計模式學得再好，重構技巧再叼，也請不要忽視工具的重要性。當你精疲力盡的時候，工具出錯的概率更低。
3、if else嵌套太多就想辦法給消除掉。
消除if else有多種辦法。
（1）、反向邏輯法
比如：if(a!=null){
}
這個你也可以寫成這樣：
if(a==null){
return Result.fail('error message');
}
上面這個方法雖然簡單，但真的很實用，可以把你的if else嵌套層數大大的減少。
（2）、多個if的情況
把if裏的代碼不要寫在if裏。而是提取一個接口。
if(a){
//此處300行代碼
。。。。
}
if(b){
//此處400行代碼
。。。。
}
if(c){
//此處500行代碼
}
此時你可以抽出接口把代碼獨立到一個個class類中。
inerface ICheck{
void check(arg ...);
}
class ACheck implements ICheck{
void check(arg ...){
//a的具體實現
}
}
class BCheck implements ICheck{
void check(arg ...){
//b的具體實現
}
}
(3)、約定匹配法
有時候你可以通過map映射來解決具有一定規律的if else，比如最著名的就是 servlet的映射。
put（"contextpath/patch"，patchHandler);
put（"contextpath/del"，delHandler);
put（"contextpath/put"，putHandler);
put（"contextpath/post"，postHandler);
4、過分重構。
剛開始迷戀重構代碼的同學，會陷入過渡重構代碼的問題。動不動喜歡，右鍵，然後refact，然後extract。
你重構要充分考慮你的代碼的流程節點和功能職責的單一性原則，否則爲了重構而重構，會導致你的代碼反而比“滿屏的”更難維護。
5、學好英文，起個好名字。
爲你的數據庫表和類起名字時應該避免以下問題。
別再二話不說照着谷歌翻譯來起名字了。直接用谷歌翻譯翻譯出來也許並不是那個真正的含義。真的需要好好地多查相關領域行業的資料，看看你的那個domain到底該叫什麼，否則最後代碼就不太好維護了。過幾年你英文變好了後你會笑你當初起的名字的。
6、一段好的代碼甚至都不需要註釋。
好的代碼本身就是註釋。
比如一個簡單功能：如果a存在，那麼就把a添加進去。
可讀性差的代碼：
if(xxx!=null && getCount(xxx)>0 && balalaal.size()>0){
sdfsdfsdfsdfsdfsdf
sdfsdfsdfsdfsdfsdfsd
sdfsdfsdfsdfsdfdsf
sdfsdfsdfsdfsdfsdf;
}
可讀性好的代碼：
if(exist(a)){
add(a);
}
顯然下面這段代碼更有可讀性。你甚至可以跟着代碼大聲念出來：如果a存在，那麼就把a添加進去！
好的代碼就像一篇文章一樣！
這裏只是舉個例子，實際開發中你還是得根據具體情況來抽取和編排你的代碼。
7、多寫//todo註釋。
你寫的代碼不可能一下子就完美無比。對於那些你不太滿意的代碼，或者自己覺得有隱患的代碼，請多寫//todo ，做個記號，以後可以優化。否則時間久了你也就忘了那些潛在有問題的代碼了。
8、遵循約定。
做一個有規則感的程序員。規則感就是如果大部隊都是一個風格，那麼也請你一定遵循，即使你可能認爲局部有一些問題。此時的規則和約定已經成爲了團隊和部門溝通的暗語，如果大家都遵循會避免很多的誤會。創新這件事情可以放在代碼具體實現上，不建議放在風格上。
9、感覺代碼慢慢變得複雜時不妨想想設計模式。
設計模式不僅僅是某些特定場景的最佳實踐，同時有時候也能幫你重構你的代碼，讓代碼佈局更加的優雅。比如上面的消除if else的第二個方法，其實就是一種設計模式。
10、轉發此文，做個愛分享的人！
ps：文中的abc命名也是不建議的。