FE 유튜브 미션 비교 회고 | 2022.03.18.

[woowapark]

목표

• 문제에 접근하는 방식, 해결 방법을 찾아나가는 방식에 대한 나의 고민&생각의 변화 과정을 돌아본다
• 다음 미션에서 문제를 해결할 때 적용해 보고 싶은 나만의 시도를 준비한다

MVC에서 벗어나 ‘문제를 먼저' 마주해보려 애쓴 이번 미션, 
어떤 점이 달라졌나요?

• (1) 각자가 새로운 페어와 함께, 새로운 미션을 진행하면서, 새롭게 생각하게 된 내용이 있다면 로또 미션에서의 경험과 비교해보며 나누어주세요.
• (2) 다음 미션에서는 어떻게 문제에 접근해볼 것 같나요?

체크 사항

• ✅ 페어 당 1개의 코멘트에 함께 논의한 내용을 작성하여 공유해주세요.
• ✅ '어떤 생각과 고민의 과정을 거쳤는 지'가 잘 드러날 수 있게 이야기를 나누고 글로도 적어주세요.
• ✅ 이야기 나눈 내용을 바탕으로 다음 미션에서 적용해볼 한 가지를 적어주세요

질문 예시

돌아보고, 준비하기.pdf

[KangYunHo1221]

• 나인

• 지난 페어 때 비녀가 해준 피드백을 곱씹으며 이번 페어 프로그래밍을 진행했습니다.

  • 코딩 할 때 자신의 의견 잘 말하기 (네무새, 좋아요무새 not good)
  • Grid 사용 (완전 좋아요~)

• 비녀 덕분에 제가 진화? 했음을 느꼈습니다. 토론을 엄청 해서 늦게 잘 정도로 서로 의견을 많이 주고 받고 고치고 그랬습니다!

• 지난 로또 때 MVC 패턴을 사용했었는데 이번 미션에서는 이를 벗어나고자 노력했습니다. 비녀도 마찬가지로 벗어나기 위해 Componenet 기준으로 개발을 했는데요, 저도 그러기 위해 노력했으나 EventHandler라는 클래스가 생기면서 약간 Controller의 역할을 하게 된 것 같아요. 이 부분은 좀 아쉽습니다.

• 비녀
  선조의 지혜,,, mvc 너무 멋진 것 같다. 하다보니까 mvc가 그리워지는 느낌이었다.
  로또미션으로 다시 돌아간다고 해도 mvc 사랑해요.
  다만 내가 새로운 방식으로 도전해보면서 배우는 과정이 즐거웠고, 새 페어와 어떻게 구조를 짤지 토론하는 과정은 더 즐거웠다.
  css와 class를 쪼개면서 관리하는것이 직관적이라 이해하기 좋은 코드를 짜려고 노력한 나 자신을 칭찬한다.
  다만 step2로 올라가면서 새로운 기능 추가하면서 구조를 계속 바꿔나갔기 때문에,
  다음 미션에서는 확장성과 야근이의 원만한 합의를 이끄는 방식으로 접근하고 싶다.

[jhy979]

비녀 또 해요 페어 ㅋㅋ

[KangYunHo1221]

ㅋㅋㅋ 주사위 신의 가호가 있기를

[LAH1203]

각자 이번 미션에서 적용해본 구조

코카콜라(펩시)

눈에 바로 보이는 느낌으로 페이지 파일을 만들어서 각 페이지 파일 안에 필요한(렌더링) 요소들을 추가하는 방식으로 구현을 했습니다. 각 페이지에 필요한 기능, 이벤트 등도 해당 페이지 파일에 추가해서 구현을 했습니다.

• 록바 : 파일구조에서도 물씬 리액트 느낌이 났다. 또한 view를 렌더하는 과정에서도 데이터를 가지고 조건을 걸어 다르게 렌더하는 방식이 신선했다.
• 하리 : 우선은 자바스크립트로도 이렇게 할 수 있구나란 생각이 들었다. 코드가 전체적으로 깔끔했고, 구조 자체도 좋았다.

록바

도메인과 UI만을 분리를 하였습니다. 도메인은 간단히 검색을 담당하는 엔진과 검색한 결과를 저장하는 엔진으로 구성하였습니다. UI는 도메인을 바탕으로 가져온 데이터를 렌더하는 파일로 구성되어있습니다.

• 콜라: 간결하게 딱 필요한 부분만 분리를 한 게 눈에 보였다. 특히 screen디렉토리 안에 UI 파일들을 각 역할마다 나눠 놓은게 인상 깊다.
• 하리 : 도메인에서 Engine을 사용했던 부분이 가장 기억에 남는다. 도메인과 UI를 분리하는 것도 깔끔하게 해준 것 같아서 코드를 파악하기에도 좋았다. 테스트 코드도 신경 써서 작성한 것이 많이 보였다.

하리

패턴 사용을 하지 말아보자는 의견이 페어와 맞아 요구사항에 맞게 간단하게 도메인과 UI로만 분리를 해보았습니다. 도메인에서는 간단하게 Web Storage에 관여하는 부분과 API를 요청하는 부분이 들어있고, 그 외 나머지 화면과 관련된 부분은 UI에 포함되어 있습니다.

• 콜라: 기능 적인 부분을 재사용 가능 하게끔 잘 만들어 둔게 눈에 띈다. 특히 스켈레톤 UI 렌더링 부분이 아직도 기억에 남는다.
• 록바: 전체적으로 파일 네이밍 뿐만 아니라, 코드를 잘 분리한 것 같다. 특히 skeleton UI를 따로 빼서 관리한게 괜찮은 아이디어 같다. 코드를 쓱 봤는데도, 코드를 짜는데 신경을 썼구나가 느껴졌다.

---

다음 미션에서는 어떻게 바라볼 것인가

코카콜라(펩시)

음...고민 중이다. 다음 미션은 타입스크립트를 사용한다고 하던데, 그때가서 생각나는 데로 페어분과 의식의 흐름으로 코드를 작성 할 것이다. (이번 미션도 의식의 흐름으로 코드 작성을 시작했다.)

록바

다음 미션은 아직 깊게 생각해 보지 않았지만, 좀 신선한 방식을 도입해보고 싶다. 다음 미션이 UI도 많고, 중복되는 부분이 많아 보이던데, 그것에 알맞은 설계를 해 볼 생각이다.

하리

아마 프로젝트 규모에 따라 짜는 방식이 달라질 것 같다. 이번에는 소규모이니만큼 패턴을 버려보자는 목적에 맞게 단순히 도메인과 UI로만 분리를 했지만, 다른 크루들이 한 것을 보니 정말 다양한 구조가 많았던 것 같다.

[jin7969]

이번 미션, 어떤 점이 달라졌나요?

• 안 : 로또 미션에서는 mvc패턴으로 구조를 설계 하였는데, 이번 유튜브 미션에서는 그런 패턴이 없이 ui,domain으로 분리를 하여서
  편하게 구현을 할 수 있었다. 하지만 나중에 구조를 생각해야 해서 고민도 든다.
• 코이 : 유튜브 미션에서는 mvc 패턴을 버리려고 했고, 하고싶은대로 만들어봤다. 검색창부분, 결과창 부분 등으로 나누어서 클래스를 짰는데, 한 클래스의 변화를 다른 클래스에서 어떻게 적용할 것인가에 대해 고민하였다. 따라서 manager를 하나 두고 이걸 통해서 변화가 일어나는 것을 감지하게 구현하였다.

다음 미션은 어떻게 접근해서 해결해나가면 좋을까요?

• 안 : 처음에는 유튜브 미션과 똑같이 구조에 대한 생각 없이 하면 되지 않을까? 했었는데, 코이의 의견을 듣고 보니 큰 그림을 어는 정도 잡고 구현을 하는 것도 좋다고 생각된다!!
• 코이 : 이번 미션에서 페어와 코드를 작성하기 전에 구조를 어떻게 잡을지, 파일은 어떻게 나눌지 먼저 고민을 많이했고 이야기를 많이 해봤는데 도움이 되었다. 다음 미션에서도 페어와 어떻게 접근할지 이야기를 많이해보고 틀을 잡으면 좋을것같다.

[KangYunHo1221]

코이 화이팅

[jin7969]

비녀 화이팅!!

[nan-noo]

블링, 태태

어떤 점이 달라졌나요?

• 블링: MVC에서 벗어났지만 뭔가 MVC로 돌아가는 듯한 느낌..? 재사용할 수 있는 부분들을 분리해서 재사용 연습을 하고 있음.
• 태태: MVC 버리고 기능 단위로 분리함.

유튜브 미션 하면서 했던 고민

• 블링: 구조적인 것을 먼저 보지않고 정리하다 보니, 결국 MVC가 보이는 느낌이었다.
• 태태: 소단위 기능을 어떻게 하면 더 깔끔하게 작성할 수 있는지 중점으로 고민. 렌더링
• 공통: api를 사용하면서 테스트를 어떻게 작성해야 하는지 고민이 많았다.

다음 미션에선 어떻게 할까?

• 블링: 리액트 느낌으로 직접 구현해보는 연습..!
• 태태: 도메인 분리 연습 더 해야지

[juunzzi]

준찌 - (1) 과거 미션과 비교하기

• 이 상태가 변경되면 등록된 컴포넌트 들에게 알리고, 그들이 각자의 파트를 재 렌더링 하도록 한다. 아이디어에만 주목하여 개발을 진행하였습니다.
• 하위 모듈들을 차례차례 개발(모듈에 대한 설계) - Bottom Up 하게 (어떤 모듈이 어떤 상위 모듈에서 어떻게 쓰이는지 정도는 설계를 해야한다. → 추가 기능이 생기고, 추가 테스트해야될것도생기고, 변경사항이 발생하면 여러 사용처로 변경사항의 부수효과가 전파된다)
• 확장에 편리했다.

준찌 - (2) 다음 미션 접근하기

• 과한 TDD (X - 세지굳 ㅋㅋ)
• 패턴을 사용하지 않겠다. (패턴이 가진 아이디어에만 집중)
• 유튜브 미션과 비슷한 구조 (확장에 편해서)
• 하위 모듈부터 개발을 하되, 하위 모듈이 사용될 상위 모듈을 일부 설계해놓고 개발 !

---

세지 - (1) 과거 미션과 비교하기

• 패턴을 사용하지 않겠다 ⇒ MVC 모델에서 View를 의도적으로 제외한 구조로 결정
• 100% TDD로 개발했더니, 구조가 난잡해졌다. ⇒ 구현 후 수정이 어려움
• 완벽한 테스트를 작성하지 못한 것이 가장 큰 문제 요인

좋았던 점 : 테스트에 대한 숙련도가 상승했다.

세지 - (2) 다음 미션 접근하기

• 현재 구조의 장점을 최대한 응용하여 변경에 용이한 구조로 시작 ⇒ 설계부터 탄탄하게
• 과도한 TDD는 지양하는 방향으로 (시간과 효율이 너무 낮음)
• 아이디어에 집중해서 구현하기 (준찌 굿)

[notPotter]

FE 유튜브 미션 비교 회고

각자가 새로운 페어와 함께, 새로운 미션을 진행하면서, 새롭게 생각하게 된 내용이 있다면 로또 미션에서의 경험과 비교해보며 나누어주세요.

해리: 페어와 문제에 대한 이해나 서로가 생각하는 구조 및 진행방향에 대해 얘기해보는게 좋을 수도 있다고 생각했다. 미션의 규모가 점점 커지고 있으므로 일단 짜놓고 고치는 것보다 진행과 함께 구조를 잡아가고, 리팩터링을 진행하는게 좋을 것 같다.

샐리: 로또 미션 에서는 시간을 정해 놓지 않고 드라이버와 네비게이터를 교체하였는데 유튜브 미션에서는 시간을 정해놓고 교체를 하였다. 각각의 방법에 따라 토론을 많이 해볼 수 있다던지, 시간 관리를 하기가 편하던지 라는 장점이 있었다.

---

다음 미션에서는 어떻게 문제에 접근해볼 것 같나요

해리: 지금까지는 일단 구현 먼저, 더러운 코드 리팩터링은 구현이 끝나고 였는데 이제 구현을 해나가면서 리팩터링을 하고 통일성있는 구조를 잡아나가는 일도 함께할 것 같다.

샐리: 로또 미션 에서는 시간을 정해 놓지 않고 드라이버와 네비게이터를 교체하였는데 유튜브 미션에서는 시간을 정해놓고 교체를 하였다. 각각의 방법에 따라 토론을 많이 해볼 수 있다던지, 시간 관리를 하기가 편하던지 라는 장점이 있었다.

[euijinkk]

이번 미션 어떻게 했는가?

• 호프
  • 다른 패턴을 해보려 했으나, 결국 갇혀있었던 것같다. 결국 방법만 바뀌고 반복이 아니었나 싶다.
  • 그래도 MVC에 갇히지 않고, 새로이 생각한거니까 좋았다.
  • 포코 강의 듣고, 문제 보다는 패턴 자체에 갇힌 사고를 했던 것같다. 어떤 문제를 해결할지에 더욱 집중할 것같다.
  • (패턴, 코드를) 구현할 때마다, 그 이유를 작성해본다. 필요없다고 생각하면 폐기한다. 글로 남기는 것이 좋더라.
• 시지프
  • 옵저버를 한 것은 문제에 직면하여 해결했다고 봐야하는가?
  • 다른 자료를 참고 하지 않으려고 노력하고,
  • 내 생각이 담긴 코드를 작성하려고 한다.
  • 구조를 중간에 생각하는 것이 두렵다.

다음에 어떻게 해볼까요?

• 호프

  • 패턴에 얽매이지 않고 싶다.
  • 미션에서 문제를 마주하면, 어떻게 해결할 지 토론해보겠다.
  • 구조에 대해 너무 고민하고 있는데, 고민하고 실패하는 것이 당연하고, 그것이 임무다. 완벽한 구조는 있을 수 없다. 많이 실패해보는 것.

• 시지프

  • 컴포넌트 방식으로 짜고 싶은데, index.js에서 모으면서 문제를 해결해나가면 Model View 분리 중심으로 하게 될 것같다.

• 문제 해결 과정 자체를 궁금해 하는 것이다. 문제에 접근하는 방식을

• 그 패턴이 문제에 대한 정확한 해결책이라면 쓰면 좋겠지만.

• 모델 뷰 분리 안하고 싶다.

• 왜 비효율적인지 직접 겪어보고, 그 후에 생각해보는 것도 좋겠다.

• 컴포넌트 방식은 마음만 먹으면 학습할 수 있을 것이다.

[rladpwl0512]

1. 이번미션, 어떤 점이 달라졌을까?

• 자스민 😺

  • 스밍만의 패턴을 만들어내려고 노력했다.
    1단계에서 패턴을 생각하지 않고, 구현만해서 문제를 직면하고 1단계에서 한 것을 나만의 패턴으로 리팩터링해서 2단계에 적용해보면서 나아진 점을 느껴보려고 한다.
    지금도 현재 진행형 …
    도메인과 뷰 사이의 의존성을 없애기 위해 엄청난 노력!
    낮은 결합도와 높은 응집력을 고민하여 패턴을 만들었다.

• 위니 🐹

  • 체력이 많이 떨어짐…
  • 패턴을 고민하다가, 기능구현하기에도 바빠서 결국 MVC 패턴을 적용했다.
    로또와 달랐던 점은 view에서 dom을 가져오고, on과 emit을 통해 커스텀 이벤트를 사용해서 의존성을 줄였다. 너무 아쉽다

2. 다음 미션에서 적용해볼 한가지

• 자스민😺
  스밍만의 패턴을 정리하고 적용해볼 예정이다! (짱)
• 위니🐹
  자스민처럼 패턴 없이 부딪히는 경험을 통해, 어떤 패턴이 좋을지에 대해 고민해봐야겠다.

[kwannee]

내가 그립지 않나요

[hwangstar156]

어제 봤잖아요

[kwannee]

아 어쩐지 그립지 않더라

[ronci]

1. 이번 미션을 진행하면서 새롭게 생각하게 된 내용

우연

• 그 전까지는 당연하게 class로만 구현했었는데 이번에 함수들로 미션을 구현하면서 class의 필요성에 대해 많이 고민해봤던 것 같다. view의 경우 class로 사용했지만 많은 경우 class말고 함수로 작성하는 것이 재사용성이 더 좋고 class의 필요성을 느끼지 못했다.
• 저번에 구조도를 한 번 그려봤었는데 이번에는 따로 그리지 않고 진행했었다. step2를 하면서 점점 규모가 커저감에 따라 파일들이나 디렉토리의 구조가 섞이는 느낌이 들어 구조도의 필요성을 느끼게 되었다.

소피아

• 이번에 view와 manager(비즈니스 로직)로 나누고 둘 사이에 커스텀 이벤트로 주고 받도록 작성했다. 이벤트가 많아지니 관리가 안 되고 복잡해지는 느낌이 있어서, 어떻게 하면 이벤트를 잘 관리할 수 있을지 고민이다. (유사한 이벤트는 모아서 발행할 수 없을지, 이벤트 타겟을 어떻게 효율적으로 설정할지)
• 유사한 이벤트를 모아서 발행하는 방법을 고민하다 보니, 뷰 업데이트를 트리거 하는 값들을 모아볼 수 있겠다는 생각이 들었다. ‘상태’라는 게 어떤 것인지 잘 와닿지 않았는데, 이런 값들이 상태가 아닐까 생각을 했다.
• 비즈니스 로직을 manager 클래스로 만들었더니, 위와 같은 고민을 해결하기에 유연하지 못한 상황을 만드는 것 같아, 클래스를 없애는 것은 어떨지 고민 중이었다. 마침 우연이 이번 클래스에서 벗어나보니 재사용성이 더 좋은 것 같고 클래스의 필요성에 대해 다시 고민해볼 수 있었다고 이야기해주었다. 클래스를 제거하면 어떤 방향으로 수정할 수 있을지에 대해서도 조금 더 생각해보게 되었다.

2. 다음 미션에서는 어떻게 문제에 접근해볼 것 같나요?

우연

• 바로 class로 구현을 시작하는 것이 아니라, 함수로 구현해보고 필요에 따라 class로 묶으면서 구현할 것 같다.
• 그리고 미래의 나를 위해 단순하게라도 구조도를 그리면서 구조를 정리해나갈 것 같다.

소피아

• 클래스에 너무 얽매이지 않기.
• 변화를 트리거하는 값들을 어떻게 잘 관리할 수 있을지 고민하기.

[byhhh2]

🐧🐤 마르코 🐻🐶

• 원래는 web component를 도전하려고 했었다..!
• 그렇지만, 이번 미션에서는 도전보다는 미션을 완수하는 것에 집중하기 위해 MVC패턴을 썼다.
• 근데 리뷰어님께서 MV패턴으로도 할 수 있다고 하셨다. -> 의존성이 높아질 것 같다는 생각이 들기도 했지만, 나중에 한번 시도해보고 싶다.
• 이번에는 새롭게 이벤트위임을 사용해봤다.
• 흐긓ㄱ..흑흑! custom event와 dispatch event를 활용하여 view의 의존성을,, 끊었는데,, view에서 이벤트를 통해 가져온 데이터가 두번 이상 넘겨져야 할 때 반복적으로 custom event와 dispatch event를 중복해서 사용하게 되니 비효율적이고 피로감을 많이 느꼈다.
• web component화 + 리액트가 하는 방식을 따라해보고 싶다! 리액트 설계를 하고 싶다~!
• 나 마르코,, 다음번의 페어와 만나기 전에는 ..! 준비를 단단히 해와서 나만의 패턴을 고민해서 페어와 토론을 진행한 후 좋은 설계를 해보고 싶다. 😉

🐙🐝 무비 🐼🐹

• 이번 페어와 구조를 논의할 때 저번 미션에서의 서로의 구조를 합쳐보기로 했다..!
• 나는 마르코와 한 custom event가 너무 좋아서 이것을 가져갔고, 이번 페어는 flux패턴과 custom element를 가져왔다.
• 그래서 둘을 합쳐서 .. 무언가를 만들어냈다.
• 미션도 어렵고 내가 짠(?) 구조도 어려워서 어렵어렵웠다.
• custom element를 쓴 장점을 극대화시키기 위해 web component화를 진행하면 더 좋은 구조가 될 것이라고 생각한다. + 재활용 되지 않는 element도 과연 custom element로 만들었어야 했나? + custom element를 이용하지 않으면 현재 패턴 (flux 비스무리한 패턴)을 사용할 수 없나?
• 준비를 단단히 해와서 나만의 패턴을 고민해서 페어와 토론을 진행한 후 좋은 설계를 해보고 싶다. (22)
• 마르코와 나중에 다시 만나기로 약속~! 나아아아아앙아아아중에

[kwannee]

아무 상관없는 이모지들 ㅋㅋㅋ

[greenblues1190]

밧드 & 우디

(1) 각자가 새로운 페어와 함께, 새로운 미션을 진행하면서, 새롭게 생각하게 된 내용이 있다면 로또 미션에서의 경험과 비교해보며 나누어주세요.

• 밧드: MVC 패턴을 안쓰려고 했다. 페어와 얘기하면서 뷰를 분리하고 기능에 따라 모듈을 하나씩 만들어보기로 했다. API 담당, 스토리지 담당 모듈을 구현하고 뷰에서 발생한 이벤트들을 담당하는 모듈인 EventHandler로 다른 모듈들을 사용해 비즈니스 로직을 처리했다. MVC 패턴을 피하고자 했던 구조지만 오히려 MVC 패턴의 각 역할의 장점을 느끼기도 했다.
• 우디: 이번 미션을 하며 옵저버 패턴으로 상태 관리를 구현했다. props drilling을 그만 보고 싶었던게 첫번째 이유, 두번째는 한번 구현해보고 싶어서. 원래 Flux 패턴을 사용해보기로 페어와 얘기를 나눴지만 Flux 패턴에 대해 공부하기로 해 글들을 찾아보며 reducer, dispatch가 불필요하다고 느껴졌다. 옵저버 패턴으로 전역 상태 관리 객체를 만들어보고 굳이 Flux가 아니더라도 충분히 사용할만한 구조라고 생각했다. 레벨1이 나에게 요구하는 능력은 구조가 아니라고 생각했기 때문에 자바스크립트 기본 개념에 집중하는 것이 가장 중요하다고 생각했지만, 옵저버 패턴을 직접 구현하며 자바스크립트 기본 개념을 더 잘 이해할 수 있었다.

(2) 다음 미션에서는 어떻게 문제에 접근해볼 것 같나요?

• 밧드: 다음 SPA 자판기 미션을 한다고 해도 패턴을 안쓰고 자바스크립트 기본 개념에 집중할 것이다.
• 우디: 유튜브 미션과 마찬가지로 레벨2를 진행하기 전 해보고 싶은 것들을 페어와 얘기해보고 시도해볼 예정!

[jhy979]

밧드 ㅋㅋ 역시 저희는 MVC패턴의 장점을 느꼈쬬

[jswith]

돔하디, 민초

이번 미션, 어떤 점이 달라졌나요?

• 돔하디 : 이번 미션에서는 디자인 패턴에 갇히지 않으려고 노력했습니다. 제 나름대로의 설득력있는 구조를 짜보기 위해 노력했고 그 결과 뷰와 도메인으로 나뉘는 구조를 만들게 되었습니다. 이렇게 하니 view 에서 도메인 로직을 호출하게 되는데 이 부분에서 많은 사람들이 불편함을 느끼는데 저는 그 불편함의 근거가 무엇인지 아직은 와닿게 공감이 되지 않았기 때문에 리뷰어에게 이 부분에 대해서 피드백을 요청하려고 합니다. 추가로 이벤트 핸들러를 포함한 부분을 뷰와 도메인 사이에 둬서 분리를 할 수 있겠다고 생각을 했는데 이렇게 하면 MVC패턴이 되는 것 같다고 생각했습니다.

• 민초: 로또 미션에서는 패턴이 필요해서 사용하기보다는 시작부터 MVC를 사용하자!로 미션을 진행했었다. 하지만 그 MVC마저도 제대로 사용하지 못했고, 코드리뷰도 코드의 흐름보다는� 이건 Model에 있으면 안돼요, Controller가 너무 비대해요, 이건 View의 역할이지 않을까요 등 MVC 패턴을 잘 준수했는지에 대한 리뷰가 주로 달렸었다. 사실 레벨 1에서는 자바스크립트의 숙련도를 높이는데 중점을 둬야 하는데 자바스크립트를 잘 사용하는지에 대한 리뷰라기보다는 특정 패턴의 리뷰를 받는 느낌이 크게 들었다. 그래서 이번에는 페어와 이야기를 나누고, 어떤 패턴을 처음부터 사용하기보다는 UI와 Domain 크게 두 영역으로 나누어 구현을 진행했다.

다음 미션은 어떻게 접근해서 해결해나가면 좋을까요?

• 돔하디 : 다음 미션도 이번에 했던 것과 동일하게 그 미션에서 요구하는 사항에 최대한 근거있는 구조를 나름대로 만들어보려고 합니다. 디자인 패턴에 얽메이면 제가 짠 코드에 대한 이해도와 구조에 대한 근거가 스스로 부족해지는 느낌이 들어서 많이 고민해보고 어떤 식으로 구조를 만들어갈지 더 고민해볼 예정입니다. 저번에 TDD에서 도메인에서 뷰를 참조하고 있는 문제에 대해서 실감했는데 다음 미션에서는 이런 피드백들을 잘 되새기면서 개선할 것입니다.

• 민초 : 미션을 진행할수록 설계의 중요성을 점점 크게 느끼고 있다. 어떻게 구현할지 생각하는 것도 중요하지만, 꼼꼼한 설계를 통해 UI와 Domain을 철저히 분리할 수 있도록 할 예정이다.

[jhy979]

민초도 패턴을 버리시려는 노력을 하셨군요! 민초와 계산기 미션할 때가 좋았는데...

[jswith]

나인의 무지성 flag가 생각나네요

[jhy979]

민초 메모...

[yunjin-kim]

결, 앨버

어떤 점이 달라졌을까?

• 앨버: MVC를 버리고 도메인과 UI를 분리하여 코드를 작성하였습니다. 그리고 추후에 UI를 세부적으로 분리해보기도 하였습니다.
• 결: 패턴을 생각하기보다는 구조를 기능별로 나누었습니다

유튜브 미션하면서 했던 고민

• 앨버: 테스트 코드 작성, UI 분리 및 재사용 (아직 해결 못함...)
• 결: 최대한 유튜브랑 비슷하게 보일 수 있도록

다음 미션 접근 방향

• 앨버: 패턴을 생각하지 않고 스스로 문제를 직면하고 이를 고민하여 해결하는 방식으로 하고 싶습니다.
• 결: 자연스러운 재사용, 패턴 적용?

[dayelop]

병민 X 티거

🔥 새로운 페어와 함께, 새로운 미션을 진행하면서, 새롭게 생각하게 된 내용

병민

• 페어랑 설계에 대해 이야기 하면서, '아 컴포넌트 형식으로 만들 필요가 없겠구나. 이거는 오버엔지니어링 일수도 있겠다' 하는 생각을 했습니다.
• 로또 미션때보다 의견충돌이 많았는데 이거를 조율하고 합의에 이르는 과정이 즐거웠습니다. 제 의견을 객관적으로 바라 볼 수 있게되서 좋았습니다.

티거

• 로또 미션에서 custom element를 만들고 flux 패턴을 적용했던 것이 좋았다.
• 로또 미션에서 좋았던 부분은 취하고 아쉬웠던 부분을 개선하여 유튜브 미션에 적용하려고 했다.
• 유튜브 미션에서는 패턴 생각을 버렸다.
• 상태 관리가 필요한 부분에 대해서만 상태 관리를 했다.
• 이전 미션과는 다르게 store 구독이 필요한 컴포넌트만 구독하고 변경된 부분만 추가로 뷰에 그려줬다.
• 커스텀 이벤트를 사용하여 이벤트 관리를 좀 더 독립적으로 했다.

🔥 다음 미션에서는 어떻게 문제에 접근해볼 것 같나요?

병민

• 다음 미션은 상태 관리가 중요해 보입니다. 그래서 로또 미션때 만들었던 컴포넌트를 고도화 하고 typescript의 Decorator를 사용해서 코드를 단순화 하고 싶습니다.

티거

• 도메인과 뷰를 나눌 것이다. 패턴 생각은 안 하고 싶다.
• 상태 변화에 따라 새롭게 뷰를 그려줘야 하는 일이 많을 것 같아서 상태 관리를 하는 것도 좋을 것 같다.

[KangYunHo1221]

공원조의 자랑 병민 티거!!

[dayelop]

공원조의 자랑 병민 티거!!

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 그거 협의된 부분인가요?

[byhhh2]

공원조의 자랑 병민 티거!! (난 포코조)

[prefer2]

꼬재&도리

어떤 점이 달라졌나요?

• 꼬재: 달라진 점이 없네요. 하다보니 그때 그 코드...
• 도리: 도메인을 확실하게 분리해보려고 노력했지만, 결론적으로는 MVC 비슷하게 흘러가고 있는 것 같아요.
• 공통: 상태 관리를 어떻게 하는 것이 더 효율적인가?

다음 미션에서는 어떻게 문제에 접근해볼 것 같나요?

• 도리: 우선 문제에 대해 많은 이야기를 나눠보고 구현을 시작해보고 싶다. 변화를 어떻게 감지할까
• 꼬재: 상태관리를 어떻게 할까를 많이 고민해보고 시작할 것 같다.

[onschan]

FE 유튜브 미션 비교 회고

동키콩 🦍

Q 유튜브 미션에서 문제에 접근했던 방식은 로또 미션과 어떤 부분이 달랐나요?

A. 코드짤 때 불편함을 못느끼는 타입인데 이번에는 최대한 코드를 작성할 때 예민하게 보려고 노력했던 것 같다.

Q. 혹시 예민하게 굴었다면 페어와의 의견충돌이 있지는 않았나요?

A. 의견충돌은 없었다(하하). 예민하게 나의 코드를 보았을 뿐 저번과 같이 도메인, UI 를 나누고 나머지 구조는 각자 생각해서 2단계때 반영하기로 했다.
서로가 하고싶은거 다 해보자라는 주의였다.

Q. 서로가 하고 싶은 거를 다 해보자는 거면 어떤 부분을 시도해보셨나요?

A. 서로가 하고싶은 부분이 달랐다. 나는 도메인을 세분화시켜서 나누고싶었다. 따라서 각 기능들이 한가지 일만 하게끔하고 싶어서 빌더 패턴, 팩토리 패턴 등을 다양하게 적용해봤다. 재밌었던 것같다.

Q. 패턴에 대해 잘 아시는거같은데..

A. 이론적으로는 패턴을 모르지만 패턴을 적용하다 보니깐 그 과정도 재미있게 느껴졌다.

Q. 다음 미션에는 어떤 식으로 진행할 것 같나요?

A. 미션에 주어진 키워드에 대해서 좀 더 공부를 많이하고 진행하고 싶다. 이번 미션에서 완벽한 이해없이 진행해서 어려운 부분이 있었다. 키워드 같은 부분을 좀 더 공부하고 시작하고 싶다.

온스타 🌟

Q. 로또 미션에서 다음 미션에서 이렇게 해봐야겠다고 생각했던 부분?

A. 로또 미션 이후 다음 미션을 생각했을 땐 패턴, 구조를 생각하지않고 도메인 UI으로만 나누는 과정을 다시 거쳐볼 것이라고 생각했었다.

Q. 실제로 그렇게 하셨나요?

A. 생각했던 대로 위의 그 과정을 다시 거쳐보았다. 하지만 이번 미션에는 도메인이라고 생각할 부분이 Youtube API 를 호출하는 한정적인 부분 밖에 없었다. 따라서 도메인이란 무엇인가에 대한 생각을 깊게 할 수 있었던 것 같다.

Q. 도메인에 대해 깊게 생각을 하셨다는데..

A. 말 그대로 도메인이 무엇인지에 대해서 많이 고민을 했던 것 같다.
더 나아가서 구조에 대한 고민을 좀 더 해봤는데, 지금의 방식처럼 패턴을 배제한 미션 진행 방식에 대한 의구심이 들기도 했다.

Q. 패턴을 배제한 미션 진행에 대한 의구심이라는게 무슨 의미죠?

A. 로또 미션의 1단계 코드는 구조가 없었기 때문에 2단계에서 1단계의 문제 해결을 위해 MVC 패턴을 쓰는 쪽으로 갔었는데,
지금 미션은 2단계를 진행하면서 구조에 대한 리팩토링을 거쳤음에도 구조가 잡혀있다고도 할 수 없는 느낌이다.
사실 이정도의 구조를 잡는 과정도 굉장히 힘들었다.
변수 네이밍만 해도 머리가 아파죽겠는데, 디렉토리명, 디렉토리 구조를 바꾼다니.. 정말 머리가 아프다.
이 방식이 맞는 것인지 의구심이 드는 이유이다.

Q. 그렇다면 다음 미션은 어떻게 진행하실건가요?
페어와의 얘기가 우선이겠지만, 역으로 적합한 패턴을 먼저 짜보고 시작해보고 싶기도하다.
구조없이 진행한 뒤에, 추후에 리팩토링 과정에서 구조를 변경하고, 패턴을 적용한다는 부분이 더 골치아프고 시간이 많이 들었던 것 같다.
YAGNI 원칙을 지키기위해 야근을 더 해야되는 것 같은 느낌..? 기능 요구 사항에 대해 더 깊게 파악하고, 더 고민한 다음에 적합한 패턴을 찾아서 적용한다면 문제가 될 것도 아니라는 개인적인 생각도 든다.

• 추가 질문

Q. 이번에는 3인페어로 진행하셨는데 2인 페어와 어떤 부분이 달랐나요?

A. 3인 페어보다 2인 페어가 편하다.

Q. 팀원들이 맘에 안들었다는 건가요?

A. (하하)그런 말이 아니다. 팀원들이 너무 좋았고 재미있게 진행했지만 그와는 다른 부분에서 차이가 있는 것같다.
3인 페어의 의견 조율을 해가는 과정이 2인 페어보다는 확실히 어려운 부분이 있다.
2인 페어에서 둘의 의견만 조율해가는 과정도 쉽지 않다는 것을 쉽게 느낄 텐데,
셋의 의견 조율이라는 것은 각자 다른 생각을 가진 셋의 의견을 일치화시켜야 되는 것이다. 그런 부분에서 2인 페어가 편한 것 같다.

Q. 좋은 점도 있었을 것같은데

A. 좋았던것은 더 다양한 의견을 들을 수 있었다는 점이다.
하나의 접근 방법에 대해서 3인의 각자 다른 의견을 들을 수 있어서 더욱 좋은 생각을 많이 할 수 있었다.
부가적으로 같이 페어했던 안과 샐리가 같이 페어하기 좋은 사람들이라 만족감 높게 페어를 진행했었다.

Q. 3인 페어 추천하십니까?

A. 사바사, 케바케!

[hwangstar156]

내가 그립지않나요

[woose28]

아놀드 & 빅터

새로운 미션을 하면서 꺠달은 점

• 아놀드
  • 단일 책임 원칙과 공통 폐쇄 원칙을 준수하다 보니 자연스럽게 MVC 패턴에 가까운 구조가 잡히더라~
• 빅터
  • bottom-up으로 작은 부분에서 큰 부분으로 구현을 했는데, 중간에 혼란이 왔다. 그래서 다음에는 큰 틀은 잡고 시작하는 것도 좋을 거 같다!

다시 로또 미션을 진행한다면

• 지난 로또 미션에서 테스트 작성 -> 구현 -> 리팩터링 순으로 미션을 진행했는데, 다시 로또 미션을 해도 이와 같은 순서로 개발할 거 같다!

• 아놀드

  • 상태 변수를 가지지 않고 파이프 라인을 통해 함수를 순차적으로 실행 시켜서 마지막에 외부 세상(뷰 or alert)을 변화시키는 함수형 프로그래밍 방식을 적용해보고 싶다.

• 빅터

  • 회고를 하면서 아놀드 덕분에 함수형 프로그래밍이 실제로 어떻게 적용되는지 확인할 수 있었다.
  • 다시 한번 로또 미션을 진행한다면, 아놀드와 같이 함수형 프로그래밍에 도전해보고 싶다!

[sanaandmomo]

빅터와 또 하고 싶네요~!~!

[compy-ryu]

패턴을 정하지 않았을 때 느낀점

후이

• 패턴을 정하고 했을 때보다 고민해야 할 점이 늘어났다. 무지성 MVC를 사용할 때는 이건 MVC중에 뭐고 어디에 들어가야 해 이런 고민만을 했었다. MVC를 배제하고 나니, 도메인과 UI의 분리에 더 중점이 맞춰지면서 건설적인 고민을 하게 됐다.

콤피

• 어떤 위치에 어떤 코드를 넣어야 된다! 라는 소모적인 토론보다, 직접 구조를 정하고 각종 문제들과 부딪혀보며 기술적인 부분들에서 토론을 많이할 수 있어 좋았다.

다음 미션에서는 어떻게 접근해볼 것 같나요.

후이

• 아마 이번과 비슷하게 패턴 생각해보지 않고 시작할 것 같다. 효율적이지는 않겠지만 고민하는 과정이 재밌었다.

콤피

• 페어와 이전 미션에서 작성한 구조를 참조해보며, 서로 좋았던 장/단점을 공유해보고 구조를 설계할 것 같습니다.

각각에서 좋았던 점과 아쉬웠던 점

후이

MVC 패턴으로 작성할 때 :

• 장점이자 단점 → 편안했다. 고민을 별로 안해도 됐다.

현재 유튜브 미션 :

• 장점 → 재밌었다. 뿌듯하다.
• 단점 → 불안하다. 언제 문제가 터질지 모르는 지뢰밭을 걷는 기분

---

콤피

MVC 패턴으로 작성할 때 :

장점

• 생각할 부분들이 없고, 이미 검색만 해도 예시가 많이 나오는 패턴이라 페어 간 의견을 말하기가 쉬웠고, 버그가 상대적으로 더 적게 발생되었다.

단점

• 지금와서 생각해보면 무언가 정해진 길만 따라간 것 같고, 배울 기회가 많이 줄어드는 것 같다.

현재 유튜브 미션 :

장점

• 기술적인 충돌이 많이 발생되었어서, 많이 배울 수 있었고 페어와 생산적인 토론을 많이해볼 수 있었다.

단점

• 초반 구조를 잡아가거나, 기능을 추가할 때마다 버그가 상당히 많이 발생되었고 구조적인 문제를 해결하기 위해 코드가 비대해져 리팩터링에 시간이 많이 소모되었다.

[hwangstar156]

후잉

[KangYunHo1221]

코피