💁🏻 2024년, 나는 어떤 코딩을 했을까?
24년도에 대한 회고?
24년 회고라기엔 벌써 25년 3월의 중반부를 향해 달려가고 있기에 지난 해에 대한 반성, 그로 비롯된 개선점 찾기 정도로 해야겠다.
24년은 나에게 참 많은 변화가 있었다.
특히나 내가 가진 직업에 대한 시각과 마음가짐이 많이 달라졌다.
단순히 업무를 처리하기 위해 코드만 작성하다가 훗날 내 코드를 보게 될 개발자들을 위해 깊이있는 고민을 하기 시작했다.
또한 새로운 기술과 개발 용어에 더욱 관심을 가지게 되었고 이제서야 진정한 개발자의 마인드셋을 가진 것 같았다.
때문에 새로운 코드를 작성하는 것도 중요하지만, 지난 내 코드를 다시 뜯어보고 알게모르게 있던 내 좋지 않은 습관들을 고쳐나가고자 한다.
내가 하던 코딩 방식
평소에 일단 하자라는 마인드로 살았다. 코드를 일단 써 내려간 다음 기능이 완성되고나면 놓아버리곤 했다. 실무를 바쁘게 하는 개발자들은 모두 공감하겠지만 하나 처리하고나면 또 다른 일이 뒤에 기다리기에 내 지난 코드를 돌아볼 여유가 부족하다ㅠㅠ
작년에 Java 개발자로 전향하겠다는 원대한 목표를 세운 후 부트캠프를 통한 코드를 작성하면서 그 주의 과제를 일주일 내내 밤을 새서 완성하고 나면 진이 빠져버려 내가 짠 코드가 맘껏 휘갈겨 져 있는 것도 모른채 그냥 넘어가버리곤했다.
➡️ 아무튼 고쳐야 할 코드가 너무너무 많단 의미
💻 어떤 방향으로 리팩토링을 할까?
👩🏻🍳 내가 요리하게 될 코드
작년에 생성한 프로젝트 중 어떤걸 가장 먼저 리팩토링할까 고민해보았다.
내 아픈손가락 같은 존재인 수강신청 프로젝트를 변경해 보려고한다.
클린아키텍처를 처음 적용해 본 프로젝트라 폴더 구조부터 어떻게 잡아야할지 몰랐고 매일 새벽 지피티를 부여잡고 엉엉 울며 정말 열심히 작성했으나 Entity를 Controller에서 불러오는 실수(피드백 받고도 왜 fail인지 몰랐음)를 하며 fail을 받았던.. 내 프로젝트..
🚫 수강신청 프로젝트의 문제점
1. Clean Architecture & REST API에 대한 이해가 부족한 상태로 작성됨.
/**생략**/
import org.springframework.web.bind.annotation.*;
import java.util.List;
/**생략**/
@RequestMapping("/lecture")
public class LectureController {
private final LectureApplyService lectureApplyService;
private final LectureService lectureService;
private final LectureHistoryService lectureHistoryService;
//특강 신청 API
@PostMapping("/apply")
public ResponseEntity<String> applyLecture(@RequestBody LectureApplyDTO lectureApplyDTO) {
/*메서드 내용 생략 */
}
//신청 가능 리스트 조회API
@GetMapping("/list")
public ResponseEntity<List<Lecture>> getAvailableLectures(@ModelAttribute @Valid LectureCommand.Date command) {
/*메서드 내용 생략 */
}
//신청 완료 목록 조회 API
@GetMapping("/{studentId}/list")
public ResponseEntity<List<LectureHistory>> getLectureApplicationHistory(@PathVariable Long studentId) {
/*메서드 내용 생략 */
}
}
▶️ '*' 사용은 지양해야한다.
▶️ REST API 위반 사항(End Point URL 수정 필요)
2. Command Pattern을 제대로 알지 못한 채로 사용함.
3. 사용하지 않는 코드(DTO, 중복된 코드 등)이 많음.
4. 작성 시 가독성을 고려하지 않음.
▶️ JPQL 작성 시 쿼리가 긴데도 한줄로 작성했다.
▶️ 어떤건 한줄로, 어떤건 줄바꿈으로 개행문자를 열었다.
5. 불필요한 테스트 코드가 많음.
@Test
@DisplayName("🟢전체 특강 조회")
void getAvailableLectures_SUCCESS_ALL() {
Lecture mockLecture3;
Lecture mockLecture4;
mockLecture3 = new Lecture().builder().lectureNm("특강3").capacity(30L).enrollStartDate(LocalDate.parse("2024-10-01", DateTimeFormatter.ISO_DATE)).build();
mockLecture4 = new Lecture().builder().lectureNm("특강4").capacity(25L).enrollStartDate(LocalDate.parse("2024-10-02", DateTimeFormatter.ISO_DATE)).build();
when(lectureJpaAdaptor.findAll()).thenReturn(Arrays.asList(mockLecture1, mockLecture2, mockLecture3, mockLecture4));
List<Lecture> Lectures = lectureJpaAdaptor.findAll();
assertNotNull(Lectures);
assertEquals(4, Lectures.size());
assertEquals("특강1", Lectures.get(0).getLectureNm());
assertEquals("특강2", Lectures.get(1).getLectureNm());
assertEquals("특강3", Lectures.get(2).getLectureNm());
assertEquals("특강4", Lectures.get(3).getLectureNm());
}▶️ 좀 더 깔끔한 테스트 코드를 작성할 수 있지 않았을까?
6. 성능 개선을 고려하지 않음.
... 등등 더 많지만 리팩토링 하는 과정에서 추가해 보고자 한다.
✅ 개선 포인트
RESTful하게 작성하기.- 계층분리를 정확하게 할 것.
- 네이밍 어색한 것 변경하기.
- 테스트 코드 점검(불필요한 테스트코드는 없는지 / 꼭 필요한 코드인데 누락하지는 않았는지)
- 기존 기능이 깨지지 않도록 작은 단위로 진행하기.
✅ 주요 리팩토링 기법
📍 메서드 추출 (Extract Method)
- 하나의 메서드가 너무 많은 일을 하고 있다면, 기능별로 분리
📍 중복 코드 제거
- 여러 곳에서 반복적으로 사용되는 로직을 유틸 클래스나 공통 서비스 계층으로 이동시키기.
📍 DTO 활용
- ⭐️ API 응답을 엔티티 그대로 반환하는 대신, DTO를 사용하여 계층 분리 강화시키기.
📍 Repository 쿼리 최적화
- N+1문제 해결, 불필요한
findAll()호출 제거, 페이징 적용 등
📍 예외처리 개선
- 일괄된
GlobalExceptionHandler도입 @ControllerAdvice활용
🔥 마무리
이렇게 정리해보니, 한 프로젝트만 훑어본 것인데도 정말 손볼 게 많다.
하지만 천천히 하나씩 개선하면서 더 좋은 개발자로 성장하는 과정이라고 생각하자.
2025년에는 더 깔끔한 코드와 함께 돌아볼 수 있길! 🚀
