[카카오테크캠퍼스] 3단계 개발 3주차 회고

이번 주는 개발 대신 멘토링과 재정비를 했다.

멘토링 내용

Fork 뜨지 않고 작업하기

깃 충돌 관련해서 여쭤보다가 멘토님께서 카테캠에 있는 레파지토리에서 각자 fork해서 작업하고 pr을 날리는 지금 로직보다는

카테캠에 있는 레포를 그대로 로컬에 clone해서 각자 브랜치에서 작업하고 pr을 날리는 것이 더 좋을 것 같다고 하셨다.

이제까지는 당연히 fork를 해야하는 줄 알았는데, 신기했고 막상 해보니까 더 깔끔하고 좋은 것 같다.

이런식으로 각자 파트에서 주차별로 브랜치를 만들고, 머지되면 해당 브랜치는 삭제 할 예정이다.

 

외부 api를 사용하는 파일의 네이밍 고민

내가 담당한 파트에서는 외부 api인 open api를 사용하는 부분이 있다. 아무래도 이 부분은 현재 내가 구현하고 있는 도메인과는 분리해야할 것 같은데 어떻게 분리해야할지 감이 잘 오지 않았다.

그래서 이 부분을 여쭤보았는데, 

infrastructure : 외부와 통신하는 기능 -> 외부시스템과연동하는 기능 (데이터, 파일 시스템에 접근.. 클라이언트..)

이런 식으로 외부외 소통하는 파일을 만들라고 하셨다.

그래서 이렇게 infrastructure을 만들고, 그 안에 필요한 부분을 구현하였다.

 

프론트와의 협업을 할 때에 어떤 점을 고려해야하는지?

우리 팀은 매주 회의를 하는데, 회의를 할 때마다 어떤 부분을 프론트분들에게 명확하게 전달해야하는지를 잘 모르겠었다.

이 부분에 대한 답변은

테스트 할 수 있는 api에 대한 작업기한을 명확하게 알려주는 것이 중요하고, api문서를 잘 작성하는 것이 좋다고 하셨다.

또한 에러 처리 방식에 대해서도 논의가 필요하다. 커스텀한 에러처리르 할 것인지 아니면 원래 있는 것으로 할지를 결정해야하는데 커스텀한 에러 코드를 내려주는 것이 좋다고 하셨다. 

 

페이지네이션 

우리는 원래 구인글 부분을 조회 할 때 무한 스크롤로 구현하고자 했다. 왜냐하면, 우리는 구인글을 지역 등으로 필터링하는 기능이 있는데 프론트측에서 서버에서 받은 데이터를 해당 부분으로 필터링하면 원래 한 페이지에 5개씩 있어야 하는 데이터가 필터처리돼서 2개 남고 이런 경우가 생길 수 있기 때문이다.

 그런데 이 부분은 서버에서 먼저 걸러서 주면 된다고 하셨다.(그게 나다ㅜㅜ) 다음 회의 때 프론트분들과 이야기해봐야겠다.

 

ERD 피드백

이 부분은 멘토님께 뭐라도 더 피드백 받고 싶어서 질문드렸던 부분인데

예상치 못하게 많은 이야기를 들었다. 우리는 나름 괜찮게 설계했다고 생각했는데 멘토님 말씀을 들어보니까 그게 아니었다. 생각보다 너무 빈틈이 많았다. 역시 현업을 하신 분은 다르다. 

우리는 근로자와 고용주를 함께 user에 두고, 근로자지만, 고용주에 해당하는 필드에는 null을 두고 이런 식으로 구현했다. 이러다보니까 테이블이 무거워지는 상황이 발생했다. 그래서 이를 해결하기 위해서 근로자와 고용주에 해당하는 필드를 관리하는 테이블을 분리하는 것이 좋을 것 같다고 하셨다.

 또한 우리는 원래 구인글 테이블을 고용주 테이블과 연결했었는데, 이를 회사 테이블과 연결하는 것이 좋을 것 같다고 하셨다. 고용주가 여러개의 회사를 가질수도 있으니까!

근데 이 부분은 프론트측도 변하는 것이 많을 것 같아서 이 부분은 다 같이 회의를 해보기로 했다.