Dev 일기장

# 개요

학원 다니면서 개인 프로젝트로 플래너 개발을 해보기로 했다.

처음에는 학원에서 배운 내용 + 내가 알고 있었는데 잊었던 것들 + 이번 개인 프로젝트로 새로 배우고 싶었던 것들 세 가지를 적절히 섞어 구현할 예정이다.

설계 했던 테이블을 기반으로 DAO 클래스를 작성했다.

# 테이블 - VO 매핑

VO 클래스 작성을 위해 회의를 다시 진행했다. 그 때 각 테이블에 당장 사용하지 않은 속성이 많기 때문에 일단은 최소한으로 테이블을 설계하고 이후에 수정하는 방식으로 가자고 강하게 어필했다. 팀원들은 잘 이해하지 못했지만 일단 따르기로 했던것 같다. 

테이블에 따라 각자 VO 클래스들을 작성했다. 각자 작성한 VO클래스를 보며 리뷰하고 리팩토링하여 최종본을 확정짓기로 했다.

사실 VO 클래스라 리팩토링 할 것은 없었다.

# DAO클래스 작성 (CRUD)

각 Plan, User, DetailPlan에 따른 DAO 클래스 그리고 그 중 가장 기본적인 CRUD메서드는 수업시간에 다 배웠다고 생각해서 각자 하나씩 맡아서 작성해보기로 했다.

내가 User 객체를 맡고, 두명씩 짝지어서 Plan과 DetailPlan을 맡아서 작성하기로 했는데, DetailPlan 작성하기로 한 두 명 중 한 명은 나가고 한 명은 잘 따라오질 못해서 일단 User와 Plan 객체만 작성됐다.

내가 작성한 UserDao이고 Create, Read (One/All) 메서드 밖에 없는데, 이것을 참고해서 작성하라고 했다.

# DAO 클래스 리팩토링

내가 작성한 UserDAO와 팀원들이 작성한 PlanDAO 클래스를 책(자바 웹 프로그래밍 Next Step)을 참고하여 리팩토링을 진행했다. DetailPlan까지 작성 후 할까 리팩토링을 진행할까 생각했지만, 먼저 리팩토링을 하면 그 구조에 맞게 DetailPlan도 작성하는게 더 편할 것 같고 코드 리뷰할 때 클린코드, 리팩토링 관련 설명을 해주고 싶어서 회의 전에 미리 했다.

## JDBC Template 리팩토링

1. 기존의 JdbcTemplate에서 DB와 연결하는 클래스를 작성했었는데, 이를 ConnectionManager로 옮겼다.
2. DAO 클래스를 잘 보면 각 메서드마다 공통적으로 작성되는 부분과 메서드마다 다르게 작성되는 부분이 있다.
   • 쿼리를 작성하고 그 쿼리에 맞게 변수들을 setting하는 부분은 메서드마다 다르게 작성되는 부분이다.
   • ConnectionManager를 통해 Connection 인스턴스를 가져오고 그 Connection 인스턴스를 통해 Statement 인스턴스를 가져오고 Statement의 executeUpdate()나 executeQuery()를 호출하는 부분은 공통적으로 작성되는 부분이다.
   • 이에 따라 JdbcTemplate에 INSERT, UPDATE, DELETE 쿼리를 담당하는 executeUpdate() 메서드와 SELECT 쿼리를 담당하는 executeQuery(), executeQueryForOne()을 작성했다.

3. SQLException 대신 RuntimeException을 상속받는 DataAccessException을 추가했다.

## UserDAO, PlanDAO 리팩토링

DAO의 CRUD 메서드들을 위에서 리팩토링한 JdbcTemplate을 사용하는 것으로 리팩토링했다.

# 코드 리뷰

내가 리팩토링한 코드를 토대로 코드 리뷰를 진행했다...만 다들 잘 이해를 못했던것 같다. 제네릭을 사용한 것, ResultMap을 이용해서 테이블 → VO로 파싱하는 부분을 RowMap이라는 인터페이스를 통해 해결한 것 등 어려워 했다. 그래서 "나중에 더 배우게 되면 이해할 수 있으니 지금은 테스트 코드와 리팩토링을 통해 이런식으로 더 깔끔하게 코드를 작성할 수 있고, 이전 코드보다 가독성이 더 좋아졌다고 느낀다면 오케이다." 라고 설명했다.

내가 팀원들보다 쪼오오오오금 더 안다고 "내가 작성한 코드가 옳다." 라고 설명하고 싶진 않았는데, 설명하다보니 그렇게 된 것 같아 아쉬웠다;

# DetailPlan VO, DAO 클래스 작성

리팩토링하여 구조화 된 DAO 클래스에 따라 DetailPlan에 대한 VO, DAO 클래스도 쉽게 작성할 수 있었다.

커밋 메시지 잘못 작성함...

# 간단 회고

지금 블로그 글을 작성하면서 가장 크게 후회하는 것은 역시 commit 메시지 관련이다.

• 팀원들이 git, github의 기본 flow? (코드 작성 → git add → git commit으로 커밋 메시지 작성 → git push로 remote에 push)도 이해하기 어려워 했어서 branch를 구분하여 작업하고 PR을 통해 Merge하는 방식을 알려주면 과부하가 올 것 같았다.
• 그래서 organization에 Repo를 하나 생성하고 각 개인 Repo로 fork하게 했고, fork한 Repo에서 작업 후 push하여 main 브랜치에서 main 브랜치로의 PR을 하도록 했다.
• 문제는 팀원들이 commit 메시지를 전혀 작성하지 않아서 팀장인 나의 입장에서는 이해하기가 매우 어려웠다. 그렇다고 팀원들한테 "commit 메시지 다시 작성해서 PR 주세요"라고 하기에도 좀 그래서 그냥 '내가 감수하자'라는 마인드로 일일이 다 보기로 했다.
• 지금 시간이 지나고 나서 커밋들을 보는데 가관이다 ㅋㅋ... 물론 나도 이상하게 작성한게 많긴 하다. 다음 파이널 프로젝트 때는 이런것을 미리 정하고 하는게 나을 것 같다..