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

文章插图
变量名 ma 和 map 没有本身含义，并且他们的泛类又是一样，很难保证不会再下面的代码不小心使用错误。
避免又臭又长的类和方法
一点都不夸张，之前看到过一类一千多行，一个方法长达 300 行， IDE 大概一页正常来说 30-50 行(取决屏幕大小) ，这个叫阅读者怎么查看。
阅读的时候，不断的滚轮翻页，就算是原作者，恐怕时间一长也很难驾驭这个类，就不用说后来的维护者了。
更重要的是一个类，一个方法过长时，会严重阻碍你的扩展和修改，方法中每一个逻辑都牵扯到很多分散的上下文，会让修改和扩展异常困难。
按照《重构》所说，出现类过长的情况很多是职责不明确，一个类存在着几十个方法，那绝对是职责过多或职责不细分。
简单列一下针对又长又臭的重构处理：

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

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

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

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

文章插图
功能相同尽量抽象，不要发散式修改
举这次我们构建订单的一个例子，见下图：

文章插图
下单在后端使用了适配者的一个设计模式，主要是包装同一个接口对外暴露，然后根据情况(商品的逻辑)进行实现类的分离。
把逻辑统一并包装成统一接口对外暴露这个本意是良好的，但是在这里例子中，只在意了商品逻辑的分离，而忽略了，其实逻辑，例如库存，支付，优惠券等逻辑其实是统一的，是可以被抽象的。
导致的结果是例如需要修改优惠券逻辑式，需要同时进行三次几乎一模一样的修改。
可以从上图看出来，过早的使用适配模式，将业务在入口处进行分离，导致了后续其实相同逻辑的业务代码也进行了分离，本来 “扣库存” “扣优惠券” “支付”等逻辑应该是一样，但也使用了三套代码进行维护。
微服务编码问题
RPC 接口必须是业务职责
RPC 接口是微服务的生产者提供一定的能力给到消费者进行使用，这个时候的 RPC 接口千万不要定义大而全的接口。
之前就发现有部分同学把 RPC 接口定义成：
insertXXXupdateXXXlistXXX 这样无异于把 DAO 层直接搬到了 RPC ，把整个 DAO 直接进行暴露，这样违背了微服务的接口调用原则， RPC 接口只提供最原子的功能，限制消费者在生产者定义好的业务中进行使用。
严禁循环调用 RPC 接口
与项目内编程不同的是，每个 RPC 接口的调用都会伴随着一次的网络开销，需要需要对一个接口进行反复请求，这个时候可以要求 RPC 接口的提供方另外提供一个可以批量的接口，将单次反复的请求变成一次请求，减少网络开销。