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 等工具均可以發現代碼中的問題，爭取從業務級別的代碼向系統級別的代碼進化。 從團隊角度，在牛逼的管理方法都不如你們都積極的去促進系統的優化發展。惟心的一句話，「隊伍不是靠管起來的，而是心往一處看，勁往一處使」。