程序员求生秘籍
今天有个新闻说米国有程序员因为没写注释被杀事件。新闻没细看，后来说是假新闻。
不过即使是假新闻，也着实把人们吓得够呛。为此，我试图理了十个实用动作给大家保平安。
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命名也是不建议的。