Created by 고주형, last modified on 5월 30, 2022

(파란별) Index

(파란별) Date

의 회의록 마스터 : 고주형

(파란별) Participants

TEAM FIRE (윤영기 고주형 이하령) + @정원용멘토님

(파란별) Assignment

1. 페르소나로 나온 결과물

  • 겪고있는 문제 정의 

  • 기능 정의

    • 우리 기능으로 해결

  • 우선 순위 정의 

    • 우선 순위적으로 선택할 기능

    • 우선적으로 MVP에 들어갈 기능

    • 합의

2. Information Archtecture

3. UI(화면) 기획

4. 화면 기준으로 사용자 스토리 작성

5. 기획서 작성

  • 개발 동기, 목적 등 넣어서

(파란별) Discussion topics

페어 프로그래밍한 썰

멘토님께 페어프로그래밍 한 Fire introduce 소개

이번 페어 프로그래밍은 성공적이었다

  • 단순히 보이스 채널 줄어서만이 아님

  • 저번에 하던 개발 이어서해서 원활하다

  • 환경 세팅 안 해도 됐었음

문제점을 회고를 할 때를 떠올리며 개선점으로 반영하자

실제 개발 

  • 속도가 느린 사람 위주로 진도 나감

오늘은 스터디를 위한 페어 프로그래밍

 = 정보전달

 = 그래서 원활

페어 프로그래밍에 대한 고찰

페어 프어프로그래밍을 왜할까?

  • 잘하는 사람이 못하는 사람을 챙긴다

  • 굉장히 중요한 로직이어서 한다

    • 동등한 사람이 같이

    • 네비게이터와 드라이버는 수시로 바뀜

페어 프로그래밍 경험담

  • 코드를 추가한 쪽에서 장애/개선사항

    • 서로 교류 얘기 

    • 해당 부분 정리

  • 동등하게 같이 VS 선후배

    • 후자가 월등히 많다 

가르쳐주기 위해서 페어프로그래밍

  • 못하는 사람이 Key를 잡는다

  • 잘하는 사람이 막힐 때 거들어준다 

상황에 따라 개선안을 계속 반영

  • 잘하는 사람이 키를 쥔다

주로 이렇게 간다

테스트 케이스는 안목이 있는 사람은 인터페이스를 짠다

  1. 구현하는 코드를 수도코드를 만든다
    = 맥락 공유가 된다

  2. 인터페이스에 대한 합의가 이루어 진다

  3. 구현체가 만들어진다

페어 프로그래밍을 하는 맥락은 다양하다 

  1. 같은 맥락을 아는 사람이 있을 수도 있고 없을 수도 있다

  2. 베이스를 같이 만드는 상황

    • 시니어가 주니어를 도와주는 상황일 수도 있다

시니어 입장에서의 페어 프로그래밍 

  • 베이스 후딱

  • 케이스 만든다

  • 그리고 빠짐

코드 베이스의 유무

  • 베이스 있냐 없냐에 따라 드라이버가 갈린다 

  • 우리가 한 페어프로그래밍은 베이스가 없는 상태에서 한 것 

언제 간섭(조언)해야 할 까요?

원포인트 얘기

  • 시기적으로 뀌냐

  • 막힐 때 뀌어드냐

의문

상하관계가 있다면 드라이버가 잘 물어볼까?

  • 동등한 입장(서로가 존중)이어야 한다 

주니어가 시니어의 코드에 뭐라 할 수 있을까

  • 중간에 놓치고 이해를 못하게 될 수도

  • 코드의 복잡도가 높다면 ?

    • 화면을 함수를 왔다갔다하는 순간 길을 잃어버린다 

주니어가 시니어의 코드를 따라갈 수 있을까?

자연스럽게 이럴 것

  • 주니어 개발자 입장

    • 아 일단 알겠습니다

    • 나중에 코드 베이스 이해한다

소통이 없다면?

  • 어디 잘하냐 보자

  • 감시

페어 프로그래밍

 = 코드로서 합의하는 것

 = 의견 교류 적극적으로 하자는 마인드 

페어 프로그래밍 기능 구상

페어 프로그래밍은?

  • 사상적 

  • 모르는 것 적극적으로 그때 그때 물어보게

  • 적극적인 마인드를 유도

만약 코드를 놓쳤다면?

  • 앞으로 되돌리기 기능 

  • 코드 에디터의 UNDO

    • Cursor 수준으로 

    • 필요하다면 오디오 

  • STT

동영상 강의에서 모르면 어떻게 해?

  • 되돌아가기 가능

VS Code에 replay 기능

시니어가 주니어에게 제공해주면 아주 좋을 것

터미널은?

  • History

  • 덤프 

만약 컨텍스트 지식 목적이 동일하다면 과연 페어 프로그래밍하는게 도움이 되었을까?

맥락 공유

  • 코드 리뷰만으로도 가능

집중도 상승

애자일

그 조직의 리더가 얼마나 기민한 방법으로 우리를 이끌어가고 싶냐. 그런 것의 방법론 중의 하나.

애자일이란?

  • 빠른 실패

  • 저렴한 실패

  • 조직원들이 실패에 유연한 생각을 하게 하자

  • 프로젝트 말미에 실패를 심각하게 생각

  • 초반 결정 

    • 시행착오 기간 줄임

    • 비용 싸

    • 거기에 참여하는 사람의 번아웃을 막아줌

      • 거기에 참여하는 사람은 이게 잘 못 됐다는 것을 알고 있을 것이기 때문 

      • 우리의 단면을 빠르게 확인할 수 있다

  • 거기에 발맞춰 나오는 도구

    • 주기를 갖게끔 하는 도구

    • 예전부터 계속 짧아짐

      • 3달

      • 1달

      • 2주 

    • 풀고자 하는 문제가 점점 마이크로

    • 빨리 해결하자 

    • 조직 운영 바뀜

    • 개발 방법론도 마이크로하게 바뀜

애자일 도입 vs XP 도입

  • 관리자와 개발 책임자가 항상 같지는 않다 

  • 애자일은 조직 리더의 사상

  • XP은 개발 책임자(테크 리더)의 조직 문화

    • 역량 교류 방법

애자일 도입은 빠르게 Burn-in되지 않으면서 진행된다

  • 기본 요건 충족

  • 사람의 마음을 불편하지 않게 하면서 

  • 누군가를 나를 관리한다 Vs 내가 관리 받고 있네는 다름

PP는 사실 애자일은 방법론에서 나오긴 했지만 다르다!  

애자일이 아니어도 짝 프로그래밍은 유효하다!

코드 리뷰

하위에 있는 컴포넌트는 모두 갱신된다 

문제: 하위에 있는 컴포넌트는 손헤다

해결: 메모이제이션, 수정되지 않으면 렌더링되지 않는다 

클래스에 따라 반응하게 만들어라

  • styled는 정적

  • 부트스트랩은 이런 스타일에 대해서 다 미리 정의가 되어있다

    • 클래스명만 알맞게 넣으면 다 처리할 수 있다

  • 이렇게 깔끔하면서 최소단위를 유지하려면 부스트스트랩

    • 리액트는 mui쓰면 적절하다

개인적 권장 

  • source폴더 밑에 common.json or global.json

    • 상수들을 넣는다 

    • 그 컴포넌트에서 

      • 특정 기능 on off

      • 팝업 on off

      • 등

    • 데이터 기준으로해서 의사소통이 원활해짐

  • 폴더명은 소문자로 

  • 컴포넌트의 크기 

  • 화면에 따라서 다르게 하는 것이 리액트

    • Atomic Design Pattern

      • 나중에 스토리북 사용시 아토믹 너무 작으면 몰리큘 수준으로 가자!

코드 리뷰 결론

  • 각 컴포넌트 리랜더링 줄이기 위해 메모 

  • 클래스를 쓰자

  • 글로벌 설정을 하나 두자

만약 더한다면?

  • DB에서 받아오자 

  • 리액트: 상태 관리 

더 리서치가 필요한 것은?

애자일이냐 

  • 아이디어를 좁힐 시기이다

타겟이 누구냐

페르소나(몇 개만 선정)

  • 멘토 멘티

    • 시니어와 주니어

    • 기술 수준 차이가 가장 적합

  • 다루는 기술의 범위가 다른 경우

    • 한 사람이 한 사람이 지원

  • 회사 업무 맥락 공유

우리는 어느정도 교육적인 목적으로 공감대를 많이 가질 수 있다.

질문

우리 MVP 가능? (하령님 질문)

화면 > 핵심기능 > 아이디어 창출 > 누구를 위해(퍼소나)

프론트엔드 기술장벽

어떻게 의사결정하냐에 따라서 달라진다

  • 문제점이 나와야 할 수 있다 

    • 지난번 회고를 봐라

      • 환경 설정

      • 인원

      • 소통

      • 더 파고 들어봐!

  • 라이브 에디팅

  • 히스토리

결국은 소통

자막, 라이브 에디팅

코드리뷰

기능들 

  • 커서 기능

  • 화면 넘기기

전후맥락이 필요하다

  • 무언가를 남기고자 한 멘트

  • 어떤 위치에 어떤 순으로 남겨

되돌아보려면 동영상이 필요!

  • 동영상은 전후맥락 파악 불가

새로운 아이디어

메타데이터를 재생만 시켜줄 수 있다면?

재생 누르다가 잠시 멈춰서 전후맥락 파악할 수 있게

멘토님 결정

  • 김태완 멘토님

  • 양수열 멘토님

    • JCO 회장 / 자바 챔피언

    • (이메일 발송 완료)

    • 설득

      • 온라인으로 해도 되니깐 맡아만 주세요!!

      • 가끔식 좋은 얘기만 해주세요.  

  • 최광선 멘토님

    • VC 

  • 창업자님께 멘토님

백엔드 기술스택

예상 

  • STUN 서버와 TURN 서버 오픈소스 확인 

  • 미디어 서버 있을 것

Signal Server를 만들 때 기술 스택 제안

숙제(다음의 방향성)

"기획 멘토님 섭외해서 수행"

  • 충분히 합의 

  • 그분에게 UI/UX 가지고 가면 

1. 페르소나로 나온 결과물

  • 겪고있는 문제 정의 

  • 기능 정의

    • 우리 기능으로 해결

  • 우선 순위 정의 

    • 우선 순위적으로 선택할 기능

    • 합의

2. Information Archtecture

3. UI(화면) 기획

4. 화면 기준으로 사용자 스토리 작성

5. 기획서 작성

  • 개발 동기, 목적 등 넣어서

다음주 

숙제

기획 멘토링

페르소나 문제 + 기능 정의를 1차적으로 하고 기획멘토님께 상담

  • 페르소나 기반 브레인스토밍을 하고 싶다. (브레인스토밍하면 우선순위 나옴)

  • 함께 아이디어 도출을 하자

  • 거기서 나온 아이디어를 쫙 열람해서 우선 순위를 정하자

  • 나머지는 개발하면 될 것!

아직까지 의문점 많다

“합의해야 진도를 나간다“

  1. 이게 맞나요? -> 페르소나 만들며 회의 합의로 해결

    1. 합의해야 진도 나감

    2. 가설과 실제 솔루션은 다를 수 있다

  2. 이게 맞네요. -> ...

다음에는? 

MVP 기획서를 만들어 오자 

  • 다음에는 MVP 만들 수 있는 수준으로 준비하자

  • MVP를 보며 리뷰하는 시간 가지자!

혹시 어려움 있으면 멘토님께 도움!

STUN 서버/TURN 서버 문서화 및 리뷰 

기획서 양식 나올 것

  • 채울 수 있으면 채워오자

다음에는 이런을 얘기하자

  • 기획 자료조사

  • 기획 어떻게 마무리할까

    • 기존 MVP 기획서에 살을 붙여서 마무리하자