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

举这次我们构建订单的一个例子，见下图：
文章插图
下单在后端使用了适配者的一个设计模式，主要是包装同一个接口对外暴露，然后根据情况(商品的逻辑)进行实现类的分离。
把逻辑统一并包装成统一接口对外暴露这个本意是良好的，但是在这里例子中，只在意了商品逻辑的分离，而忽略了，其实逻辑，例如库存，支付，优惠券等逻辑其实是统一的，是可以被抽象的。
导致的结果是例如需要修改优惠券逻辑式，需要同时进行三次几乎一模一样的修改。
可以从上图看出来，过早的使用适配模式，将业务在入口处进行分离，导致了后续其实相同逻辑的业务代码也进行了分离，本来 “扣库存” “扣优惠券” “支付”等逻辑应该是一样，但也使用了三套代码进行维护。
【新来的实习生竟然偷偷在代码里“下毒”......】微服务编码问题
RPC 接口必须是业务职责
RPC 接口是微服务的生产者提供一定的能力给到消费者进行使用，这个时候的 RPC 接口千万不要定义大而全的接口。
之前就发现有部分同学把 RPC 接口定义成：
insertXXXupdateXXXlistXXX 这样无异于把 DAO 层直接搬到了 RPC ，把整个 DAO 直接进行暴露，这样违背了微服务的接口调用原则， RPC 接口只提供最原子的功能，限制消费者在生产者定义好的业务中进行使用。
严禁循环调用 RPC 接口
与项目内编程不同的是，每个 RPC 接口的调用都会伴随着一次的网络开销，需要需要对一个接口进行反复请求，这个时候可以要求 RPC 接口的提供方另外提供一个可以批量的接口，将单次反复的请求变成一次请求，减少网络开销。
文章插图
使用工具辅助清理恶性代码
P3C 插件
在使用 Eclipse 或 idea 编程中，首推使用阿里的 P3C 插件进行辅助，代码规范检查插件 P3C ，是根据《阿里巴巴Java开发手册》转化而成的自动化插件。
文章插图
使用 Skywalking 找出恶性代码
与 P3C 直接辅助编码不同的是， Skywalking可以在生产环境中通过链路的跟踪确定某一个微服务的接口性能或调动出现异常。
这里不累赘介绍 Skywalking 的用处，其实链路跟踪不仅仅是运维或架构师应该关注的点，普通的开发者也可以借助链路跟踪去回溯自己的代码，站在一个高的角度在生产环境中审视代码在链路中表现。
善于使用链路跟踪往往可以发现在平时编码中被忽略的问题，例如，一次不经意的循环调用 RPC 很容易就造成超大的调用跨度，而往往在编程中开发者是未能及时感知的。
文章插图
小结
在分享的时候其实还讲了抽象的原则和一些设计模式的使用，这里就不累赘的复述了。
简单的说，要写出好的性能，可读性高，逻辑明了的代码，往往靠的不是一次一次的 CURD ，而是平时的总结和思考。
作者：陈于喆
简介：十余年的开发和架构经验，国内较早一批微服务开发实施者。曾任职国内互联网公司网易和唯品会高级研发工程师，后在创业公司担任技术总监/架构师。
编辑：陶家龙
征稿：有投稿、寻求报道意向技术人请联络 editor@51cto.com
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】