新来的实习生竟然偷偷在代码里“下毒”......( 二 ) 【51CTO.com原创稿件】写这个文章是因

第一，这 10000 次开销如果是程序员在写代码已经明确知道的开销属于业务必须那倒无妨，只怕程序员在写代码的时候还无意识到这个点是会被随时放大。
第二，即使 10000 次开销是属于业务必须，那按照这个代码来看，还是存在可以优化的空间，可以在循环中将所有查询条件都进行拼凑，然后在进行一定程度的批量查询，可以较大程度降低 DB 的开销。
不要随意定义局部变量名
命名风格我们可以参考阿里的《Java开发手册》，这里主要指出来的是局部变量随意命名的现象比较严重，大家一般都会以为局部变量只是在本方法内使用，又不会对其他方法和其他人造成影响。
但殊不知局部变量名起得不好或随意也对开发者本身造成困扰甚至连自己到不知道的错误，以下是一个比较经典的随意起变量名的例子：
文章插图
变量名 ma 和 map 没有本身含义，并且他们的泛类又是一样，很难保证不会再下面的代码不小心使用错误。
避免又臭又长的类和方法
一点都不夸张，之前看到过一类一千多行，一个方法长达 300 行， IDE 大概一页正常来说 30-50 行(取决屏幕大小) ，这个叫阅读者怎么查看。
阅读的时候，不断的滚轮翻页，就算是原作者，恐怕时间一长也很难驾驭这个类，就不用说后来的维护者了。
更重要的是一个类，一个方法过长时，会严重阻碍你的扩展和修改，方法中每一个逻辑都牵扯到很多分散的上下文，会让修改和扩展异常困难。
按照《重构》所说，出现类过长的情况很多是职责不明确，一个类存在着几十个方法，那绝对是职责过多或职责不细分。
简单列一下针对又长又臭的重构处理：

分析需要重构类的功能。
将职责相同的方法使用组合或集成的方式抽取为独立的类。
分析各个方法，将重复的代码提取为函数。
命名，对类有一个好的命名有利于对类的定位和确立职责。

Log 日志要提供明确的指向，辅助定位
Log 日志要有明确的指向性，一个可以辅助调试，一个可以记录事件，和确立定位错误。
像以下的这个例子，打印了一个 log.error 日志，但这个错误，就算我们事后去查看日志，只知道这里有一个错误日志，但究竟是哪一个用户日志，哪一张优惠券的日志，无从得知，不能有助于我们直接定位错误。

文章插图
再看一下的日志，将返回的一个 List 进行直接打印，此处的打印并无助于保留和定位问题，只会留下无价值的信息并且让日志变得乱糟糟。
通常，我们留下实体名字和逻辑关键字就足以识别一条记录。

文章插图
复杂模块，代码未动，大纲注释先行
要阻止一个初级的程序员一上来就写代码的难度堪比阻止一饥饿的人要饱餐一顿，有多少程序员被称之为码农，一上来就想搬砖。
在流程和系统的设计上，我们有 E-R 图和流程图，帮我们建立模型和流程。
当我们碰到逻辑比较复杂的类或方法，我们也需要先梳理好逻辑和流程，用注释或伪代码定好逻辑和流程，把整体的思路确立后，搭起一个骨架，再往里面填肉(写代码) 。
只要流程清晰，逻辑明朗，这个时候写代码其实是最简单的事情。

文章插图
功能相同尽量抽象，不要发散式修改