글 쓰는 시간

커밋 컨벤션

깃을 쓰면서 프로젝트를 하면 할수록 깃 컨벤션을 잘 잡고 가야 할 필요성을 느낀다.

커밋 기록이나 PR 기록을 보면 컨벤션을 잘 맞춰서 작성하면 굉장히 깔끔해 보인다.

기본적으로 아래와 같은 형식으로 작성하는게 보통인것 같다.

(깃모지) 커밋 유형: 커밋 내용 요약
ex) feat: xxx 기능 추가

아래 사진도 아직 고쳐야할 부분이 보이지만 컨벤션 없이 중구난방으로 작성한 오른쪽 보단

커밋 컨벤션을 지키면서 작성한 왼쪽이 더 깔끔해 보이는것 같다.

커밋 컨벤션 표

이번 프로젝트에서 쓸 커밋 컨벤션을 표로 만든 것이다.

깃모지를 써보았는데 앞의 prefix만 잘 붙여주면 깃모지는 굳이 필요한가 싶다.

팀원 간의 협의가 있어야겠지만 아마 다음 프로젝트 부터는 안쓰는 방향으로 갈것 같다.

JIRA

1차 팀 프로젝트에서 JIRA를 써서 일정 관리를 하니 좋았던 경험이 있었다.

비록 JIRA의 단편적인 기능만 사용하고 있지만 차차 쓰는 기능을 늘려보도록 하고

우선 쓰고 있는 좋은 기능을 정리해보려 한다.

에픽

기능을 분담하고 각자 맡은 부분에서 큼직큼직한 주제를 에픽으로 정한다.
각자 데드라인을 설정하고 정리하여 프로젝트 일정 진행 내역을 확인할 수 있다.

하위 이슈

에픽 아래에는 에픽을 쪼갠 내용인 하위 이슈들을 나열하여 PR 단위로 정한다.

PR이 너무 길어지면 코드 리뷰 시 피곤함을 유발할 수 있으므로 적절한 단위로 하위 이슈를 나눈다.
추후 이전 작업 내역을 찾을 때 용이하도록 티켓번호와 기능을 제목으로 하여 PR을 올린다.

JIRA

지금까지 JIRA 하면 뭔가 복잡한 무언가라고 생각하고 있었던것 같다.

그래서 JIRA, 티켓 이런 이야기가 나오면 괜히 쫄아서 손 댈 생각도 못해보고 있었다.

하지만 요즘들어 다른 사람들도 다 쓰는데 나라고 못쓸까? 라는 생각을 갖고 그동안 못해본걸 해보고 있는데,

JIRA도 그 중 하나라고 생각이 되어 뭐가 됐든 한번 해보기로 했다.

최근 IDIOT-s 에서 팀 프로젝트 하는것도 JIRA 쓴다고 해서 팀원분께 알려달라고 부탁했다.

설명을 들으면서 시연하는걸 보고 나니 잔뜩 쫄아있던거에 비해 생각보다 별거 없었다.

깃허브 기능의 마일스톤, 이슈와 비슷한 느낌인데 더 쉽게 만들어둔 느낌이었다.

써보기

JIRA 에는 에픽이라는 조금 큰 작업 단위가 있고, 에픽 하위에 하위 이슈라는 작은 작업 단위가 있다.

내가 이해한 바로는 대충 이런 식으로 쓰는것 같다.

1. 적절한 크기(하루 내로 할 수 있을 정도)로 업무를 쪼개고, 쪼갠 업무로 에픽을 만든다.
2. 에픽에서 세부적으로 해야할 일을 나눠서 하위 이슈를 만든다.
3. 하위 이슈를 처리할 때 해당 이슈 이름의 브랜치를 만들고 거기서 처리한다.
4. 각각의 하위 이슈들을 작업하고 PR을 올린다.

팀 스타일에 따라 맞추면 되겠지만 기본적인 골자는 이런것 같다.

내가 써보면서 익힐겸, 팀원들도 꼬실겸 어떻게 쓰는지를 나름대로 정리해보았다.

이슈 생성 방법을 간단하게 사진으로 정리하면 아래와 같다.

JIRA는 깃허브 org 레포지토리와 연동할 수 있다.

연동 후에 이슈를 처리하는건 아래처럼 하면 된다.

워크 플로우 설정같은거도 할 수 있는것 같았는데 차근차근 만져봐야겠다.

좀 더 많은 기능이 있겠지만 이 정도만 써봐도 깃허브보다 이슈 관리, 브랜치 설정하기 편하다는 느낌이었다.

그래서 팀 프로젝트 할 때 쓰자고 꼬셔서 도입에 성공했다. 야호 !

코드 리뷰 훔쳐보기

최근 다른 사람이 받은 코드리뷰를 훔쳐볼때마다 하나씩 배워간다.

공부하기 싫을때는 이렇게 다른식으로 배움을 얻는것도 되게 좋은것 같다.

오늘 배운건 검증부는 하드코딩한다 라는 주제이다.

검증부는 하드코딩한다.

요즘 테스트코드를 적용해보는건 좋지만 너무 생각없이 작성하고 있었음을 느낀다.

예를 들자면 아래같은 코드다.

문제의 테스트코드

@DisplayName("로그인 요청 시 DB 정보와 일치하면 accessToken 을 발급한다.")
@Test
void signin() throws JsonProcessingException {
    // given
    Signup signup = Signup.builder()
        .email("hyukkind@naver.com")
        .name("midcon")
        .password("1234")
        .build();
    authService.signup(signup);

    LoginRequest request = LoginRequest.builder()
        .email("hyukkind@naver.com")
        .password("1234")
        .build();

    // when
    String name = authService.signin(request);
    User user = userRepository.findByEmail("hyukkind@naver.com")
        .orElseThrow(() -> new InvalidSigninInformationException());

    // then 이 검증부가 문제 !
    assertEquals(user.getName(), name);
}

생각없이 검증부를 아래처럼 작성하고 있었다.

assertEquals(user.getName(), name);

문제점

1. 무의미한 검증

이런 검증부는 별로 의미없는 테스트라고 생각이 된다.

이처럼 도메인 로직을 사용한 소프트 코딩은 사실상 프로덕션 코드를 복사 & 붙여넣기 한것이다.

굳이 userRepository.findByEmail 일 이유도 없고 signup.getName 이어도 상관없을 것이다.

2. 구현코드와 강결합

이처럼 도메인 로직을 사용한 테스트는 도메인 로직과 강결합을 한다는 문제점 또한 가진다.

만약 리팩토링을 하여 user.getName 로직이 바뀐다면 테스트 또한 모두 바꿔야한다.

검증하고자 하는 로직을 변경한다면 테스트를 바꿔야하는건 당연하지만

다른 도메인 로직을 바꿨을 때도 상관없는 다른 테스트 코드를 변경해야하는건 문제가 있다.

따라서 검증부는 아래처럼 하드코딩하여 테스트 목적에 맞는 값을 작성하는게 옳다.

수정한 검증부

// then
assertEquals("midcon", name);

이와 관련한 더 자세한 내용을 원한다면 아래 참고자료에 첨부한 향로님 블로그 글을 읽어봐도 도움이 될것이다.

참고자료

코드 리뷰

코드 리뷰란 주어진 코드에 대해 코드를 작성한 개발자와 이외의 개발자들끼리 피드백을 주고 받는것이다.

이 과정을 통해 코드를 작성한 개발자는 본인이 생각하지 못했던 버그나 사이드 이펙트를 발견할 수 있고,

코드를 리뷰한 개발자는 자신과 다른 관점의 코드를 보며 인사이트를 얻을 수도 있고 지식을 말로 가공하는 과정에서

지식을 재정리 하며 효과적으로 전달하는 방법을 생각해볼 수 있다.

코드 리뷰 하는법

그럼 이제 Github 에서 Pull request(PR)를 이용해 코드 리뷰를 하는 법을 알아보자.

org 를 만들어서 코드 리뷰 할 사람끼리 PR 올리는 과정까지은 알거라 생각하고 설명하지 않겠다.

우선 원격 리포지토리에 가서 Pull request 탭을 들어가면 아래처럼 나올 것이다.

1. 리뷰어로 참여하고자 하는 PR 에 들어가서 Files changed 를 누른다.

2. 아래 사진의 과정을 진행

Files changed 에 들어가면 해당 PR 에 커밋한 모든 파일들이 보일것이다.

리뷰를 남기고 싶은 코드가 있다면 아래 사진의 1, 2 의 과정으로 리뷰를 남긴다.

1, 2 를 반복하여 모든 리뷰를 마치고 나면 3번을 누른다.

3. Submit review 를 누른다.

Comment, Approve, Request changes 기능이 있으니 잘 활용하자.

전체적인 코멘트를 남기고 싶은게 있다면 맨 위 코멘트를 작성할 수 있다.

해당 PR 의 내용을 브랜치에 merge 하는걸 승인한다면 아래의 Approve 를 체크해주면 된다.

끝!

코드 리뷰는 처음이라

굉장히 유익한 시간이었다.

현업자들의 정돈된 코드와 취준생들의 정돈이 덜 된 코드를 번갈아 보면서 어떡해야 가독성 높고 변경에 용이한 코드를 작성할 수 있는지 생각해볼 수 있었다.

또한 현업자들의 커밋 단위와 커밋 메시지의 좋은 예를 볼 수 있었고 ReadMe 작성, 테스트 작성도 배울 수 있었다.

또한 코드 리뷰를 하며 동일한 주제에 대해 내가 생각했던 접근 방법과 다른 사람들의 다양한 관점의 접근을 비교해보고

좋은 인사이트를 얻을 수 있었다.

첫 코드 리뷰 모임을 굉장히 좋은 사람들과 진행하게 되어 기쁘다.

더 생각해 볼 점

코드 리뷰 또한 개발자간의 오고가는 커뮤니케이션이므로 리뷰를 받는 사람의 마음을 고려하는게 제일 순위인것 같다.

내가 생각하는 방법만이 정답이 아니고 코드 리뷰는 서로 최적의 방법을 찾아가는 과정임을 명심해야한다.

따라서 누가 봐도 완전히 안티패턴인 경우를 제외하면 내가 전달하고자 하는 메시지를 명확하게 전달하면서

상대방의 마음을 상하지 않게 하는법을 더 생각해봐야겠다.

또한 방법을 알려주기보단 방향을 알려주는 방식으로 리뷰하는 습관을 들여야겠다는 생각이 들었다.

현업자 분들의 코드 리뷰 방식을 보면서 이런 상대방을 생각하는 스탠스가 눈에 잘 보여서 배울게 정말 많았다.