ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
2
팀 번호주제서기프론트 질문 + 피드백백엔드 질문 + 피드백
3
예시프로젝트 명FE 서기:
BE 서기:		1. 지금 구현하신 게 모바일 사이즈 서비스인 것 같은데, 발표하실 때는 PC버전으로 보여주셨습니다. 프로젝트를 좀 더 잘 표현하려면, 모바일이면 모바일 형식에 맞게 시뮬레이터도 많으니깐, 그런 거 사용하셔서 보여주시면 좋을 것 같습니다. 계획 의도가 잘 보이지 않았던 느낌.
2. 지금 현재 메인 페이지에 무한 스크롤로 모든 산책 목록을 넣을 거라고 하셨는데, 성능 면에서 생각을 해보셔야 할 것 같습니다. 모든 이미지를 한꺼번에 불러올 수 없다. 무한 스크롤 같은 경우는 무한히 읽어올 수 없다. 수천 개 수만 개를 다 읽어올 수 없다.
3. 프런트 앤드 세 분이서 하셨는데 아까 필터 기능에 있는 디자인들이 삐져나오고 이런 것들은 퀄리티를 떨어트리는 것이다. 프런트는 보이는 게 다인데, 이렇게 정렬이 되어이지 않으면 깔끔한 느낌을 주지 못한다.
4. 상태 관리 라이브러리를 리덕스를 쓰시는데 왜 리덕스를 선택하셨는지? -> 항해 시작할 때 배운 게 리덕스였고 지금 상태에서 또 다른 새로운 라이브러리를 배운다는 것보다는 익숙한 것을 하는 게 나은 것 같다는 판단에 리덕스를 선택했습니다.
5. 혹시 아마존에 EC2를 쓰셨는데 혹시 클라우드 프런트를 돌려서 배포를 빨리하는 캐시가 있는데 그런 거를 적용해 보실 건지? 여러 가지 시도해 보는 게 좋을 것 같습니다.
6. const, let, var 다 섞여있는데 일부러 이렇게 쓰시는 건지? -> 카카오 맵에서 쓰는 데로 가져와서 우선 코드 구현하는 거에 급급해서 복사 붙여넣기 한 것 같다. -> 현업에서도 복붙해서 많이 쓰긴 하지만, 복붙할때 자신의 식대로 풀어 나아가야 한다. 근데 지금 말씀하신 것처럼 복붙해서 썼다고 말씀하시면 좋은 인상을 줄 수 없다.
7. 현업에서 많이 쓰는 라이브러리를 하나씩 늘려가도 좋을 것 같다.		1. Mvp 소개해 주실 때 필터라는 기능을 소개 안 해주셨는데, 필터라는 기능이 있는데 강조를 안 하신듯. 다음에는 그걸 글 강조해 주세요.
2. 지금 before after를 gif 파일로 비교해 주셨는데 좋습니다. 어떤 문제들을 극복했는지 보여줘서 좋습니다. 하지만 카카오 관련해서 연동+속도 문제가 있었다고 하셨는데, "문제가 있었습니다."에서 끝나서 아쉬웠다. 어떻게 하면 이거를 개선할 수 있었던지를 발표를 해주는 게 좋을 것 같다.
3. DB 코드를 뭔가 더 예쁘게 작성해 보시려는 노력을 하셨는지? -> 서비스를 구현하려는데 포커스를 주어 예쁘게라는 생각을 안 해본 것 같습니다. -> 아무래도 데이터 베이스 성능이 내가 쿼리 비문을 잘못 짠다고 해서 엄청 문제를 일으키지는 않지만, 내가 서비스를 만들려고 하는 의도를 퀸가 쿼리 비문으로 녹여낼 수 있는 (ORM을 사용하던 하지 않던) 방식을 생각하면 좋을 것 같습니다.
4
1조FE 서기: 박혜정
BE 서기: 최명백		1. 메인페이지에서 달력 모양으로 데이터를 뿌려주는 데에 있어서 라이브러리를 사용하지 않으신 것 같습니다. 달력 라이브러리를 사용하지 않은 이유는 무엇이며 달력에는 어떤 html 구조를 사용했나요?
일정 표시에 도움이 되는 라이브러리가 많았으나 배경에 썸네일 사진을 넣으려다 보니 어려운 점이 많았습니다.
또한 대다수 달력 라이브러리는 일정 관리, 연월일 뷰 등 다양한 기능을 제공하나 저희 프로젝트의 달력은 달력 형태를 유지하되 사진을 채울 액자틀의 기능 외에 다른 기능이 일체 필요하지 않아 직접 구현하기로 정했습니다.
html 구조는 테이블이 아닌 div 태그로 map 함수로 일자 데이터를 나열하고 css로 가공하여 달력 형태를 그리도록 했습니다.

2. 일기 게시물을 등록할 때 사진을 넣지 않은 경우는 어떤가요? 또 당일이 아닌 과거나 미래의 글도 작성이 가능한가요?
현재 당일만 글을 쓸 수 있도록 제한이 되어 있습니다. 이전 날짜에도 게시글을 쓸 수 있도록 하자는 의견은 합의가 되었으나 구현이 되진 않은 상태입니다.
사진 첨부와 관련해 말씀드리자면 유연한 사용자 경험을 고려할 시 사진은 선택사항인 게 낫겠다고 인지하고 있으나 구체적으로 논의 및 결정이 이루어지지 않아 다시 논의토록 하겠습니다.

3. 기술 아카텍처에 보면 부트스트랩이 명시되어 있습니다. 라이브러리 선택 이유는 무엇인가요? 또 달력에도 부트스트랩이 적용되어 있나요?
css가 능숙하지 않은 상태에서 원하는 뷰를 빠르게 완성하고, 기능 구현에 먼저 집중하기 위해 부트스트랩을 적용했습니다.
상단 네비바와 글작성 페이지의 form, 모달 등 전체적으로 적용되어있는 상태입니다. 달력은 부트스트랩이 아닌 순수 CSS로 구현하였습니다.

4. 상태관리 라이브러리로 리덕스를 선택한 이유가 무엇인가요?
다른 상태관리 라이브러리들도 언급은 되었으나 각자 상태관리 이해도가 달라 새로운 기술 도입 시 러닝 커브에 대한 부담감이 있었습니다.리덕스가 공통적으로 익숙해 부담을 최소화하기 위해 결정하였습니다.
리코일이나 리액트쿼리가 더 가볍거니와 상태관리에 대한 이해도가 낮은 사람이 있을 경우 이것들이 더 쉬울 수도 있습니다.
말씀을 들으니 기술 선택에 있어 관성적이고 보수적인 태도였다는 점을 인지하게 되었습니다.		1. 레디스와 관련된 질문입니다. 단순히 토큰을 저장하기 위해 사용하신 건가요? 아니면 refresh 토큰을 위해 사용한 것인가요?
refresh 토큰을 위해 사용한 것이 맞습니다. 유효기간 설정에 있어서 rds보다 장점이 있다 생각합니다.
그렇다면 레디스 외에 다른 대안이 있나요? 또한 히스토리 체크와 소프트 삭제를 구현할 때 문제가 있지 않을까요?

2. 통상적인 패키지 구조를 따르지 않은 이유가 있나요? 도메인 별로 패키지를 구분하게 된 이유와 통상적 구조를 왜 오래도록 많은 사람들이 사용했는지 고민과 생각이 궁금합니다.
패키지 구조란 기능 구현에 직접적인 영향을 주지 않는 영역이라 여겨 결국 개발자의 생산성과 편의성이 중요하다고 생각했습니다.
저희 팀 프로젝트의 규모에서는 새로운 팀원 추가가 없을 것이고, 파일이 10개 미만이기 때문에 저희 프로젝트의 규모에서 적절하다 느꼈습니다.
추상화가 적용되거나 파일의 갯수가 늘어나는 경우 어떻게 될 것인가요? 미래에 내 서비스가 어떻게 바뀔지는 알 수 없습니다. 또한 내 소스는 선후배, 동기, 동시대 개발자들도 볼 수 있기에 제3자가 볼 때 패키지 구조가 어떠해야 하는지 고민과 생각을 더 해주시길 바랍니다.
5
2조FE 서기:
BE 서기:		1. 리덕스 - 지역관리와 전역관리중에 유지보수의 편의성 관점에서 선택하세요.
2. 테스트코드(모든 기능에 대한 전반적인 테스트를 할 수 있는 코드)를 만들어봅시다.
3. 브랜치 전략이 어떻게 되나요? pr을 올리시는건가요 ?
4. 불필요한 소스파일을 정리해봅시다.
5. eslint나 프리티어 같은 소스공통화를 생각해봅시다.
6. 서비스 오픈이 가장 중요합니다. 서비스의 핵심기능들을 정해진 시간내에 구현하고 배포하는데 집중하세요.		1. List 로 이미지를 관리한다고 했는데 그 list 데이터가 어떻게 생겼는지? -> 저장할 때 이미지 string을 특정한 separator를 사용하여 string으로 만들어서 저장하는 방안.(어노테이션 말고)
2. 서비스 오픈이 중요함. 서비스 MVP위주의 핵심기능먼저 구현.
6
3조FE 서기:
BE 서기:		11.blue/green 배포 방식이 뭔가요? 처음 jar 파일을 실행하면 port 8080에 배포하고 새로운 jar가 들어오면 port8081에 배포 후 정상 작동하면 로드밸런스가 port8081에서 정상 실행
2.redis를 쓰는 이유는 뭘까요? 실시간 채팅 기능 구현
3. 발급한 토큰은 어떻게 리프레쉬해주나요? 무중단 배포할 게 아니라 지금 이게 더 중요해보인다. 우선순위를 잘 잡으세요.
4.기본 생성자는 java에서 자동으로 생성하지 않나요? NoArgsConstructor를 왜 쓰나요?기본 생성자를 작성하지 않으면 문제가 발생하는 것으로 알고 있습니다.
JwtFilter에서 84번째 라인에서 doFilter가 뭐하는 건가요? 숙제. Aop랑 dofilter는 같다. interceptor. spring 밖에서 일어나는 건지. 안에서 일어나는 건지.
채팅방, 물물교환 체결만 되면 되겠다.
7
4조FE 서기:
BE 서기:		1.   Dto 만들 때 builder 스타일을 썼는데 왜? -> Dto에 담긴 정보들이 많고, 전달하는 정보순서가 중요하기에 bulider 사용

2.    추가적으로 핵심기능만 개발하면 좋을 것 같다

3.    디렉토리 중 model이 entity인데 명칭을 entity 로 리팩토링하는 것이 좋을 것 같다.

4.    이중for문 -> 소스를 보기 편하게, 로직 자체를 어떻게 이중 for문을 벗어날 수 있을까,
좀 더 함수형으로 map filter optinal을 이용해서 소스를 구성하면 성능을 개선할 수 있다.
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100