Skip to content

5주차 화요일 회의록

ji3427 edited this page Dec 18, 2020 · 1 revision

오늘의 할 일

  1. 발표 대본 완성 - 재익, 경수
  2. PPT 완성 - 화영, 승효
  3. 예제 이름 변경 ⇒ 발표 자료 link
  4. 공식문서 예제 페이지 제외하고 완성
  5. 버그 리포트 업데이트

빠시부 - 화영

목요일 4시까지는 PPT 완성해서 보내야 됨

템플릿은 상관이 없습니다

에피소드냐 기술이냐

→ 부분적으로 가져왔을때 어색하거나 붕 뜨는 느낌 있을 수 있다 (기승전결이 완벽하지 않아서)

열심히 회의했던 부분, 가져와도 되지 않을까?

기술 100% (너무 TIL 느낌) vs. 일화 100% (너무 일기 느낌)

개발자 분들이 어떤 것을 들으러 올까?

  • 기술적으로 잘하는 사람
  • 팀에 잘 섞이는 사람
    • 토의
    • 기술적 부분

질문할 여지를 남겨놓을 수 있는 발표를 하자

  • 발표 시간은 부족하다. 우리가 역으로 질문을 받고 싶은 내용을 던져 놓자.

질문

어떻게 발표하면 좋을까요?

  1. 기술 100%

    • 개발을 진행하면서 겪었던 버그들과 그것들을 해결해나가는 과정들을 설명
    • 팀원들과 겪었던 에피소드나 기술외적으로 문제를 해결해나가는 경험등을 이야기해서 커뮤니케이션 능력도 보여주면 좋겠다는 의견이 있음
    • 너무 기술적인 이야기를 하면 분위기가 Down될 것 같음 (오히려 좋아할까?)

    → 타임라인 순으로 경험적인 부분을 녹여서 설명

  2. 경험 50% 기술 50%

    • 1번과 3번 (기술과 경험)을 적절히 섞어서 설명
    • 하지만, 짧은 발표 시간 제한이 있어 두 개 다 충분히 설명하지 못할 것 같음 (발표는 7분!!)
    • 갑자기 경험 얘기하다가 기술적인 용어들이 등장하면 어색한 느낌이 있었음 (기승전결을 완벽히 다룰 수 없기 때문에)
  3. 경험 100%

    • 팀원들과 있었던 일들이나 기술 외적으로 문제를 고민한 일들을 설명했음
    • 어제 발표 자료를 다 만들기는 했으나 너무 일기 같음. → 일기 같아서 3번은 안하기로 결정
    • 기술적으로 어떤 부분을 고민했는지는 설명이 거의 없었음
    • 다른 팀들 보다 다양한 사건사고들이 있어 발표할 이야깃거리가 존재함

고민중인 내용 🤔

요약하면, 기술만 말하면 TIL 같고 경험만 말하면 다이어리 같아서 문제.

그렇다고 합치자니 어느 비율로 섞어야 할지도 고민이고, 7분이라는 시간이 너무 부족하게 느껴집니다.

저희보다 그 기술에 능숙한, 선배 개발자 분들이실텐데 기술적인 얘기만 하는 게 재밌을까 싶고,

반대로 기술적인 이야기를 했을 때 선배 개발자 분들이 "대견하다"고 생각할지. 반응을 예측할 수가 없음.


발표자료: 부스트액트

무슨 의도냐 ?!?!

honux님과의 멘토링

기술 100% 이지만 경험도 살짝 간 치는

  • 개발을 진행하면서 겪었던 버그들과 그것들을 해결해나가는 과정들을 설명
  • 팀원들과 겪었던 에피소드나 기술외적으로 문제를 해결해나가는 경험등을 이야기해서 커뮤니케이션 능력도 보여주면 좋겠다는 의견이 있음
  • 너무 기술적인 이야기를 하면 분위기가 Down될 것 같음 (오히려 좋아할까?)

→ 타임라인 순으로 경험적인 부분을 녹여서 설명

잘싸웠다.. ! 라는 거 뿜뿜 티내기

인상적인 것 중에 인상적인 것 (1개 혹은 2개) 에피소드를 메인으로 녹여내기

팀 폭파 사건으로 결정 시 운영진에게 dm 하기

데모: 충분히 천천히, 연습 많이, 1분 정도 보여주면 될 것 같음

코드: playground, codesandbox (고려)

제 3자의 입장에서 생각

좋은 프레임워크란 무엇인지? 그걸 만들기 위해서 어떤 노력을 했는지?

유저의 입장에서 사용할 수 있는 것인지?

겪은 문제 (프레임 워크 << 위주로 )

나중에 블로그 정리도 합시다

임시 대본

  1. 타이머로 7분 재는 것 시작

    발표 전에 F11 눌러놓기!!!!!

    • 발표 시작하나요? 발표 시작하기 전에 7분 타이머가 우측 상단에 있는데요, 7분 지나면 자동으로 QnA 페이지로 가니까 놀라지 말아유. 그럼 바로 시작하도록 하겠습니다.
    • 안녕하십니까, 자유프로젝트-D-Boostact팀 발표를 맡은 심재익입니다. 저희는 4주동안 framework를 만들었고, 그간의 경험을 소개해드리도록 하겠습니다.
  2. 우리 팀이 터지게 된 것 ( 불가피한 사정으로 팀 프로젝트가 변경 )

    • 저희가 불가피한 사정으로 중간에 자유 프로젝트로 변경이 됐었어요. 다행히 초반이었지만, 저희가 새 주제를 정할 필요가 있었어요. 그래서 뭘 할까 생각을 해봤는데,
  3. 왜 우리는 부스트액트를 하기로 했을까?

    • 아무래도 저희 팀원들이 다 바닐라 스크립트를 deep하게 다뤄보고 싶었던 거 같아요. 웹 기술은 빠르게 변한다고 하잖아요?
    • 그래서 일단 기본이 되는 바닐라 스크립트에 더 비중을 두고 싶었던 거죠 . 근데 그렇다고 저희가 프레임워크를 등한시할 수도 없으니까, 아예 프레임워크를 만들어보는 건 어떨까 생각했어요.
  4. 우리가 원하는 부스트액트는?

    • 그래서 저희는 일차적으로, 프레임워크의 기준을 잡았어요. 아, 이정도는 되야 우리가 프레임워크를 만들었다 라고 말할만한 기준들인데요. 첫째는 리액트의 jsx나 hook 기능을 구현해야 한다고 생각했고. 둘째는 상태관리와 가상돔을 통한 렌더링이었고요, 마지막으로, 그래도 SPA를 위해 라우팅은 되야한다고 봤어요.
    • 이제 저희는 여기까지만 정하면, 되게 순탄하게 잘 풀릴 줄 알았어요. 그런데 막상 시작하고 나니 산적한 문제가 많더라고요. 일단 저희 중에 React를 잘 다룰 줄 아는 사람이 없었어요.
    • 기술적 도전을 원하는 개발자들.... (해봤으면 도전이 아니었겠지.)
    • 그래서 이게 더 기술적 도전이 될 수 있다는 생각도 있었어요. 누군가 해봤다면 그 사람한테는 기술적인 도전이 될 수 없잖아요? 차라리 아무도 안해봤을, 특별한 도전을 해보고 싶었어요.
    • 다음은 저희가 실제로 구현하면서 겪은 ****문제들을 소개하려고 해요.
  5. 우리가 겪은 문제

    • 저희가 겪은 문제는 많지만, 개발자라면 누구나 겪어봤을 문제들을 가지고 와봤어요. 하나는 텍스트 노드에 null이나 undefined가 들어가는 것을 예외처리하려고 if 문에 느낌표를 써서 처리를 했는데, "0"이라는 텍스트를 쓰면 터지는 문제가 있더라구요. 사소한 오류였고요,

    페이지 이동

    • 또 삭제 로직이 제대로 동작하지 않는 문제도 있었어요. 저희가 아무리 봐도 이유를 알 수 없어서 결국 저희가 만든 로직을 다 뜯어 봤었어요. 근데 알고보니 "삭제"라는 영단어 스펠링을 틀렸더라구요. 사실 문제가 없던 코드였는데 아주 오랜 시간을 들인 문제였어요. 이 기회를 통해서 매직 string을 지우는게 유지보수 관점에서 굉장히 중요하다는 것도 배웠습니다.
    • 또 문법 때문에 발생한 문제도 있었어요. 최신 문법이면 무조건 좋다 생각해서 옵셔널 체이닝(?.)도 넣었었는데, 바벨에서는 별도의 플러그인을 넣지 않으면 옵셔널 체이닝을 처리해주지 않더라구요. 있어보인다고 무조건 최신 꺼를 쓸 필요는 없다는 것도 배웠고요,
    1. 1분마다 터지는 타이머 null과 undefined를 처리하려고 if문에 !연산자를 썼는데, 숫자 0을 textElement에 쓰면 터져버렸다.

    2. Delection이 맞는 줄 알았는데 Deletion이었다. 삭제 로직이 동작하지 않는 줄 알고 다 뜯어봄.

    3. ?. 호환 X → webpack 문제인 줄 알았는데 우리가 쓰는 바벨과 node version이 호환되지 않아서 발생한 문제였음.

      • ?.를 처리하기 위해서는 바벨에 따로 플러그인을 넣어줘야 함
      {
        "plugins": ["@babel/plugin-proposal-optional-chaining"]
      }
  6. 우리가 뭘 배웠는지?

    • 이번에는 저희가 프로젝트를 통해 뭘 배웠는지를 말씀해드리도록 할게요.

    • 저희 프로젝트가 평소에는 해보기 힘든 경험이잖아요? 그래서 더 특별했던 거 같아요. 리액트를 사용하는 시점에서는 생각할 필요도 없었고, 애초에 이런 게 문제가 된다거나, 토론 주제가 될 수 있다는 생각도 없었어요. 그냥 당연하다고 생각했던 것들인데도 구현을 하다 보니까 여러가지를 고민을 하게 되더라구요.

    • 처음에는 저희가 렌더링을 구현을 했는데 구현하면서 여러가지 고민들이 생기기 시작했어요

    • jsx를 html로 바꾸는 방법을 고민하다가 createElement같은 함수의 존재를 알게 되었고, 가상 DOM이 왜 필요한지도 느끼게 되었어요. 또 가상돔의 diff 알고리즘 최적화를 위해서 특정 node의 정확한 위치를 알아내는 방법과 리액트에 존재하는 key attribute가 왜 필요하고 어떻게 구현할지를 고민했어요.

    • 다음으로 상태관리를 구현하면서 생긴 고민들인데요, state hook이 node의 위치는 어떻게 기억하고, 어떻게 값을 저장하는지에 대해서도 고민을 했고 effect hook은 어느 시점에 호출되고 상태변화를 어떻게 감지해야할지에 대해서도 고민했어요. 이 이외에도 이벤트 위임이나 라우팅에 대해서 많은 고민을 하게 됐죠.

    • 앞서말했던거 처럼 지금까지 아무 의심 없이 사용하던 것들을 다시 생각하게 되는 좋은 기회였던것 같아요.

    • 가상돔이 어떻게 동작하는지.

    • 특정 node의 위치를 어떻게 알아내는지 (DB auto increment를 DOM에 적용해보기)

    • jsx가 어떻게 html로 변화하는지.

    • 렌더링 될 때 어떻게 훅 상태가 이전과 똑같이 들어가는지

    • HTML에서 엘리먼트가 시작하는 시점, 끝나는 시점. → Provider 때문에 이런 문제가 존재한다는 걸 알게 되었음.

    • 리액트에 존재하는 key attribute 기능을 어떻게 구현할지

    • 다른 프레임워크들이 왜 이벤트 위임을 사용하는지

    • 우리가 고민한 게 되게 많았는데, 여기서 해결이 된 것도 있고, 아직 해결이 안 된 부분도 있지만, 저희가 했던 고민들을 나열해봤어요. 가상돔이 어떻게 동작하는지, 특정 node의 정확한 위치는 어떻게 알아내는지, jsx 가 html로 어떻게 바뀌는지, 렌더링이 된 후에도 hook이 node의 위치는 어떻게 기억하고, 리액트에 존재하는 key attribute는 어떻게 구현할지. 또 마지막으로 프레임워크들은 왜 이벤트 위임을 사용하고 있는지.

    • 지금까지 아무 의심 없이 사용하던 것들을 점검해보는 시간이 되었어요.

  7. 투두리스트 예제.

    • 저희가 부스트액트를 이용해 만든 걸 몇 개 보여드리려고 해요. 문법은 리액트와 동일하게 만든 걸 볼 수 있고요, 동작도 잘 되고요. (몇 번 만져보는 거 보여주고)
    • 저희가 부스트액트로 만든 부스트액트 공식문서도 있고요, 저희가 만든 부스트액트가 동작한다는 것을 확인할 수 있을 거 같아요.
      • 투두리스트 말고 또 다른 거 있는지 더 고민해보기
  8. 프로젝트를 통해 깨달은 점

    • 마지막으로 저희가 프로젝트를 통해 깨달은 점이에요.
    • 개구리를 해부하는 것보다 개구리를 만드는 게 개구리를 이해하는 데 도움이 된다는 것.
    • 자동차를 만든다고 운전을 잘하는 것은 아니라는 것 → 그래도 운전을 이전보다는 잘하겠죠? ㅋ
    • 많은 걸 배울 수 있는 프로젝트였고, 참 즐거웠던 거 같아요. 부스트캠프가 끝나더라도, 산적한 문제들이나마 더 해결해보려고 해요. 저희 프로젝트 관심 가져주시고요, 컨트리뷰션도 가능하니깐 참여 많이 해주세요. :)))
    • 이상으로 발표 마치겠습니다. :))))))))

대본

안녕하십니까, 자유프로젝트-D-Boostact팀 발표를 맡은 심재익입니다. 저희는 4주동안 framework를 만들었고, 그간의 경험을 소개해드리도록 하겠습니다.

React Framework를 사용할 줄 아는 것과, 그 근간이 되는 Vanilla Script를 잘 다루는 것 중 어느 쪽이 더 중요한지는 개발자마다 다른것 같습니다. 저희는 바닐라 스크립트가 더 중요하다고 생각했습니다. 그 이유는, 기술의 트렌드는 빠르게 변하는 반면 그 기술의 근간은 잘 바뀌지 않기 때문입니다. 따라서 저희는 리액트의 근간이 되는 바닐라 스크립트와, 프레임워크의 동작 원리를 이해해보고자 했습니다.

저희는 프레임워크를 만들 때, 다음과 같은 기능들은 필수적으로 구현되어야 한다고 생각했습니다. 첫 번째로, 리액트에 있는 jsx나 hook 기능들을 지원해야 한다고 생각했습니다. 두 번째로, 프레임워크에 있어서 필수적인 기능인, 상태관리와 가상돔을 통한 렌더링이 되어야한다고 생각했습니다. 마지막으로, SPA에서의 라우팅을 지원해야 한다고 생각했습니다.

저희가 프로젝트를 진행하면서 겪었던 기술적으로 어려웠던 부분들을 소개해드리도록 하겠습니다.

5~~


저희가 프로젝트를 마무리하고나서 아쉬웠던 부분들이 있었는데요, 이들을 앞으로의 과제로 두고 해결할 예정입니다. 예정된 과제로는 Node에 key값을 넣어서 자리를 바꾸는 로직을 만들어, 렌더링을 더 효율적으로 하는 것, 현재 라우팅 쪽에서 외부 라이브러리를 사용하고 있는데, 자체적인 라우팅을 구현하는 것, 코드를 모듈화 하는것, 테스트 코드 작성, 예외, 에러처리를 하는것들이 있습니다.

오늘 해야할것

  • 프레젠테이션?
  • 페이지 구성
    • 시작 버튼
    • 우측에 시계
    • up/down 버튼 되는지 확인
    • 시작 페이지 & 프레젠테이션 템플릿

팀원소개 + 데모

route, component(page),

Clone this wiki locally