Photopic) 여기서 경험한 개발 문화
🔔 뽀또픽 개발 문화
이번 프로젝트를 하면서 가장 좋은 경험 중 하나가 개발 문화였다. 백엔드 개발자로서 같은 백엔드와, 다른 직군들과 소통을 할 때 어떤 용어를 사용하고 협업하는게 이전 직장에서는 경험하지 못했던 새로운 경험이었다.
이전 직장에서는 개발 용어집은 있었지만 제대로 적용하지 않은 부분이 많았고, 코드 리뷰가 없고 알아서 잘 했겠지 하는 마인드로 테스트는 작업한 사람만 했다. 그래서 나는 중요한 작업의 경우 내가 1차로 테스트 후 PR을 올릴 때, 전체 플로우랑 중요하게 봤으면 하는 부분들을 언급해서 요청했었다.
소통
개발 소통은 오프라인 회의가 아니라면 디스코드를 많이 이용했다. 기획자, 디자이너는 피그마에서 소통하긴 했지만 자세한 부분은 디스코드에서 얘기를 더 많이 했다. 아무래도 프론트, 백엔드 둘다 피그마가 어색하고 디스코드 화면 공유를 통해 피그마를 볼 수도 있어서 그런 것 같다.
컨벤션
코드 컨벤션은 구글 자바 컨벤션을 참고했는데 그대로 적용하지는 않고 우선 컨벤션에 맞춰서 개발하다가 불편하다고 느낀 부분은 서로 피드백하여 우리만의 룰을 적용했다. 커밋 컨벤션이나 이슈 템플릿 등은 우테코 저장소를 참고했다.
코드 컨벤션
- static import 허용
- 테스트 코드만 와일드 카드 허용
ApiResponse
- Error인 경우에는 {code, errorMsg}만
- success인 경우에는 전달할 값(id, name, …)만
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
//200
{
id: 1
name: hi
}
//200
{
id: 1
key: hi
}
//200 이외 400 ...
{
code: 1234
errorMsg: "MEMBER_NOT_FOUND"
}
이슈
1
2
3
4
5
## 📋 추가 기능
## 🛠️ 작업 내용
- [ ] [TODO1]
- [ ] [TODO2]
PR
1
2
3
4
5
## 🚀 작업 내용 설명
## 📢 그 외
## 📌 관련 이슈
테스트 코드
1
2
3
4
5
6
7
8
@DisplayName("사용자 정보 조회")
void select_member(){}
@DisplayName("사용자 정보 수정 - 유저 없는 경우")
void update_member_memberNotFoundException(){}
@DisplayName("토큰 생성")
void createToken_customException(){}
CI/CD 워크플로우
개인 프로젝트 할 때 직접 빌드하고 배포 서버에 파일을 옮기는 일은 정말 귀찮다. 지금에서 생각해보면 CI/CD를 왜 미리 구현 안했을까 라는 생각이 든다. 뽀또픽에서는 Github Actions를 이용하여 구축을 했다. 같은 팀원의 말로 본인은 Jenkins만 사용하고 Github Actions는 처음 써보는데 이게 더 편한 것 같다고 했다. 나는 아직 Jenkins를 안써봤지만 채용공고를 보면 Jenkins가 좀 더 많이 쓰이는 것 같다.
각자 역할이 있겠지만 차이를 간단히 확인해보니 Github Actions는 큰 프로젝트의 경우 비용이 많이 들어가고 Github에 상당히 의존적이다. 그래서 깃허브를 쓰거나 소~중규모 프로젝트의 경우에는 적합하지만 그렇지 않은 경우 Jenkins를 쓰는 것 같다. Jenkins가 오픈 소스인 것도 있고 설정이 복잡할 수는 있지만 그만큼 커스터마이징이 자유로워서 실무에서 더 사용되는 것 같다.
테스트 코드
이전 직장에서는 테스트 코드 작성 환경이 열악했다. 우선 테스트 프레임워크인 JUnit이나 Mockito가 없었고, 내부망을 사용하고 기존에 없던 의존성을 추가하는 것이 상당히 제한적이었다.
그래서 테스트 코드를 작성할 때 로컬 환경에서 최대한 use case들을 확인해야했다. 물론 환경 문제로 로컬/개발 환경에서 테스트가 불가능한 경우 어쩔 수 없이 스테이징 서버까지 코드를 올리면서 테스트를 했다.
이런 상황을 피하고자 이번 프로젝트에서 테스트 코드를 적용해보았다. 레포지토리, 서비스, 컨트롤러 단으로 각 단위테스트를 진행하면서 어떤 플로우로, 어떤 함수가 쓰이는지 알게 되는 경험이었다. 물론 아직 익숙하지 않지만 Mock을 만든다? 어떤 상황이 나타난다고 가정한다? 는 식의 테스트 방식이 굉장히 재밌었다.
후기
이번 활동에서 얻은 가장 좋은 경험이 개발 문화였다. 같은 직군의 팀원이 졸업 예정인 대학생이었는데 정말 많이 배웠다. 오히려 이 친구한테 내가 어떤 것을 알려줘야 서로 윈윈일지 걱정될 정도로 기술적인 부분을 많이 배웠다. 그리고 다른 직군 팀원들도 각자의 분야에서 전문성을 잘 보여줘서 개발하는 시간은 알찼다.
물론 처음부터 끝까지 어떤 불만이 없던 것은 아니지만 결과적으로 보면 필요한 부분에서 싸우고 조율해서 다같이 수료하는 결과를 얻은 것이라고 생각한다. 덕분에 생각하는 범위가 넓어지고 백엔드에서는 어떤 것들이 더 있고, 다른 직군 관점에서는 어떻게 생각할 수도 있다는 등 이타적인 것들이 많이 생긴 것 같다.