프로젝트 코드 리팩토링 후기

개요

프로젝트를 진행하면서 이전 개발자들이 작성했던 코드를 이어 작성해야 하는 일이 생겼습니다. 실제로 취직하면 이전에 작성된 코드를 수정하는 일이 많으니, 좋은 경험이 될것이라 생각했습니다.

다만 코드를 보니 MVC 패턴의 계층이 모호한 코드와 비효율적인 코드가 많이 보였었습니다. 또한 로직 상 잘못된 것도 있었으며, 가독성이 나쁜 코드도 있었습니다.

제가 생각하는 좋은 코드는 다음과 같습니다.

• 메서드 명과 파라미터 이름으로 해당 메서드의 로직을 쉽게 이해할 수 있는 코드
• 단일 책임을 갖고 있는 메서드
• 계층에 따라 정리된 책임
• 중복되지 않으며 확장성과 가독성 좋은 코드
• 한 줄의 주석보단 좋은 메서드 명

Controller 리팩토링

위의 코드는 리팩토링 전 코드입니다. Controller 계층에서는 사용자에 요청을 받아 적절한 비즈니스 로직과 연결해 주어야 하지만, 비즈니스 계층에 작성되어야 할 로직들이 컨트롤러에 적혀있습니다.

문제점

• 비즈니스 로직이 Controller에 작성 됨
• MVC 계층에 위배
• 중복되는 코드가 많아 재사용성과 확장성에 비효율적이며 가독성 저하
• Rest API Method 의 잘못된 사용

따라서 위의 문제점을 찾아내고 다음과 같은 코드로 변경했습니다.

해결 방법

• 중복되는 로직은 하나의 메서드로 병합
• 비즈니스 로직은 단일 책임의 원칙하에 service 계층으로 이동
• PATCH 와 PUT 의 차이를 구분

위와 같은 방법으로 코드가 간결해지고 , 중복됐던 비즈니스 로직을 제거하고 단일 책임으로 묶음으로 써 확장성과 유지 보수가 용이해지고 코드의 가독성이 좋아졌습니다.

Service 리팩토링

• 서비스 계층에 존재하는 메서드 들
  

처음 리팩토링 할 때 해당 서비스 계층을 이해하는데 시간이 걸렸습니다. 그 이유는 다음과 같습니다.

문제점

• 오버로딩된 메서드간의 다른 로직
• 모호한 메서드 명이 많아 각 메서드를 이해하기 위해 코드를 분석
• 비슷한 메서드 명인데 다른 로직으로 인해 발생한 모순
• 코드 블록들이 뭉쳐있어 가독성 저하
• 중복되는 메서드 발생
• 메서드의 파라미터 변수 명이 어려우며 , 요구되는 데이터가 많음
• 확장성과 유지보수에 용이하지 않음

위의 문제점을 파악하고 다음과 같이 리팩토링을 진행했습니다.

- 리팩토링으로 인해 간소화된 메서드

해결 방법

• 확장성을 고려해 중복되거나 비슷한 로직은 하나의 메서드로 병합
• 많은 파라미터 변수가 필요할 때는 메서드를 분할
• 단일 책임이라도 다른 로직끼리 코드를 분리 ( 문단 처럼 )

어렵지 않은 방법으로 복잡한 8개의 메서드들을 4개의 메서드들로 간소화한것을 볼 수 있습니다. 또한 각각의 메서드 명만 보더라도 쉽게 이해할 수 있으며 추후 확장하거나 다른사람이 리팩토링할 때 쉽게 이해할 수 있는 코드가 되었습니다.

Security Config 파일

코드가 길어 두 개의 이미지로 나눴는데, 이미지만 보더라도 코드가 복잡해 보이는걸 볼 수 있습니다.

문제점

• 인수에 인스턴스된 객체를 바로 전달함으로써 많은 들여쓰기로 인해 가독성 저하
• 분리되지 않은 로직으로 인해 낮은 가독성과 효율적이지 않은 코드
• 로직 사이의 주석으로 인해 가독성이 나빠진 코드

위의 문제점을 파악하여 다음과 같이 리팩토링을 하였습니다.

해결 방법

• Spring Security 에서 제공하는 메서드를 활용
• 가독성을 저하시키는 메서드를 별개의 클래스로 분리
• 주석 제거

위의 세 가지를 활용하여 몇백줄이 넘었던 Security 파일을 단 50줄로 정리할 수 있으며 , 뿐만 아니라 코드의 가독성으 높일 수 있었습니다.

정리

진행되던 프로젝트 중간에 투입된 적은 처음이였으며, 리팩토링을 진행하여 코드를 개선하는 좋은 경험이 된 것 같았습니다.

위에 소개된 코드는 일부이며 수정된 로직은 더 많았으며, 수정된 사항은 비슷했기에 중요하다 생각했던 부분만 소개했습니다.