멘토님 말씀
즐거운 분위기로 회고를 마무리 하라
소감 위주로 가져가고! 말을 많이 하자!
앞으로의 행보에 대해서도 !
인터뷰 형식 등, 프로젝트 대환장 파티 컨셉!
구현 보다는 알맹이가 중요하다.
(경) 인스타규램 프로젝트 완료 (축)
회고회고회고회고🍯 멘토님들의 피드백
희 멘토님의 문서화 TIP !
- 잘 모르는 사람한테 보여줘서 피드백을 받는 방법도 있다
- 중간중간 개발을 하면서 기술문서를 쓰면서 피드백 받을거 받으면서 남들 시선에서 내 글을 보면서 반영 시킬 수 있다.
- 문서화는 남과 나를 위함이다
- 회사에 가면 성과, 역할이 있으니 잘 정리를 하면 기반이 될 수 있다 문서화는 선택이 아닌 일을 잘 할 수 있는 방식의 default 이다
- 내 생각을 적는 느낌보다는 남들이 잘 파악을 할까 위주로 생각을 하면서 글을 쓰면 좋을 것 같다
- 문서화는 업데이트가 될 수 있는 방향으로 가자 !
희님의 프론트 엔드를 생각하는 백엔드 개발자
- 프론트를 생각하는 백엔드 개발자라는 수식어가 이상할정도로 당연하다
- 같이 협업하시는 분들은 다양한 분이 계신다
- 개발자는 개발만 하는게 아니라 중간에서 소통을 많이 해야하는 순간들이 있다
- 왜 협업을 많이해야하는지 소통을 해야하는지 생각해보는게 중요하다
- 우리는 서비스를 만드는 사람이기 때문에 서비스를 위해서 개발을 하는 사람이다
- 이런 측면에서 프론트가 아니라 생각의 끝이 사용자와 서비스면 좋겠다 .
희님의 화려한 기술에 대한 조언
- 일을 하다 보면 화려한 기술이 아닌 빠르게 서비스를 빠르게 런칭을 한다던가 개선을 하는게 더 중요할 때가 있다. 무조건 화려한 기술을 써야한다는 생각은 하지 않았으면 좋겠다.
- 본질을 챙기고 더 넘어서 걱정은 하지 않아도 될 것 같고 걱정할 시간에 서비스에대해 더 고민을 해보는게 좋을 것 같습니다.
- 기술은 그 상황에 맞는 올바른 길이 있기때문에 그때그때 잘 선택하면 된다.
- 기초가 잘 되어있으면 어떻게든 할 수 있다.
- 최종때 어떤 목표, 협업 방향을 가질지 진지하게 고민을 해서 한번 얘기를 나눠보면 좋겠다.
프론트랑 소통할 때
- 당연하게 생각하지 않으려고 하고 배려하는 것
- 프론트는 협업 강의 과정이 없음 .. .. . . . ..!!!!!!!
- 내가 안다고 상대가 당연히 알거라고 생각한다 는 안 좋은 생각!!!!
- ~ 되는거 아니야 ?, ~ 하면 당연히 될 거 같은데 ? 백엔드에서 판단 금지
- api 명세할 때 백엔드랑 프론트 담당자 한명씩 같이 논의를 했다.
- json 깊이가 너무 깊지는 않은지 ? ⇒ 프론트에서는 이게 불편합니다.
- 어떤 response 가 넘어오면 좋을지
- 서로 같이 일하고 싶은 사람이 되는 것이 중요하다 . ⇒ 그것이 협업이다
에일린님의 기술적 피드백
- docker compose를 사용해보는게 어떤가 ?
- 패키지 구조에도 여러가지 아키텍처가 있으니 다른 것도 한번 공부해봤으면 좋겠습니다.
- 헥사고날 .. . . .
- 의존성을 최대한 분리하는 방향으로 가는 것이 좋습니다.
- 일단은 아키텍처 보다는 리팩토링을 중요하게 합시다.
- 비관적락이랑 낙관적락을 써야하는 이유는 뭔지 면접때 논리적으로 말하는 것이 중요할 것같다.
- 꾸준히 리팩토링을 통해서 개선하는 것이 중요할 것같다.
- swagger에서 request랑 response 어노테이션 사용해주는게 좋을 것 같아요
희님의 아키텍처 구조 피드백
- 상황에 맞는 아키텍처 구조를 가져가는 것이 좋다.
- 정형화된 구조를 꼭 따라야할 필요가 없다.
- 의존성을 최대한 분리하는 방향으로 가는 것이 좋습니다.
희님의 기획에 대한 의견
- 서비스를 런칭하는 것이 아닌데 기획이 중요한가? 생각을 했습니다.
- 생각보다 면접에서 왜 했는지, 왜 기획했는지 질문이 많이 들어왔습니다.
- 내가 낸 아이디어가 아니라도 왜 하게 됐는지 고민을 해보는 것이 중요하다.
- 깊게 고민을 하면 면접에서도 잘 어필이 될 수 있다. 평소에 고민을 많이 해보면 좋습니다.
- 팀이 되어서 했어요 ⇒ 는 바로 탈락 !
- 서비스 관점에서 기획을 할 때 주도적으로 의견 많이 내고 만들어간다고 생각하면 좋을 것 같습니다.
희님의 마지막으로 하고싶은 말
- 팀원들끼리 조심스러워하는건 좋지만 조심스러워하다가 생각공유를 못해서 개발시간이 늘어질 수 있습니다.
- 조심스러워하는걸 줄였으면 좋겠고 생각 공유를 많이 했으면 좋겠습니다.
- 모르는 것도 서로서로 질문을 많이 했으면 좋겠습니다.
- 물어볼 용기가 필요합니다. 지금 안 물어보면 1년 뒤에도 모른다는 생각으로 !!
- 지금 모르는게 제일 덜 부끄럽다는 생각으로 !
- 뭔가 모를때 정답이 있는 영역이라면 빠르게 배우면 되는 것이다.
- 정답이 없을 때는 내가 못보고 있는 것도 다른 사람들이 보는 경우가 많다.
- 시야를 넓힐 수 있음. 질문을 듣는 사람도 시야 확장이 가능
- 빠르게 진행된다면 모두에게 좋을 수 있다.
- 존중을 바탕으로 질문은 명쾌하게 ! ⇒ 내가 뭘 모르는지 내가 어떻게 했는지 그래서 뭘 하고 싶은지
docker compose 한번 해봐라
핵사고날 한번 ? 적용해봡니다.
코드 깟는데 실속 없어!
의존성 저장
비관적 락이란? -> 지금도 써야한다고 생각하느냐? 개선할 사항이 있느냐?
무적권 리팩터링
docker compose (mysql viewer)랑 같이 있으며 개별적으로 사용할 수 있는 위함이다.
저 때는 기획서 햇다. 히히님 기획서가 별로 안중요해보였다. 왜 기획했나요 ? 라는 질문이 있다. 아 저는 그냥 됬다라기 보다는 내 아이디어는 ~이러한 이유로 기획했다. 내가 전에 자주사용해보면서 불편을 느꼇다.(내 것처럼 임한다는 자세를 보여야 어필이 된다)
swagger request filed에 달아두면 프론트 분이 파악하기 용이 할 것 이다. -> 메리트가 있을 것이다.