0206_retrospective - Softeer-Team6/Team6-6Four GitHub Wiki

김성우

노션에 안드로이드 프로젝트 기능 구현 사항, 구현에 필요한 라이브러리, 개발 협업 규칙을 정리해 업로드하였다. 
이제는 개발 단계에 들어가야 할 것 같아서 프로젝트를 생성하고 개발에 필요한 라이브러리를 설치하였다. 
협업 규칙에 맞춰 깃 컨벤션을 지켜 dev 브랜치에 생성한 코드들을 머지하려고 하였는데 익숙치 않아서 너무 어려웠다. 
빠르게 익숙해져서 협업 전략을 지키는 데 쓰는 시간보다 개발하는 데 많은 시간을 할애할 수 있도록 해야할 것 같다. 
dev 브랜치에 머지한 이후에는 본격적으로 홈 화면 구성 작업을 진행하였다. 
워밍업 때와 같은 화면을 만들지만 직무 교육을 받으면서 배웠던 부분을 전부 고려하면서 코드를 작성하다보니 신경 쓸 부분이 꽤 있었지만 코드가 많이 개선된 느낌을 받아서 조금 뿌듯하였다.

송예린

### 오늘 한 일
- Erd 이해 
- 회원가입/로그인 구현을 위한 흐름 파악
- 필요한 요소(로깅필터)관련 서칭
- 협업 룰 익히기 (이슈 / pr 템플릿 적응)


### 세부 내용
- erd 논의
팀원이 짜온 erd를 바탕으로 백엔드 다같이 논의하면서 이해하는 시간을 가졌다

- 협업 룰 익히기
문서화가 빡세다 .. 하지만 적응해야지 !

- 디자인 이슈 공유
디자인 하는 과정에서 논의하는 시간을 가졌다

### 좋은 점
같은 공간에 있다보니 궁금한 점에 있어서 실시간으로 해결할 수 있다는 점이 좋았다.
다만 .. 백엔드 방은 공기가 너무 답답하다..ㅎ

유승민

## 한줄일기
프로젝트 패키지 구조 잡으면서 생긴 고민
CQRS 라는 용어를 접하고 CUD 와 R 이 다른 흐름으로 동작한다는 것이 매우 흥미로웠다.
그래서 '카밥' 프로젝트를 진행하면서도 이런 개념을 적용해보고 싶다는 마음이 들어서 패키지 구조를 구상했다.

하지만 읽기 저장소와 쓰기 저장소를 분리해야하는 CQRS 이지만 프로젝트 내에서 실제로 저장소를 2개 사용하기로 하지도 않았고 읽기 성능이 중요할만큼 큰 트래픽이 들어오지도 않을 프로젝트이기에 현 시점에서 꼭 도입해야하나? 라는 생각이 들었다.

그럼에도 불구하고 command, query 로 분리되어 비지니스로직이 처리되는 우아한 패키지 구조라는 생각에 일단 그렇게 구상했고 팀원들에게 소개했다. 
하지만 지난 2일동안 초기 세팅을 진행하면서 계속해서 이렇게 꼭 해야하나? 라는 고민이 이어졌다. 
성능적으로 이득이 있지도 않은 depth 만 깊어지는 구조라고 생각이 들었다. 오히려 팀원들이 작업을 함에 있어서 이런 복잡한 구조는 작업을 힘들게 하지 않을까 싶어서 PR 을 올리기 전에 마지막으로 물어보게되었다. 
우려했던 것과 같이 '실제로 이해하기 힘들었고 내가 잘 몰라서 그런가보다' 라는 좋지 않은 생각이 들게 만들었다. 
내가 매력적이라고 생각해서 팀원들의 작업을 힘들게 할 이유는 없는 것 같다. 
코드를 작성하면서 예술 행위를 하기보다 같이 활동하는 팀원들의 생각을 좀 더 자세히 물어봐야겠다고 깨닫게된 경험이였다.

## 느낀점
항상 why? 를 더 생각해야겠다고 깨달은 하루였다.

## TODO
1. API 개발
2. 개발 공수 다시 잡기

이대산

# 오늘 한 일
-  VPC 보안 그룹 설정
데이터베이스가 있는 인스턴스는 외부에서 접근하지못하도록 막아두고 다른 인스턴스는 접근할 수 있도록 설정하였다.

- AWS EC2 Java 설치 및 환경 구성
각 인스턴스에 필요한 java, mysql, redis, nginx를 설치하는데 mysql를 amazon-linux os를 선택했는데 많이 애먹었다.. 
그리고, 자꾸 다운되서 스왑메모리도 설정하였다

- CI/CD 구축 진행중....

# 회고
전체적으로 이슈관리나 커밋 등 우리가 어떻게 컨벤션을 정하였는지 확실히 이해하는게 중요하다고 느낌.. (너무헷갈림)
협업에 유용하게 백엔드 파일구조가 픽스되었는데 이걸 잘 이해하는게 중요하다고 느꼈음.. (머리아프다)