2021-01-22(Fri)

항목

내용

학습 날짜

2021-01-22(금)

학습 시간

11:00~24:00

학습 범위 및 주제

협업규칙

학습 목표

협업에 필요한 규칙들을 논의한다.

동료 학습 방법

상세 학습 내용

닌자 프로젝트를 마치며, 제 13차 미팅을 진행했다.

닌자 프로젝트를 하면서 느꼈던 이슈와 그에 따른 논의를 하다보니 장시간 미팅을 진행했다. 이후 ESlint와 prettier를 airbnb 스타일로 적용하는 것을 시험하였다.

아래는 회의록.

닌자 프로젝트 연장여부

—> 들어보니, 닌자 프로젝트를 연장하고 싶다기보단, 본 프로젝트 시작일을 늦추고 싶다.

sanam: 다음 주 화요일에 시작하고 싶다.
jujeong: 다음 주 화요일부터 시작을 하고 싶다.
yohan: 주말에 좀 더 해보고 싶다. 마무리하기에는 아쉽고, 더 해볼 수 있을 것 같은 느낌이 든다. 화요일보다는 월요일에 시작을 하고 싶다. 조금 더 공부를 해도 닌자프로젝트를 구체화하는 식으로 해볼 수는 있겠지만, 본프로젝트에 들어갈 때 좀 더 효율적인 설계, 협업 방법에 대한 고민은 빠르게 얘기나누는게 좋을 것 같다. 그래서 하루라도 빠르게 시작하는게 좋을 것 같다.
eunhkim: 요한님 의견에 동의합니다.
iwoo: 설계, 협업 방법 등을 정하려면 빠르게 논의를 시작해야할 것 같다.
sanam: 사실 주말에 공부를 할 환경이 안 되어서 월요일을 학습에 쓰고 싶다.
jujeong: 주말에 약속이 있어서 월요일을 학습에 쓰고 싶다.

sanam: 월요일에 다 같이 만나자.

다들 동의

죽전역에서 만나자 12시!

🍉 ← 주말간 학습, 생각정리를 해서 월요일에 결정해야할 이슈

🍌 ← 오늘 얘기를 끝내야할 이슈

닌자 프로젝트하면서 느꼈던 이슈

index.html 의 레이아웃을 제대로 잡고 시작하면 좋겠다.
- nav view, main view, side bar 간의 관계가 semantic ui에 따라서 col, row가 제대로 나눠지면 좋겠다.
- index.html 레이아웃을 semantic-ui로 잡는 것이 최적인지에 대한 의문, CSS로 가능
용어를 명확히하자. 🍉
- guest가 처음에는 user의 타입 중 하나였는데, 사이드바 만들면서 없앴음.
- model도 백본 모델이 있고, Rails 모델이 있고..
- 용어 사전? 협업문서에 용어 사전이 명확히 적혀져있으면 좋겠다.
협업 규칙 🍉
- 용어를 얘기할 때는 DB에 정의된 이름을 쓰도록 하자.는 식으로 협업규칙이 담긴 협업문서 작성 필요.
책임 기반 설계를 하자.
- 유스케이스 적자.
DB 설계까지 확실하게 정하고 가야할 것 같다.
- 레일즈 테이블 스키마와 백본 모델Model의 속성을 가능한 일치시키는 것이 필요하고, 다를 때에는 백본에 대한 충분한 이해와 테스트 케이스가 필요하다.
  - 불일치할 경우 레일즈에서 백본으로 가져오는 것은 문제가 없는데, 데이터를 저장할 때 문제다.
    ex) Backbone: A=a, B=b —> Rails: A=a, B=b, C=default, D=default
- 레일즈 DB의 모델, 모델에 저장되어야할 요소.
- DB 설계를 확실하게 하려고해도 아마도 불완전할 거다.
  - 책임이 있고, 역할이 ← 구현하기 위해서 코딩하면서 설계가 같이 이뤄지고, class가 수행해야할 메서드가 정의되고, 이 때 필요한 클래스 안에 들어있는 프로퍼티 같은게 결정된다.
  - 코딩 단계로 안 들어가도 책임이 명확하면 DB field 설계까지 잘 될 것이다.
- 마이그레이션 명명 규칙, 관리 규칙 등이 필요하다.
- 데이터베이스 마이그레이션 관리자 지정이 필요하다. 🍉
로그인 한 유저가 탭을 끈 경우 or 로그아웃 한 경우 처리 방식 설정 🍉
- 새로고침
- 동일한 탭 내에서 다른 서비스로 이동하는 경우
- 로그아웃 버튼 클릭
- 탭 닫기
- 로그아웃이란 무엇인가. 로그아웃에 수반되어야할 액션들은?
  - 참고로 window 객체가 사라지면 케이블은 끊긴다.(새로고침같은거)
- 로그아웃 되는 경로들은?
- 로그아웃의 기준을 페이지 단위로 할 것인지, 세션 단위로 할 것인지 정의가 필요
- 정의한 기준에 따라서 서버 및 프론트가 로그아웃시 필요한 행위들을 정확하게 수행하도록 구현
- 로그인 되어 있다는 것을 어떻게 저장할 것 인가?(세션 or 쿠키)
- devise gem 사용 여부 🍉
  - eunhkim: 반대, 서브젝트 요구사항을 만족시킬지 미지수다.
  - iwoo: wpark님네는 devise 썼던데? 그럼 서브젝트 요구사항을 만족시킬 수 있는 방법이 있지 않을까? 싶긴한데, 로그인/로그아웃 관련해서 우리가 구현했을 때 얻을 수 있는 학습을 생각하면 devise 안 써도 뭐.. 좋을 것 같다.
  - sanam: 기술적으로 모든 것을 다 컨트롤하는건 좋다고 생각한다. 근데 디바이스잼 자체도 솔직히 루비레일즈에서 많이쓰이는 것이니까 아는 것도 좋다고 생각한다. 결론은, 로그인 관련해서 디바이스잼 사용하지 않고도 모든 것을 케어할 수있으면 사용하지 않는 것이 좋다고 생각한다. 레일즈 개발자로만 살 것이 아니니까, devise잼에 의존적이지 않은 방법으로 로그인 기능을 구현할 수 있으면 다른데서도 써먹을 수 있지 않겠나.
  - jujeong: 첨에는 devise 잼 써보고 싶었는데, 은휼님이 각이 안 선다고 하셨으니, 로그인 단계에서 서비스 요구사항들을 명확하게 정한 다음에 devise 잼으로 구현해보는 것이 좋지 않을까 생각한다.
  → iwoo: 가입/로그인/로그아웃 요구사항을 오늘 정해보는게 좋을듯
  - 세션이 아니라 윈도우를 기준으로, 어떤 액션으로든 윈도우가 unload될 때 로그아웃에 필요한 모든 액션(브라우저/서버 쿠키 및 세션 데이터 처리 포함)들이 수행되는 것으로 통일할 필요가 있다. 액션 케이블 역시 윈도우 단위로 연결이 유지된다. 주소창에 다른 주소를 입력하거나, 새로고침 버튼을 누르면 케이블 연결은 해제된다. 서버 입장에서는 로그아웃 버튼을 통한 HTTP 요청에 대해 로그아웃을 진행하고, 이외의 방법으로 유저가 윈도우를 unload하는 액션에 대해서도 사이드바 채널의 unsubsribed 감지를 통해 로그아웃을 처리해야 한다.
    ex) 클라이언트 User A가 갑자기 연결을 끊어서, Rails가 이를 감지해서 DB에 있는 User A의 status 필드를 offline으로 업데이트한다.
  - 싱글 페이지를 통해 회원가입, 로그인, 로그인 에러, 로그아웃 등을 정상적으로 수행할 수 있다.
  - 유저가 정상적으로 로그아웃을 하지 않고 페이지를 이탈하는 경우에 대해서도 감지할 수 있다.
  - 필요에 따라 유저 모델을 백본에 구현하여 RESTFUL하게 CRUD를 진행하는 것에도 문제가 없다.
View의 갱신시점
- yohai: 길드 랭킹이 바뀌거나 길드가 추가/삭제 되거나 할 때 갱신시점이 어떻게 되어야할지 논의가 되어야할 것 같다. 게임이 끝날 때마다 갱신할지, 동기화 버튼을 누를 때만 갱신이 되게끔할 것인지.
  - iwoo: 동기화 버튼을 누를 때만 갱신이 되게끔할 것인지 ← 저는 여기에 동의.
    채팅, 유저상태 확인(사이드바), 게임, DM ← 극단적으로 동기화는 액션케이블로.
  - eunhkim: 랭킹보기를 누르면 그 때 갱신이 되게끔하면 되는 것 아닌가? 말씀하신 것은 서브젝트에서 요구한 사항이 아닌 것 같고, 요구한 사항을 깔끔하게 만드는데 집중하자. 그리고 예외사항이 발생하지 않도록 관리하는 것이 더 중요한 것 같다.
    오히려 추가할 거면 랭킹 필터링(다승기준, 득점기준 등) 기능이 있는게 나을듯
  —> 요소별 동기화 수준을 정해야겠네!🍉
  - 완전히 동시에 갱신되어야하는 것: 채팅, 유저상태 확인(사이드바), 게임, DM
  - 나머지는 페이지에 접근할 때의 시점을 기준으로 렌더링하면 되지 않을까
    랭킹보기를 누르면 그 때 갱신이 되게끔하면 되는 것 아닌가?
- 전역 변수 관리
  - view 를 한번 만들어 두고 수정하면서 사용?
  - var app = app || { } 을 시도해봤는데 레일즈 환경에서 잘 작동하지 않았음
  - var app = window.app || {} 으로 선언하고, 파일 마지막에 window.app = app으로 정리하면 잘 작동하고 'app'이라는 짧은 키워드로 사용할 수 있다는 장점이 있음. window 객체를 통해 보여진다는 점은 단점임.
  - intertnal.js내에 선언된 app 변수를 이용해서 export/import하는 방식
    **import { app } from './internal'** **export let app = {}**
  - eunhkim: view 객체를 살리는 것은 좋은 것 같고, 그 view 객체를 render해서 삽입된 DOM 요소들은 hide 속성으로 숨기는 것이 아니라, 다른 페이지로 넘어갈 때 삭제해줘야할 것이다.
  - yohai: DOM 요소까지 전부다 들고 있어야할 것 같다.
  - sanam: 모델과 컬렉션은 들고 있어야할 것 같다. DOM 요소는 동적으로 만들고 제거해야할 것 같다.
  - eunhkim: sanam 의견 + sub 뷰는 삭제해야할 것 같다. sub 뷰를 제거하지 않으면 sub 뷰에 걸려있는 이벤트가 다 살아있을텐데, 이런 이벤트가 중복될 것이 걱정된다.
로그인하지 않은 유저에게 게임을 중계할 때, 로그인하지 않은 유저가 connection 인증 단계에서 reject되고 있음. 이 인증 단계를 해제하면 current_user를 활용하여 게임 진행 및 채팅 등 동기화 작업을 정상적으로 수행하기가 어려움. 그러면 선택적으로 커넥션 인증을 진행하여 프라이빗/퍼블릭 채널을 생성할 수 있어야 하는데, 그 과정을 어떻게 해야 할지 모르겠음.
특정 게임의 진행 채널과 중계 채널을 분리할 것인지 아닌지에 대한 결정 필요
사이드바를 네비게이션 밑으로 넣어야 하고, 우측에 고정하면 좋겠음
레일즈 서버와 백본 프론트 통신 API의 명확한 확립 필요 🍉
```
routes.rb에서
api 네임스페이스와 resources 메서드를 활용하면 좋지 않을까! RESTful하게 라우트관리를 하게된다..!
```
예를 들어, 회원가입은 User모델에 대한 RESTful API요청으로, POST 요청을 보내게 될 것이다. 그런데 로그인할 때는 RESTful하지 않은 라우트를 이용하게 될 것이다. 게임이 끝날 경우 업데이트해야할 요소들을 한번에 업데이트하기 위해 각 요소 별로 RESTful 하게 요청을 보내는 것이 아니라, 각 요소별로 업데이트할 내용을 한번에 POST로 보내게 된다. 비 RESTful 요청의 확립이 필요하다.
```
어떤 라우트로 받아서 어떤 것을 리턴한다. <-- 이거 정하고,
이걸 어떤 컨트롤러에서 처리해줄지까지 정해야한다.
```
라우트(백본/레일즈), 모델(백본/레일즈), 컬렉션, 뷰, 채널, 컨트롤러 및 액션, HTML 템플릿 모두에 대한 설계가 필요하다. 🍉
역할을 어떻게 나눌 것인지, 프론트/백의 역할을 전체적 혹은 기능 단위로 구분할 것인지, 레일즈 안에서 모델과 마이그레이션, 그리고 프론트 퍼블리싱(HTML/CSS) 등 특수한 영역에 대해 담당자를 따로 지정할 것인지 🍉
경우의 수!
1. 프론트/백을 전체로 구분
2. 프론트/백을 모듈 단위로 구분
  - Guild 페이지를 만든다!
    Guild 페이지 프론트 task카드 - yohai
    Guild 페이지의 백 task 카드 - iwoo
  - Chat 페이지를 만든다!
    프론트 - sanam
    백 - sanam
3. 프론트/백 구분 없이 모듈 단위로 구분
iwoo: 전체 마이그레이션 담당자처럼 전체 HTML, CSS 담당자가 있어야할 것 같다. 대신 전체 백이나 전체 프론트를 계속 담당하게끔 하는건 학습기회가 박탈된다는 면에서 좋지 않다고 생각한다.
백 프론트는 API가 명확하게 정해있는 상태에서 task가 나눠지고, 이걸 자유롭게 팀원들이 잡고 구현에 들어갈 수 있도록 하면 될듯. 그리고 전체 통일성을 담당하는 담당자는 팀원에게 하나씩 부여되어야할 듯.
작업에 필요한 의사결정의 권한을 해당 작업자/팀이 어디까지 가질 수 있는지, 프로젝트 매니저를 따로 지정하여 권한을 위임할 것인지, 위임한다면 전체 미팅을 통하여 결정할 안건과 매니저에 의한 의사결정 권한을 어떻게 구분할 것인지, 그리고 의사결정의 권한 이외에도 어떤 책임을 가져야 하는지
경우의 수!
1. 다른 모듈에 영향이 가는 것 '무엇을'에 관계된 동작들과 다른 코드가 구현되는 기본구조들-DB 구조, HTML 구조
2. 다른 모듈에 영향이 가지 않는 것 '어떻게'에 관계된 동작들

만약 프로젝트 매니저를 둔다면? 이 사람이 하는 역할은?

task 우선순위 정해서 분배 역할?
- yohai: 이건 경험과 실력이 있는 사람이어야 의미있게 할 수 있을 것 같다. 아래 두 역할을 하는 사람이 프로젝트 매니저가 아닐까.
  - 최종 검토자 역할
  - 어떤 모듈을 추가해야할 때 추가해도 될 것 같다는 의사결정의 역할
- eunhkim: 역할 분배는 42스럽지 않은 것 같다. 하고 싶은 파트를 개발하도록 하는 것이 42 스러움의 최종 모듈로 보인다.
결정권을 가진다?
- 의견충돌 날 법한 것들을 그냥 결정해버릴 수 있다.
- 뭔가 다른 모듈과 협의를 해야하는게 있으면 PM에게 물어본다.

기존의 회의를 통해 의사결정하는 방식-문제 생겼을 때, 걱정되는 것 생기면 회의시간 기다려서 다수결로 정해서 개발하는 방식-을 유지해도 문제가 없다고 생각하는지 일단 궁금하다.
- yohai: 늦어지는 것은 사실 상관없다. 프로젝트를 많이 안해봐서 뭐를 더 선호하고 이런 것은 정해져있지는 않다. 그런데 지금 은휼님이 말씀하신 것처럼 이제 하루에 가장 많은 시간을 쓰는 일이기 때문에 팀원분들의 감정을 충족시키는게 우선이라고 생각을해서 다른 분들이 원하시는 방법이 있으면 충분히 따를 수 있다. (선호) + 오프라인으로 하고 싶다..
- sanam: 1~3일마다 회의를 하는 것은 맞다고 생각하지만 회의가 너무 길어지면 안된다고 생각한다. 회의가 10분, 20분 내로 끝나야한다고 생각한다. 그리고 PM의 역할에 대해서 얘기를 나눴는데, PM의 역할을 생각을 해보면, DB, HTML/CSS 같은 것들에 대한 관리를 PM이 하면 되지 않을까 싶다. 결론적으로 회의로 모든 안건을 정하는 것은 아니라고 생각한다. PM이 조율을 해야한다고 생각한다. (반대)
- jujeong: 찬성(선호)이다. PM이 필요한 이유는 설계와 구성이 다른 문제가 생겼을 때 PM이 의사결정을 해줄 수 있을 것이다. 그런데 문제가 발생하면 문제를 발생시킨 구성원과 관련된 모듈의 구성원과 어차피 회의를 해야하지 않나. PM이 마음대로 정할 수 없는 것 아닌가. 개발하다가 문제가 생기면 연관된 모듈의 개발자와 대화를 나눠서 해결해보고, 회의시간 때 생겼던 이슈와 해결 등을 공유해야할 것 같다.
- eunhkim: 반대. PM을 둬야한다. 회의를 무조건 거친다면 커뮤니케이션 비용이 너무 많아질 것 같다. jujeong님 얘기하신 것에 이어서 얘기한다면, 연관된 모듈만의 문제가 있을 수 있기 때문이다. 특정 모듈과 부딛치지 않는 문제에 대한 의사결정을 빠르게 해야할 필요가 있다. 회의할 때 얘기해야할 것이 많은 것이 보이는데, 너무 혼자서 얘기를 하는 것이 좋다고 생각하지 않는다. 나는 내 입장에서는 우리 프로젝트하는데 이슈가 있어서 얘기를 하는건데 본의아니게 빅마우스가 되는 것이 스트레스를 받는다. 결과적으로 내 의견이 채택되면 영향력을 과도하게 끼치게 되는 것 같아서 부담스럽다.
- iwoo: 비선호. 총대매는 사람 없는 회의는 목적없는 회의로 변질되기 싶다. PM을 두자. 총대를 매는 사람이 있어야한다는 것은 동의한다. 대신 PM이 다른 구성원들을 설득시키려는 노력이 있으면 괜찮을 것 같다. 그렇지 않으면 감정적으로 문제가 생길 것 같고, 빠르게 개떡같은 판단을 내리는 문제가 생길 수 있을 것 같다. 별개로 정기적으로 브리핑을 하는 식으로 이슈가 공유되는 자리가 있으면 좋겠다.
- eunhkim: 그러려면 설득에 대해서 모두가 동의하는 가치가 있어야할 것이다.
기존의 회의를 비선호 하는 사람이 다수결이다. 그럼 어떻게 해결할까?
- 회의는 정기적으로는 있어야한다.
- PM을 두자.
- 모두가 동의하는 가치를 정해놓고 시작하자.
- 세부 사항 🍉
  - 모두가 동의하는 가치(서브젝트, 신속성, 라이브러리 vs 직접 구현, 단순성, 일관성, 테스트 작성과 예외처리, 통제가능성 ...)
    서브젝트(Restful 포함)
    신속성
    안정성(예외 처리)
    가독성s
    구성원의 만족
    단순성
    일관성
    취업에 적용가능성
    학습 가능성
    통제 가능성
    객체지향성
  - PM의 역할
    DB 마이그레이션 관리자, HTML/CSS 관리자 등등
  - PM은 누가 할 것인가
  - 회의 시간
  ㅇㅋㅇㅋ다들 파이팅~!! 👍 🙋🏻‍♂️ 😺
  - iwoo: 백본 추가 학습과 더불어 wpark님 코드를 보고 구조를 생각해보겠다.
  - sanam: semantic UI 학습할 것이다.
  - eunhkim: activeAdmin 공부할 것이다. 장고 어드민처럼 관리자페이지를 바로 만드는 것을 학습해볼 것이다. 콘솔 안들어가고 데이터베이스 내용을 바로 GUI로 보고 처리할 수 있다.
    나머지는 gem list를 보면서 적용할 수 있는 gem이 있는지 확인해보겠다.
  - yohan: SPA 책을 빌려와서 읽어볼 생각이다.
  - jujeong: 백본과 자바스크립트를 다시 한번 봐야할 것 같다. 직접해보니까 잘 생각도 안나고 해서 복습이 필요할 것 같다.

학습 내용에 대한 개인적인 총평

길어지는 미팅을 극혐하지만 나름 의미있는 논의로만 채웠던 것 같다. 학습에 시간을 많이 쓰지 못한 것은 아쉽지만, 팀원들의 감정적인 면이 충족되려면 본 프로젝트를 본격적으로 시작하기 전에 이런 식으로 의견을 모으는 절차가 필요할 것이다.

불필요한 의사결정 지연을 줄이고 방향을 제대로 유지하기 위해 1) 모두가 동의하는 가치를 정하고 2) PM 역할을 하는 사람을 정하기로 했다. 모두가 동의하는 가치가 명확히 정해지면 PM 역할이 불필요하다고 생각할 수도 있겠지만, 그럼에도 PM은 있어야한다고 생각한다. 무슨 일이든 '책임 지는 한 사람'이 있어야 제대로 돌아간다고 믿는다. 그래야 '책임 지는 한 사람'이 일이 되게 만들기 마련이기 때문이다.

다음 학습 계획

Backbone의 sub-view 관리 방법 확인
협업 규칙 등 관리하는데 필요한 툴 정해보기

Previous2021-01-23(Sat)Next2021-01-20(Wed)

Last updated 3 years ago