우아한테크코스 Level3 스프린트 1 회고

공병주(Chris)·2022년 7월 26일
우아한테크코스회고
2
post-thumbnail

스프린트1 회고

우아한 테크코스 레벨 3 팀 프로젝트가 시작이 되었다. 이전 기수 사람들이 레벨3가 우테코의 꽃이라고 해서 기대가 되었다.

아래와 같은 기대를 했다.

  • 레벨 1, 레벨2에서 공부하고 배우고 고민한 것들을 미션이 아닌 우리가 기획한 서비스에 사용할 수 있다는 기대

  • 팀으로 협업을 한다는 점. 팀끼리 컨벤션을 정하고, 문화와 규칙을 만들 수 있다는 기대.

  • 미션에 얽매이지 않고 궁금했던 기술들을 적용해볼 수 있겠다는 기대

    팀원은 동키콩(FE), 무비(FE), 조시(BE), 헌치(BE), 토르(BE), 이스트(BE), 크리스(나)로 구성되었다.

첫 만남은 솔직히 조금 대면대면했다. 레벨2 - 레벨3 사이의 방학에도 서로의 일정으로 인해, 회의 날짜를 잡기가 힘들었다. 그렇게 결국 우리는, 레벨3 개학 2일 전에 첫 회의를 진행했다ㅋㅋㅋ…

팀 문화 정하기

  1. 결정은 다 같이, 책임도 다 같이
  2. 다 같이 알기
  3. 비난 없는 의사소통
  4. 반대는 근거와 함께
  5. 바로 말할 권리, 늦게 답할 권리
  6. 메시지를 보낼 때, 핵심으로 소통
  7. 공적인 회의는 존댓말 사용

복잡하게 하지 않고 필요한 것들만 정했다!

데일리 미팅 규칙

  • 시작 시간 : 10시
  • 할일
    1. 오늘 할일 공유
    2. 어제 진행 상황
    3. 요청 사항 있다면 요청
    4. 이슈 공유
    5. 논의사항

❗️ 모든 인원이 꼭 의견 다 내기

❗️ 10분 잡담하고 미팅 시작!

Level 3, 팀 협업 목표

팀원들과 목표를 공유하는 시간을 가졌다.

나 개인의 목표

  • 많은 기술 적용해보기 ( 로깅, CICD 등등 )
  • SpringBoot와 JPA 남에게 설명할 수 있는 수준 되기
  • Infra 공부하기 (+ 가능하다면 CS까지)
  • 프론트의 구조 어느 정도 파악하기
  • 팀원들과 더 친해지고 사이좋게 잘 마무리 하기

팀 목표

  • 프로젝트 성공
  • 프로젝트 유지보수 경험
  • 더 나은 협업 경험
    • 팀문화 정착시키기
    • 올바른 갈등 해결 및 소프트스킬 증진
  • 사이좋게 지내기

주제 정하기

먼저 서비스의 주제를 익명, 대나무숲으로 정했다. 그리고 주제와 연관되는 아이디어를 7명이 생각나는대로 적었다.

그 후, 아이디어를 세부 기능 및 주제들로 분류했다.

그리고 분류된 주제들의 우선순위를 매겼다.

첫번째 스프린트에서 구현할 기능

위의 우선순위를 기반으로, 첫 스프린트에 구현할 기능을 정했다.

사실 최종 구현할 것들까지 정하고 있었는데, 개발에 드는 리소스가 측정이 잘 되지 않았고 2주 단위로 애자일 하게 개발하는 것이 좋다는 결론을 내려서 api를 3개로 정했다.

2주동안 3개의 api를 개발하는 것이 적다는 생각을 할 수 있다. 하지만 첫 주에는 레벨 인터뷰와 UX 특강이 있었기 때문에, 거의 팀 프로젝트를 진행할 수 없는 상황이었다. 또한, 팀 프로젝트에 적응하는 시간들이 필요했고, 컨벤션과 git-flow 등 정해야할 점이 많아서 기능을 적게 구현했다.

추후의 회고에서, api를 적게 가져가고 협업에 적응하는 시간을 많이 가질 수 있어서 좋았다는 의견을 7명 모두 내었다.

협업 시작

레벨 3가 시작되고 레벨인터뷰와 UX 특강을 끝내고 본격적인 회의를 시작했다.

Git 관리 방법

  • master : 운영, 배포
    • dev : 개발용 서브 브랜치
      • fe : 프론트용 브랜치
        • feature
        • fix
      • be : 백엔드용 브랜치
        • feature
        • fix
    • hotfix : 배포 후 버그 긴급 수정용 브랜치

우리의 서비스는 규모가 그리 크지 않기 때문에 gihub-flow 방식을 기반으로 Git 관리 방법을 정했다.
프론트와 백엔드의 Repo가 분리되지 않았기 때문에, FE와 BE를 분리해주었다.

팀 협업 툴

Miro

아이디어 회의나 와이어프레임 작성은 Miro를 통해서 한다.

디자인 → Pigma

디자인은 Pigma를 통해 백 + 프론트 함께 한다.

사실 FE가 디자인을 다 하는 팀들도 있었지만, FE가 BE에 비해 비교적으로 ui과 가깝지만, FE 개발자는 디자인을 전담하는 것이 아니라고 팀에서 판단을 했기 때문에, 함께 디자인을 하기러 했다. 이 부분은 정말 잘한 것 같다! 뿌-듯

Notion + Slack

회의에 대한 기록과 정해진 규칙들은 Notion을 통해서 기록한다.

슬랙을 통해서 소통하고, Notion의 중요한 변경은 Slack 알림을 설정해둔다.

첫 디자인 회의

3개의 페이지에 대해 팀원 7명이 모두 함께 디자인을 했다. 헌치가 디자인 전공이었어서, 중심을 잘 잡아줘서 좋았다. 그리고 다른 팀원들도 의견을 많이 내고, 열심히 해서 예쁘고 깔끔한 디자인이 빨리 나온 것 같다.

백엔드 컨벤션

테스트 메서드 명명 규칙

테스트 메서드는 영어

  • DisplayName 한글로 사용
  • calculate (성공) → calculate
  • 예외 발생 경우가 하나일 경우 : calculate_Exception
  • 예외 발생 경우가 여러 개일 경우 : calculateException{Reason}

테스트 메서드를 한글이 아닌 영어로 결정한 이유

  • 이해를 위해 테스트 메서드 명을 한글로 작성하는 사람들도 있는데, Displayname으로 충분히 대체가 되고 이미 영어 메서드에 익숙함.
  • 테스트 메서드의 이름과 프로덕션 메서드의 이름을 동일하게 작성해서, 해당 테스트 메서드가 프로덕션의 어떤 메서드를 테스트하는지 바로 쉽게 확인할 수 있게 함.

테스트 Mocking 유무

  • 통합 테스트로 가져가고, 필요에 따라서(외부 Api 사용 등)에는 모킹

DB 테이블 PK : id vs tableName_id

  • tableName_id

사실 이 부분은 취향차이이지만, 현업에서 DB A 분들이 tableName_id의 형식을 많이 사용하기 때문에 맞춰주는 것이 좋다고 생각하여 결정

Lombok 사용범위

  • Getter만 사용
  • 만약에 사용해야 될 상황이 있으면 팀원들과 논의

final 사용 범위

  • 필드 : O
  • 파라미터 : X
  • 지역변수 : X
  • VO는 final class
  • 꼭 써야 할 경우가 있으면 쓰기!

service에서 domain 반환 vs dto 반환

  • 일단 디폴트는 dto로 두고, 프로덕션 쳐보면서 융통성 있게

Service 레이어까지 request/response dto로 통일

  • 계층마다 dto를 분리하는게 이상적일 수도 있지만, 이상과 현실은 다르다.
  • 계층 마다 dto를 분리하면 관리 포인트가 너무 많아진다.
  • service

CustomException 사용

테스트 코드 AssertAll 사용

  • assertThat 만을 사용하면 여러 assertThat 중 하나가 실패했을 때, 다른 assertThat이 성공한지 실패한지 모른다.

RestAssured 메서드 추출 방식

  • 범용적으로 추출
  • 네이밍은 httpPost, httpGet, HttpGetWithAuthorization같은 형식으로
  • 매개변수로 Object(request Body), String(url) 전달

테스트에서 given, when then 명시안함

  • 명시 안하고 개행으로 구분

“.”은 한줄에 하나만

  • RestAssured는 제외
  • 목적은 가독성 향상, 한줄에 하나만 하는 것이 가독성을 해친다면 하지 않는다.

개발 시작 ( 몹 프로그래밍 )

스프린트 1에서는 api가 3개 밖에 되지 않아서, 백엔드는 몹 프로그래밍을 통해서 개발을 진행했다.

확실히 5명이 하나의 코드를 작성하다보니, 생각이 다른 점이 꽤 있었다.

인수테스트에서 인수를 Client로 가정할지, 고객으로 가정할지에 대해 토론을 했다.
이 토론을 3시간 이상 정도 진행하고, 고객으로 가정했다.

해당 주제로 3시간 이상의 시간을 할애하고 나서 우리의 피드백은 아래와 같았다.

서로를 설득하는 것도 충분히 좋지만, 정해진 시간 내에 기능을 구현해야 하는 것도 생각하자. 타임키퍼를 두어서, 해당 주제를 토론하는 것이 손익분기점을 지난다면 깔끔하게 끊고, 결정을 하자.

맞는 말이다. Trade-Off인 경우에서, 서로를 계속 설득하려고 하니 힘만 빠지고 계속 서로를 설득하는 상황이었다. 이럴 때는, 깔끔하게 Trade-Off를 인지하고 다수결로 결정하기러 했다.

JPA 엔티티 자동 생성 하는 방법

백엔드 팀원들과 JPA 엔티티 자동 생성하는 방법을 공부하고 적용해보았다.

팀 기술 블로그 https://sokdak-sokdak.tistory.com/2

개인 블로그 https://velog.io/@byeongju/qpmaix3w

데모

데모 하루전, 토르와 조시의 발표를 피드백하고 사진 한장 남겼다! 우리 팀은 사이가 정말 좋아서 너무 좋다~!~!

토르와 조시가 발표를 너무 잘해주었다!!!

사실 개발자는 말하기 능력도 상당히 중요한데, 토르와 조시는 이미 훌륭한 것 같다.

나도 상대방에게 요점을 확실하게 전달하는 연습을 더 해야할 것 같다!

무튼 우리팀 너무 좋다~❤️

끗!

profile
공병주(Chris)
이전 포스트

스프링에서 메일 보내기

다음 포스트

우아한테크코스 Level3 스프린트 2 회고

0개의 댓글