클린코드와 관심사의 분리

이번 프로젝트를 할 때 이전의 3개의 프로젝트를 보며 느낀점이 있다.

 

코드가 복잡하고 내가 다시 봐도 이해가 잘 안되는 것이었다.

코드의 중복이 굉장히 많았으며 관심사의 분리도 잘 이루어지지 않아서 service 계층에서 있어야 하는 비즈니스 로직이 컨트롤러에 있는 등 코드도 알아보기 힘들었으며 관심사의 분리도 잘 이루어지지 않았다.

 

 

 

나날이 코드

@GetMapping
public GarmentResponseDto Garment(@RequestParam Double temp, @RequestParam Double uv,
                                  @RequestParam Double rain, @RequestParam Sex sex) {
    List<Garment> outers = garmentService.findOuters(temp, uv, rain, sex);
    List<Garment> tops = garmentService.findTops(temp, uv, rain, sex);
    List<Garment> pants = garmentService.findPants(temp, uv, rain, sex);
    List<Garment> shoes = garmentService.findShoes(temp, uv, rain, sex);

    List<GarmentDto> outerList = outers.stream()
            .map(o -> GarmentDto.convert(o)).collect(Collectors.toList());

    List<GarmentDto> topList = tops.stream()
            .map(t -> GarmentDto.convert(t)).collect(Collectors.toList());

    List<GarmentDto> pantsList = pants.stream()
            .map(p -> GarmentDto.convert(p)).collect(Collectors.toList());

    List<GarmentDto> shoesList = shoes.stream()
            .map(s -> GarmentDto.convert(s)).collect(Collectors.toList());

    return new GarmentResponseDto(outerList, topList, pantsList, shoesList);
}

예를 들면 위와 같은 코드이다. temp, uv, rain, sex로 옷들의 리스트를 조회하는 과정과 stream().map으로 dto로 변환시키는 과정은 service 계층에서 이루어져야 하는 과정이다. 하지만, 컨트롤러에서 이루어졌으며 다른 로직에서도 이와 비슷한 경우가 많았고, 중복된 코드도 종종 있어서 클린 코드와 관심사의 분리를 고려하여 '법잘알' 프로젝트를 진행했다.

 

 

 

SuggestionController

@GetMapping("/list")
public ResponseEntity<List<SuggestionListResponse>> suggestionList(
        @AuthenticationPrincipal PrincipalDetails principal,
        @RequestParam(name = "category", required = false, value = "category") String category,
        @RequestParam(name = "likeCount", required = false) Boolean likeCount) {

    List<SuggestionListResponse> allSuggestion = suggestionService.findAllSuggestion(category, likeCount, principal.getUser());
    return ResponseEntity.ok(allSuggestion);
}

 

 

 

SuggestionService

public List<SuggestionListResponse> findAllSuggestion(String reqCategory, Boolean likeCount, User user) {
    Category category;
    if (reqCategory != null) category = Category.categoryConverter(reqCategory);
    else category = null;

    List<Suggestion> suggestionList = suggestionRepository.findAllSuggestion(category, likeCount);

    List<Long> userLikeSuggestions = suggestionUserLikes(suggestionList, user);

    return suggestionList.stream()
            .map(suggestion -> SuggestionListResponse.convert(suggestion, userLikeSuggestions))
            .collect(Collectors.toList());
}

 

 

위와 같이 컨트롤러 계층에서는 프론트엔드로부터의 요청을 받고 service 계층의 로직을 실행시키는 코드만 존재한다.

service 계층에서는 예외처리, dto 변환, db 조회 등 비즈니스 로직의 코드들이 존재한다.

 

이 포스팅을 쓰게 된 이유는 '나날이' 프로젝트는 작년 11월에 한 프로젝트로 최근에 진행한 프로젝트인데, 얼마 전에 다시 봤을 때 조차 코드가 너무 정리가 안 되어있고 내가 봐도 이해하기 힘들었기 때문이다.

 

 

 

 

나중에 취직해서 프로젝트를 진행할 때 나 혼자 진행하는 경우는 거의 없고, 백엔드 개발자도 여러명이 존재한다. 그런데 이렇게 클린 코드를 신경쓰지 않고 동작만 한다면 ok 라는 마음으로 코드를 짜면 나중에 에러가 나거나 다른 사람이 내 코드를 수정할 때 엄청 힘들 것이다.

 

클린 코드와 관심사의 분리를 신경써서 설계를 한다면 한 눈에 파악하기도 쉽고, 어떤 로직에서 무슨 역할을 담당하며 어떤 기능을 하고 싶은지 한 눈에 파악이 되어서 나에게도, 동료 개발자에게도 도움이 된다.

 

단순히 기능을 모두 구현하는 개발자보다 협업 능력과 이런 세부적인 것들까지 신경쓰는 개발자로 성장하고 싶다.

 

 

이전의 3개의 프로젝트에서 단순히 기능 구현만을 추구했던 것을 반성하고 앞으로는 똑같은 기능을 하더라도 좀 더 나은 설계 방법과 표현을 할 수 있는 개발자가 될 것이다.