토의와 토론과 희의
| 날짜 | 내용 | 작성자 |
|---|---|---|
| 2019-11-05 | 11월 5일 토의 토론 내용 기록 | 김기표 |
| 2019-11-06 | 11월 6일 토의 토론 내용 기록 | 김기표 |
| 2019-11-07 | 11월 7일 토의 토론 내용 기록 | 김기표 |
| 2019-11-26 | 11월 26일 토의 토론 내용 기록 | 김기표 |
김기표 : ui test할 때 enzyme 라는 툴을 사용하는 것은 어떤가요?
고승빈 : 아까 전에 ui test tool로 다른 것도 있지 않았나요? Typescript도 그렇고 배워야할 내용이 너무 많아지면 프로젝트를 진행하는데 있어서 많은 제약이 생길 것 같아 유려됩니다.
김기표 : 아, 아까는 ui test에 대해서 어떻게 생각하는지 물어본 거였고, 때문에 이번에 제안한 것은 처음입니다. 그리고 Typescript에 대해서는 기본적인 javascript 지식이 있어서 익히는데 큰 어려움이 있을 것 같지는 않습니다. 하지만 프로젝트에 지장을 주면 안 되기 때문에 그런 방향으로 접근해야 할 것 같습니다. ESLint를 적용하는 것은 어떻게 생각하나요? 이 것은 한 번 설정하면 이후에 크게 신경 쓸 필요가 없을 것 같아요.
김경래 : 저번에 한 번 설치 해본적이 있는데 설정해야하는 것이 많아 포기해본적이 있습니다. 하지만 팀원들이 같이 한 번 설정 한다면 적용하는 것도 나쁘지 않다고 생각합니다.
김경래 : 로그인을 했을 때, 우리가 대화를 나누었던 기록 데이터는 어떻게 해야할까? 아까 webSql에 대해서 기표가 말해줬는데 그런 기능들을 사용하면 컴퓨터가 바뀌었을 때는 적용이 잘 안 되지 않을까? 그것이 고민입니다. 데이터베이스에서 모든 데이터를 가져올 수는 없기 때문이다.
김기표 : 그럼 특정 날짜 이후의 내용만 데이터베이스에서 가져오고 그 이전에 내용은 스크롤을 했을 때 나와야할 것 같다.
김경래 : 그럼 이전에 말했던 페이지 네이션이나 무한 스크롤을 구현해야겠다.
김경래 : 우리 이따가 기획서 면담진행할 때 할 질문리스트는 언제 뽑을까요?
이상원 : 그걸 지금하죠!
김경래 : 저번에 말했던 동시접속에대해서 이슈가 생길 수 있을 것같아서 우려가 있어서 말씀드려요, 웹소켓을 이용했을 때 사용자수가 많아지면 소켓이 메모리를 잡아먹는데, 많은 사람들이 이용하면 그러한 커넥션 수 때문에 문제가 생기지 않을까요? 이 부분에 대해서 질문을 해봐야할 것 같아요.
김기표 : 음 크게 문제가 될까요? 연결했다가 끊는 방법은 어때요?
김경래 : 그렇더라도 수용가능한 용량에 보다 많은 사람들이 연결을 유지하고 있게 될 수 도있으니까 한 번 질문 해봐요.
팀원 : 알겠습니다.
고승빈 : 아까 이야기했던 문제에대해서 할말이 있는데, 메시징 서버를 따로 두는 것은 어때?
김기표 : 그럼 메시징 서버랑 api 서버랑 따로 나누고 디비는 서로 공유하자는 형식으로 하자는 거지?
고승빈 : 응 내 말이야.
김경래 : 그럼 우리가 사용하는 서버가 3개가 되잔아 그럼 NAT라는 기능을 이용하면 어때? 마치 네이버가 자신만의 DNS 서버가 있듯이 하나의 도메인 안에서 서버를 구분하는거야.
팀원 : 좋습니다.
김기표 : 회의 기록하기가 너무 불규칙적으로 자주있으면 정리하기 힘드니까 스크럼 끝나고 회의 시간을 갖는 것은 어때?
김경래 : 나도 그렇게 생각해, 내가 생각하기에 스크럼은 너무 구체적이지 않고 다른 프로젝트의 팀원들이 모여 자신이 일을 하고 있는 것을 어필하는 느낌이라 같은 프로젝트를 진행한다면 꼭 필요한 공유내용같은 것은 좀 깊은 시간을 가지고 하는게 좋을 것 같아
김기표 : 그럼 한 시간 정도 잡는 것은 어때?
고승빈 : 너무 의무적으로 시간을 정해 놓고 하면 뭔가 말하는 것을 강제하는 느낌이 들어서 공유할 것이 있을 때만 스크럼 끝나고 하는 걸로 하자.
팀원 : 오케이
김경래 : 곰곰히 생각해 봤는데 기존 슬랙의 가입 방식에대해서 큰 의문이 생겼어요. 인증하고 가입하는 방식이 ux적으로 사용자에게 좋은 경험을 주는 것 같지는 안아서 조금 개편했으면 하는데 어떻게 생각해요?
이상원 : 아마도 이 인증방식은 슬랙의 그룹(워크스페이스)와 크게 관련이 있는 것 같아요. 슬랙에서 가입이란 자사 플랫폼의 가입이 아니라 그룹(워크스페이스)의 가입에 중점을 두어서 이런 방식이 슬랙에 도입 된 것 같은데, 그럼 두 가지 안의 화면을 기획해보고 투표를 해보는 건 어때요?
김경래 : 그럼 제가 기존방식을 타파한 그룹이아닌 슬랙에 인증하는 방식을 기획해 볼게요.
이상원 : 승빈님은 주말에 알고리즘 시험이 있으니까, 일찍 가셔야해서 저랑 기표님은 기존 슬랙에 맞추어 화면기획을 해볼게요.
김기표, 고승빈 : 알겠습니다.
김기표 : 슬랙을 sign in을 보니 이런게 있는데, 제가 domain을 이용하는 방법에 대해서 잘 몰라서 그런데 path형식으로 각 그룹을 구분 짓는 것은 어때요?
김경래 : 이게 불가능한 건 아니고, 이 기술과 관련해서 공부한 바로는 적용하면 크게 도움 될 것 같은해 해보는게 어때요?
김기표 : 네, 한 번 도전해 봐요.
-
1번안 => 기존 슬랙의 방식을 사용하자
-
2번안 => 인증을 그룹이 아닌 슬랙에 의존적으로 하자
김경래 : UX적으로는 2번안이 더 좋은 것 같다. 1번안은 이해하기가 너무 어렵다.
이상원 : 저는 기존 슬랙을 따라가고 싶어서 1번안을 했으면 좋겠습니다.
김기표 : 개발 관점으로는 크게 다른 점이 없으니 저는 둘 모두 괜찮습니다.
고승빈 : 화면도 더 적고 간단한 2번안이 좋은 것 같습니다.
김경래 : 그럼 2번안으로 합시가.
김기표 : 기능 기획서를 만들고 화면기획서를 만드는 것은 어떤가요? 기능들을 다 기획해노면 가져다가 화면에 적으면 될 것 같은데 말이죠.
김경래 : 화면을 보고 기능을 유추하는게 더 빠르고 수월할 것 같은데 그건 어떤가요?
김기표 : 하지만 자세한 화면을 보기는 어려우니까 간이로 경래님이 그린 인증방식의 화면을 보면서 기능목록을 뽑아 주실 수 있으신가요? 제가 구체적인 화면을 ui/ux tool을 이용해서 그리고 있을게요.
팀원 : 알겠습니다.
김경래 : 제가 서버쪽 코드를 보면서 든 생각인데요. api를 도메인을 중심으로 하면 좋지 않을까 하는생각에 혼자서 한 번 바꿔 보았는데, 아직 적용하지는 않았어요, 이 구조에 대해서 어떻게 생각하십니까?
이상원 : 왜 이렇게 바꾸려고 하십니까?
김경래 : 개인적인 갱각인데, 소스와 라우터가 있는데, 소스를 라우터에서 가져다 쓰는 것은 한데 묶여 있는게 ,컨트롤러를 가지고 와서 쓰는 것 보다 더 깔끔하고 의미적으로 더 좋아보였기 때문입니다.
김기표 : 저는 이 구조를 보면서 느낀 장점은 의미가 명확하다는 것입니다. Domian이라는 중심을 가지고 의미가 생기기 때문에 좋아 보입니다.
고승빈 : 저는 이렇게 바꾸는 것에 대해서 뚜렷한 장점이 없어보입니다. 게다가, 컨트롤러 안에 라우터가 선언되어있는데 이것은 좋아보이지 않습니다.
김기표 : 그러면, 라우터를 선언하는 클래스가 컨트롤러의 함수들을 도메인 단위로 상속을 받아서, 이런 방식의 도메인 중심을 하는 것은 어떻습니까?
고승빈 : 라우터가 분기되는 경우가 있는데 이경우에는 해결이 어려워 보입니다. (라우터가 라우터를 상속)
김경래 : 만약에 라우터에서 또 라우터를 사용한다고 했을 때, 필요 조건이 서브 패스가 처리하는 일이 많다면 현재 우리 프로젝트의 구조가 맞다고 생각합니다. 하지만 우리 프로젝트 특성상 그렇게 많은 분기가 일어나지 않을 것 같습니다.
고승빈 : 또 하나의 문데는 한 도메인이 너무 많은 책임을 가지고 있는 것 같습니다. 경래님이 너무 많은 부분을 참고 하시는 것 같습니다.
이상원 : 간단하게 생각할 수 있는 문제를 너무 복잡하게 생각하는 것 같습니다. 투표를 통해 결정하면 좋겠습니다.
결론 : 현재 상활대로 진행하기로 함.
팀원들에게 소켓에 대한 설명을 마친 후
김경래 : socket을 보면 room이라는 것이 존재하는데, 우리 프로그램의 방식에는 맞지 않는 것 같다,