Skip to content

2021 07 04 회의록

Jinhong edited this page Aug 16, 2021 · 2 revisions

[Front, Back] 세미 스프린트 회의

  • 호스팅 → EC2로 가능한지 확인 (리버스 프록시 사용)
  • 질문 : 1차 데모때 API 연결까지 가능한가?

7.17까지 프론트 / 백 1-2주차 스프린트 마무리

  • 스프린트 주기는 프론트-백 따로 두기
  • 하지만 최종 합의일은 17일까지
  • 오늘 쳐낼 기능을 쳐내자
    • 쳐내는 기능은 구글 닥스에 정리함!
  • 프론트-백 자주 공유가 중요하다고 느낌
  • 브콜 : aws팀코톡 (ec2, s3 등...) 부탁드립니다!
  • 프론트와 백 관련 배포 논의합시다 (다음주중에? 어느정도 구현되고나서 ㅎㅎ)
  • 사진 : 절대 경로로 사용
  • 만일 진행 중 구현 요구사항이 변화가 있을 경우 항상 빠른 피드백 필요!!!!

첫번째 데모(7월19일) 까지 프론트 및 백엔드 구현 기능 리스트

image


[Back] 기술 스택 회의

1. 프로세스 진행 방법

  • 마크 : 어떻게 코드를 짜가며 구현해나갈 것인가?
  • 첫 스프린트 일정(2주) → 세미 스프린트(1주, 1주)
    • 1주차 세미 스프린트에서 설계 대 구현의 비중을 어느 정도로 둘 것인가?
    • 1주차 비중을 설계(45) : 구현(32) 정도로 두고, 2주차 부터는 회고하면서 유연하게 비중을 변경한다.
    • 손너잘 : 4 2 1 (마지막 하루는 이슈 트랙킹하는 날로 잡는 것은 어떨까?)
    • 마크 : 5 2 (설계 기간 때 OAuth, 이미지, 태그 등 구현에 필요한 개념 학습하고 구현을 컴팩트하게 가져가자)
  • 설계에 대한 정의?
    • 단순히 ERD 그리는 것이 아니라, 리팩토링 등등 모든 것이 수반된 개념.
    • DTO 분리, 계층, 코드 컨벤션 등에 대한 합의도 이 때 이루어져야 한다.
    • 설계는 스켈레톤 코드가 수반된다. 구현 때는 비즈니스 로직에 초점을 맞춘다.
  • 어떻게 설계할 것인가?
    • 2 / 3명씩 짝을 지어서 각각 나름의 설계를 한 다음, 마지막에 상호 리뷰함으로써 하나로 통합한다.
      • 다만 이를 위해서는 공통된 스키마 컨텍스트가 있어야 한다.
        • 웹 계층 구조, OOP, 포맷팅 컨벤션 등. (아마 월요일에 이야기해야 할 듯)
        • 상대방에게 주입하고 싶은 지식을 정리해옵시다 (내일 월 오전까지)
    • 2~3명이 주도로 설계하고 나머지는 기반 지식 학습하고 마지막에 리뷰한다.

2. OAuth의 이해

  • 생활 코딩

3. 기술 스택

  • (월)요일에 구체적인 금지 기술이 나오지만 우리와는 별 상관은 없을 듯 하다.
  • CI 방식과 DB에 대해 고려하면 될 듯하다.
  • DB는 MariaDB (MySql은 유료이며, NoSql은 어려울 듯 하다.)
  • CI는 Jenkins (Travis는 유료이며, Jenkins가 Java Project 친화적이다.)
  • 협업 툴은 Jira 러닝 커브가 높아서 Github 기반으로 가자.
  • Java 버전은?
    • Java 11 : 컬렉션, 스트림 등 모던 Java 기능 친화적이다.
      • 다만 다른 프레임워크 및 라이브러리와의 호환성 측면을 간과할 수 없다.
    • Java 8 : 익숙하다.
    • Java 11로 도전하고 정말 문제가 있으면 8으로 다운그레이드 한다.
    • Java 11의 장점 : https://m.blog.naver.com/gngh0101/221562878280
  • 인프라 구성
    • Reverse Proxy + WAS + DB
    • EC2 3개

4. Git 전략 + 코드 리뷰

  • 코드 리뷰
    • 최소 2명 Approve
    • 최대한 빠르게 코드리뷰를 하되, 가급적 빠르게 Merge 해서 속도를 올린다.
    • 코드보다는 테스트 케이스에 대한 정도를 기반으로 판단하여 merge 후, 나중에 코드 퀄리티에 대한 리뷰를 추가로 진행(따로 이슈로 등록?)
      • 코드 자체에 대한 리뷰는 다같이 띄워놓고 한꺼번에 진행하도록
    • 테스트 코드 컨벤션은 내일 논의 필요 - 테스트종류, 메서드명 등등
    • 테스트 코드는 단위, 슬라이스, 통합 테스트 정도로 생각한다.
    • 슬라이스 테스트와 통합 테스트는 서비스 레이어를 중심으로 진행하자. 서비스 레이어가 흐름을 제어하기 때문이다.
  • Git 전략
    • Github Flow + Git Flow를 섞자
    • Develop 브랜치를 포함해서 총 3개의 브랜치로 가자
      • Master, Develop, Feature
      • Develop에 계속 pr 보내고 완료되면 Master로 merge

[회의 요약]

기술스택

  • CI/CD: Jenkins
  • DB: MariaDB
  • Java: 자바 11
  • 프레임워크: Spring Boot + Spring Data JPA + AssertJ
  • 배포: docker + nginx + AWS (reverse proxy + WAS + DB)
  • 일정관리: Github 프로젝트 + Notion

설계

  • 1주차 sprint: 설계 5 + 구현 2 (4/3같은..)
  • 2명/3명 으로 나누어서 설계 후 논의하여 합치기
  • 설계하면서 스켈레톤 함께 작성

코드리뷰

  • 최소 2명 이상의 Approve 이면 merge
  • 첫번째 단계의 merge 조건은 탄탄한 테스트코드
  • 두번째로 단계로 다같이 모여서 코드 퀄리티에 대한 리뷰를 함께 진행
  • 빠른 merge를 기반으로 진행하도록 함

추가 논의 필요 (아마도 월요일)

  • 테스트 코드 컨벤션
  • 설계 관련 기반 지식 나눔 및 설계 조 짜기