일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 혼공파
- java
- 자료구조
- Kotlin
- SQL
- 정보처리기사
- 기술면접
- 티스토리챌린지
- groupby
- 안드로이드스튜디오
- MySQL
- CS
- Android
- Til
- 카카오코테
- 프로그래머스
- doitandroid
- 인프런
- 코틀린
- select
- join
- 안드로이드
- 혼공챌린지
- 코테
- 혼공단
- 오블완
- 스터디
- 자바
- 알고리즘
- 정처기
- Today
- Total
Welcome! Everything is fine.
프로젝트를 시작할 때 생각해볼 것들 💭 본문
이번 프로젝트를 끝내고, 지난 프로젝트에서 아쉬웠던 점을 정리해봤다.🖋️
그런 점을 이번 프로젝트에서 꽤 많이 개선한 것 같고,
이번 프로젝트에서의 아쉬운 점 역시 다음 프로젝트에서 개선할 수 있다면 좋을 것 같다!
팀원들과 사소한 것 하나까지 공유하자
지난 프로젝트에서는 git에 익숙하지 않은 팀원분들이 많았다. 그래서인지 사실 내가 맡은 기능을 개발하는 시간보다 git 관련 문제를 해결하는데 더 많은 시간을 쓴 것 같다. 우리팀에서 일어난 문제는 다음과 같았다.
- merge가 되면 develop에서 pull을 받은 후, 자신의 브랜치에서 작업을 해야한다. 그러나 중간에 확인해보니 팀원 모두가 pull을 받지 않고 작업을 하고 있다는 사실을 알았다. 자신의 브랜치에서는 자신이 맡은 기능만을 개발해야한다고 알고 있었던 것이다.
- 자신의 브랜치에서 develop 브랜치로 merge를 해야하는데, 다른 팀원이 실수로 main 브랜치로 PR을 한 후 합쳐버렸다. 이런 상황을 미리 막기 위해 아예 develop 브랜치를 default 브랜치로 정했어야 했는데 아쉬운 부분이다.
- PR 제목 컨벤션이나 내용 템플릿을 정하지 않아 통일성이 없는 PR들이 생겨나서 신경쓰였다.
- 커밋 메세지가 깨져서 알아보기 힘든 경우가 많았다. 보통 터미널에서 커밋 메세지를 작성하면 그런 문제가 생기는 것 같다. 나는 주로 커밋 메세지는 인텔리제이가 제공하는 창을 이용해 적어서 몰랐다. 지금 찾아보니 인코딩 세팅을 변경 해주면 해결되는 것 같다.
내가 알고 있는 내용이더라도 다른 사람은 모를 수 있고, 혹은 다른 스타일을 가지고 있을 수 있기 때문에 정말 사소한 부분까지도 공유하고 이야기를 나눠보는 것이 중요하다고 느꼈다.
공통으로 사용되는 파일을 잘 관리하자
프로젝트 내에서 거의 모든 도메인에서 사용되는 예외 처리나 리소스 패키지 안에 있는 파일 등을 잘 관리해야겠다고 느꼈다. 같은 기능을 파일이 여러 개 올라오거나, 올라오지 말아야 할 파일이 올라왔기 때문이다. 특히 application.properties와 같은 설정 파일은 .env 파일을 만들어 환경 변수를 관리하는 작업이 필요하다. 또한 공용으로 사용되는 파일은 미리 global(혹은 common) 패키지를 만들어 한 사람이 작성해 올리도록 하는 게 낫지 않을까 싶다.
commit & code convention을 자세히 정해놓자
간단한 커밋 컨벤션만 정하고 프로젝트에 들어갔기 때문에 통일성이 없는 부분이 상당히 많았다. 이건 발표 때 튜터님이 다른 팀에 지적한 내용인데, 우리팀에도 해당된다고 생각했다. 미리 파일명, 메서드명, 변수명 컨벤션을 정하고 시작했다면 좋았을 것 같다. 예를들어 어떤 조회 메서드의 이름을 findXXX(), getXXX() 둘 중 어떤 것을 쓸지, 각 엔티티에서 변수명은 어떤 식으로 쓸지 등을 정해놓으면 좋을 것 같다.
주석은 필요한 내용만 적자
아주 긴 주석을 마주하면 읽을 용기가 없어진다. 내가 생각하는 좋은 코드는 주석 없이도 잘 이해되는 코드지만, 주석을 달아야 한다면 정말 필요한 부분 한 두줄만 있으면 될 것 같다.
코드 리뷰를 하자
남이 쓴 코드를 읽는 건 정말 피곤한 일이다. 하지만 코드를 읽고, 이해하고, 잘못된 점이 있는지 검토하고, 리뷰를 달기 전 내가 알고 있는 지식이 맞는지 다시 한 번 검색하는 작업은 나를 더 성장시킨다. 지난 프로젝트에서 코드 리뷰를 하고 싶었지만 시간에 쫓기듯 개발해서 하지 못했다. 하지만 코드 리뷰를 했다면 다들 더 좋은 코드를 작성할 수 있는 힘을 기를 수 있지 않았을까? 이번 프로젝트에서 코드 리뷰를 하면서 코드 리뷰의 중요성을 다시 한 번 깨달았다. 그리고 스스로 실력이 부족하다는 생각에 코드리뷰를 잘 하지 않는 경우가 있는데, 오히려 다른 사람들의 코드를 보먀 왜 이렇게 짰는지 의견을 나눠보고 새로 알게 된 점을 따로 공부해보면 더 실력이 좋아질 것이다.
튜터님께 자세히 피드백 받자
여기서 말하는 자세한 피드백은 코드 리뷰를 말한다. API URL이나 진행 상황에 대한 피드백 이외에 핵심 기능에 대한 코드 리뷰를 받았다면 좋았을 것 같다. 이 부분은 이번 프로젝트 후 느낀 점이다. 이번 프로젝트에서 튜터님의 상세한 코드 리뷰를 듣고 어떤 방향으로 리팩토링 해볼 수 있을지에 대한 힌트를 얻었기 때문이다.
'TIL' 카테고리의 다른 글
[Spring] Spring Security 도입 후 NullPointException 해결(@AuthenticationPrincipal) (3) | 2025.03.14 |
---|---|
[Spring] application.yml에 시크릿 키 넣지 말아주세요...(.env 파일 만들고 설정하기) (0) | 2025.03.10 |
[Spring] enum abstract method로 중복을 해결해보자 (0) | 2025.03.07 |
[Spring] JWT 시크릿 키 설정 및 문제 해결 / -hex 64 vs -base64 32 차이 (0) | 2025.02.27 |
[Spring] @EntityGraph로 N+1문제 해결하기 (0) | 2025.02.26 |