개발하는 햄팡이

[2025.05.28] TIL - Spring 프로젝트 - 일정 관리 앱 피드백 리뷰 본문

Diary/2025

[2025.05.28] TIL - Spring 프로젝트 - 일정 관리 앱 피드백 리뷰

hampangee 2025. 5. 28. 18:55

저번에 했던 프로젝트
https://github.com/GyeongSe99/Spring-Schedule

 

GitHub - GyeongSe99/Spring-Schedule: 내일배움캠프 Chapter4. 스프링 프로젝트 - 일정 관리 앱 만들기(JPA ver.)

내일배움캠프 Chapter4. 스프링 프로젝트 - 일정 관리 앱 만들기(JPA ver.). Contribute to GyeongSe99/Spring-Schedule development by creating an account on GitHub.

github.com

 


 

최근 진행한 개인 프로젝트 피드백이 왔다.

 

근데 내일배움캠프가 진짜 괜찮다는 생각이 든데 나는 극I로 찾아가서 질문하는것을 잘 못하는데 과제 제출하면 이후 엄청 세세하게 피드백 해주시는게 너무 좋은 것 같다.

 

이 피드백 내용을 잊어버리고 싶지 않아서 맨 처음 받았던 피드백부터 하나둘 정리해보려고 한다.


1. List에서 맨 앞의 값 삭제 시 removeFirst() 사용

예전에 계산기 프로젝트를 했을 때 결과 값을 List에 담아서 관리했는데

이때 맨 처음 결과를 삭제할때 result.remove(0)으로 작성했었다. 코딩테스트를 하다보면 발생하는 문제..

이때 removeFirst() 메소드를 사용하는게 더 가독성이 좋을 것 같다고 하셨는데 아차 했다.

 

2. 사용하지 않는 메소드 삭제

나는 메소드를 만들때 뭔가 나중에 필요할 것 같아.. 라는 생각이 드는 메소드를 일단 만들어놓고 보는 성격이 있다..

준비성이 철저한건지..... 사실 사용하지 않는 메소드는 올리지 않는 것이 좋다고 알고는 있었지만

뭔가 사용할 것 같아서 또 올렸다.. ^ㅡ^

개인 과제라서 그냥 넘어가긴 했는데 팀프로젝트 할 땐 주의해야겠다.

 

그래도 누군가 이런 코드를 봤을떼 미래의 누군가를 위한 배려라고 생각해주면 좋겠다.

 

3. SRP는 꼭 지키려고 노력하기!

사실 이건 내가 SOLID를 모르는 시절 작성한 코드였다.

단일 책임 원칙이라는 말은 알았지만 책임이 뭔지 정확히 몰랐고, 그냥 뭔가 이정조면 괜찮겠지 했는데

이 클래스는 이런 역할을 하는 애라고 정했으면 그 기능이 아닌 경우에는 가차없이 다른 클래스로 분리해야된다는 것을 몰랐다.

이걸 알고 나서 과거 나의 코드를 보니 해당 원칙을 안 지킨 부분이 좀 많았다는 것.....

 

뭐 이제라도 알았으니 됐다 ㅎ.ㅎ

정보처리기사랑 면접 준비하면서 슬슬 CS를 공부하고 있는데 이런 코드 짜는 부분에서 새롭게 알게되는 것들이 많다.

그래서 CS를 중요하게 보나보다

 

4. common > entity 패키지에 Entity 모아놓기

이건 항상 이렇게 하고 싶었는데 이렇게 해도 되나 싶어서 못했던 방법.

그런데 피드백에서 해당 방법이 msa로 분리시 모듈을 나누기 수월해서 좋다는 피드백이 있었다.

User Entity를 Auth에서도 사용하고 User에서도 사용하다보니 얘가 어디에 위치하는게 올바른 것인가 항상 고민했었다.

그래서 그냥 공통으로 빼고 싶었는데 그렇게 못했었는데

모듈 분리 시 좋다는 점을 알게되었다.

 

5. getSchedulesByUpdatedAtAndWriterId 메서드의 경우 그냥 getScheduleList로 두기

이건 뭔가 의미를 명확하게 하고 싶어서 이렇게 했는데 사실 쓰면서도 너무 길어서 이게 맞나 싶긴했다.

그런데 getScheduleList는 너무 두루뭉술 한 것 같아서 고민이었는데 나중에 다른 조건이 추가될 경우 새로운 메소드를 만드는 것이 아니라 List를 반환하는 메소드에 조건을 추가하는 형태로 기능 구현이 되기 때문에 getScheduleList로 하는 것이 더 좋다고 한다.

 

6. Mapper클래스 사용 or Dto 및에 변환 메소드 생성

저번 일정 관리 어플리케이션 프로젝트에서 변환하는 로직이 너무 길어져 보기싫어서 Mapper클래스로 따로 분리했었다.

왜냐하면 나는 원래 @MapStruct를 사용해서 자동 mapper를 사용하는게 익숙했어서 그랬는데,

취향차이이긴 하지만 나중에 Dto가 엄청나게 다양해질 경우

Mapper클래스 내부 코드도 엄청 길어지고

그러면 어떤 메소드를 사용하는게 적절한지 찾기가 힘들어진다고 한다.

 

진짜 취향차이이긴 하지만 이렇게 명확한 장단점을 들으니깐 또 Dto 밑에 만드는게 좋은 것 같기도!

그래서 나도 이제부터 이렇게 하기로 마음먹었다.

 

 


 

일단 생각나는게 이 정도라서 여기까지 써야지

 

내일배움캠프가 진짜 좋은게

튜터님들한테 질문하러가면 너무 명확하게 설명해주는 부분들이 많아서 좋다
학생들을 많이 만나서 그런가?

우리가 어떤 것을 어려워하고 어떤 것을 잘 모르고 어떤 것을 원하는지 다 아시는 것 같다.

 

덕분에 진짜 예전보다 더 빠르게 성장하는 느낌...

새로운걸 알아가고 그걸 뭔가 만드는 것에 적용한다는게 재미있는 것 같다 ^ㅡ^

 

그리고 위의 프로젝트는 ReadMe를 안 썼지만 이런 문서 같은 부분에서도 뭘 명확하게 작성해야하는지

알려주시는것도 너무 좋은 것 같다.

그리고 그 프로젝트에서 나올 수 있는 면접 질문도 해주시는데

진짜 취업 준비에 엄청 많이 도움이 된다...

 

 

 

광고비 안받았고 진심이다..