JAVA编码中养成的坏习惯

在设计及开发中，一般会因为各类缘由，导致代码设计和开发中的无序。这里简单说一下碰到的几种简单状况。

1. 服务调用写到了循环中

public List<MemberDetailDto> queryMembers(List<String> memberIds) {
        return memberIds.stream().map(memberId -> {
            MemberDetailDto memberDetailDto = memberService.queryOneMember(memberId);
            // ...
            return memberDetailDto;
        }).collect(Collectors.toList());
    }
复制代码

以上这种写法并不算好，容易致使后续的性能问题，甚至若是后期在维护中，queryOneMember方法操做复杂话，可能致使各类异常问题发生。固然若是业务中 memberIds 的量是可控的，通常不会产生发生问题。

final String tenantId = "传入参数";
List<CardInfoDto> data = mbrMemberCards.stream().filter(Objects::nonNull).map(mbrMemberCard -> {
    CardInfoDto cardInfoDto = MbrMemberCardMapper.INSTANCE.mapToCardInfoDto(mbrMemberCard);
    TenantDto tenantDto = tenTenantApi.findOneTenant(tenantId);
    cardInfoDto.setLogo(tenantDto.getLogo());
    return cardInfoDto;
}).collect(Collectors.toList());
复制代码

而若是是上面这种写法，那么就有点蠢了。TenantDto tenantDto = tenTenantApi.findOneTenant(tenantId); 这个在循环中每次都会调用，是没有意义的，能够在循环中调用一次便可。

经过代码历史查到，这些是同一我的写的。这就是一种代码编写的习惯，若是养成了在循环中调用服务的习惯，那么能够预见垃圾代码的成片出现。

2.服务领域划分不清楚

一样一个例子。

final String tenantId = "传入参数";
List<CardInfoDto> data = mbrMemberCards.stream().filter(Objects::nonNull).map(mbrMemberCard -> {
    CardInfoDto cardInfoDto = MbrMemberCardMapper.INSTANCE.mapToCardInfoDto(mbrMemberCard);
    TenantDto tenantDto = tenTenantApi.findOneTenant(tenantId);
    cardInfoDto.setLogo(tenantDto.getLogo()); //商户Logo
    return cardInfoDto;
}).collect(Collectors.toList());
复制代码

咱们能够猜想出，此代码片断是用于查询会员卡列表的，那么为何在循环中存在代码 cardInfoDto.setLogo(tenantDto.getLogo()); //商户Logo，这样代码是用来增长字段“商户Logo”。从领域模型来看， “商户Logo”与“会员卡”没有直接从属关系，那么为何会如此去设计呢？

经过GIT的提交历史中，我看到此“商户Logo”字段是后来增长的，为了在客户端展现会员卡的归属商户的Logo。根据业务上，每一个商户的客户端都是隔离的，并且在客户端启动时也初始化了商户的基本信息，可是因为Logo字段是后续增长的，而没有初始化到客户端，才致使客户端中须要展现“商户Logo”时就找不到了。

然后续的开发人员为了解决一时的须要，就采起了“你啥时候要这个字段，我就给你在接口中增长这个字段”这种设计心理。

最后致使，客户端作接口对接时，在文档里寻找须要的字段。一个反人类的服务诞生了。咱们JAVA开发工程师常常被问这样一类问题“商户Logo不该个在查询商户信息的接口中吗？”

3.不遵循设计原则，协做中的混乱

一个敏捷的团队仍是比较注重沟通和协做的，可是团队中总会发生意想不到的事情。

例如，相似功能的接口在系统中存在多个。今张三添加一个查询商户的接口，明天李四增长一个查询商户的接口，致使在系统层面的混乱。特别是目前的微服务架构。

致使混乱的根本缘由，仍是没有遵循设计原则。简单的说，手机客户端须要一个查询商户的接口，张三认领了此功能的开发，而后完成。后来，需求发生了变化，WEB客户端须要在商户信息中增长商户下的渠道信息，李四认领了这个功能的开发，而后李四从新写了一个查询商户信息的接口也提交测试了。

因而，后台服务的接口愈来愈多，系统间交互也愈来愈复杂。此时，已经没有人可以阻止系统继续混乱下去了。

以上只是简单的举个例子，从我的到团队总会存在各类各样的问题。从我的角度出发，编码算是技术活，每一个人的习惯可能不同，可是尽可能培养好的习惯，checkstyle、findbug 等工具均可以发现代码中的问题，争取从业务级别的代码向系统级别的代码进化。 从团队角度，在牛逼的管理方法都不如你们都积极的去促进系统的优化发展。惟心的一句话，“队伍不是靠管起来的，而是心往一处看，劲往一处使”。