4회차

• 영감을 받은
  • CA: 디자인시스템, 당근마켓 영감
• 만족스러운
  • LCK(LOL) SKT T1 못할 줄 알았는데 너무 잘해쏭 페이커 잘했나요?

• 희망 찬
  • LCK..T1
• 슬픈
  • LCK..T1
  • TDD 과제

• 만족스러운
  • 휴가 6일을 받았다. = 염려하는
  • 발표 준비
  • 이어지는 야근

• 피곤한
  • 가평 원격 - 파티 소주는 몇 병 마셨나요? 이번에는 조금만 마셨군요
• 우려하는
  • 저희 팀에게 거는 기대가 큰데 부담감

• 고독한 = 재택하면 좀 다운되는 경향이 있습니다
• 긍정적인
  • 오늘 발표랑 해피아워 기대됩니다!

• 집중하는
  • 새 프로젝트 리더
• 지루한? 나른한?
  • ThreeJS 강의를 듣는 중, 전 과정을 다 듣고 있다보니
• 놀란
  • 놀랍네요,,
  • 제 소소한 취미

notion에서 확인하실 수 있습니다. (opens in a new tab)

Frame 11

Java는 누가 짜도 비슷한 코드가 나온다.

JavaScript는 개발자의 역량에 따라 다른 결과물이 나온다.

함수형 프로그래밍은 단순히 class를 쓰지 않고, function을 이용해서 개발을 한다는 개념이 아닙니다.

Frame 12

프로그래밍이라는 게 결국 상태를 변경하는 것

많아지면 많아질 수록 복잡해진다.

OOP → 상태가 복잡해? → 잘 조립해보자 → 상태를 object로 만들어보자 → OOP는 object간의 상호작용

데이터가 변하니까 관리가 어려운거라면(state)

변하는 경계를 최대한 좁게 만들면 관리가 쉬워지겠네

FP → 상태가 복잡해? → 상태를 관리하지 말자 (상태를 변하게 하지 말자) → pipeline을 만들자

state가 변하니까 관리하는 게 어렵다.

state를 변하지 않게 관리하는 게 FP

Frame 16

함수형 프로그래밍에서는 함수가 상태를 변경하지 않습니다.

함수는 관리로부터 자유롭다.

객체지향은 디버깅을 하기 위해서 과정을 모두 거쳐야 합니다.

함수형프로그래밍은 각각은 틀리지 않는다는 것을 알 수 있다.

단순히 함수를 써서가 아니라, 함수형 프로그래밍으로 함수를 짰기 때문에…

Frame 18

OOP는 잘 짜여진 폴더 같은 개념

FP는 다 펼쳐져있다.

Frame 23

문제가 생기지 않는다라고 확신되는 코드의 양이 많을수록 복잡도가 줄어든다.

안전한 코드와 불안전한 코드, 상태를 변경하는 코드와 아닌 코드가 섞이면 문제가 된다.

Frame 27

내가 코드를 많이 쓰더라도, 코드를 바라보는 관점이 달라지고 파이프라인으로 보일 수 있는 것들이 좋은 코드를 작성하고 있는 반증

느슨하게 연결이 되어있어야 한다.

“가급적 리턴값이 없는 함수를 만들지 말자, 가급적 상태 배달하는 함수를 만들지 말자”

• OOP의 단점과 FP의 단점만 작성하게 될 수도 있다.
• JS는 만드는 사람의 역량이 굉장히 중요하다.
• Java는 잘 모르는 사람이 작성해도 비슷한 모양이 나온다.

• 문제가 없다.
• 두 가지 말이 섞여서 나오는 것
• 타입 지원을 잘하는데, 기존에 만들어져있던 함수형 라이브러리들이 TS가 나오기 전에 만들어진 것이 많음
• 더 업데이트 안하고 있거나 유지보수 안되는 부분이 있어서 나오는 이유입니다.

• redux saga를 빼고 제너레이터가 주류로 올라온 적이 없어요.
• 여러명이서 개발을 하는건데 나 혼자 힙쟁이가 되면 개발 실력이 있어도 위험할 수 있다.
• 잘 못만들었다. ⇒ 이해하기 어렵다. ⇒ 이해하기 어려운 것을 굳이 사용해야 하나요? ⇒ 끄덕..

• 바람직한 건 후자가 맞아요.
• 오버 엔지니어링을 하지말자. counter 프로그래밍에서 이런 간단한 예시는 오버 엔지니어링인 경우가 많다. 한번 해보고 자주하는 패턴이 생기면 다음부터는 처음부터 그렇게 짜고 있을것이다
• onClick을 따로 안쓰고 싶은데 그건..
  • 그건 안돼요. 미리 준비하는 것도 맞고 오버 엔지니어링도 안좋은 게 맞다.
• 14라인 이후에 코드를 수정할 때, 화면에 대한 수정만 있고 싶다.
• 14라인 이후가 변경되었으면 좋겠는 이유와, 14라인 전이 변경이었으면 좋겠는 이유가 달랐으면 좋겠고, 만약 합쳐져 있다면 어디를 변경해야하는지 경계가 모호하고 확인해야 한다.

• 함수형에서 지향하는 건 액션만 EXport하거나 은닉하는 것을 추천하진 않아요 오히려 계산이 export될 확률이 높아요.
• Action이 존재 => dispatch로 action을 호출
• action을 따라서 어떤 계산을 쓸지 pipeline을 따라서 하게 됨
  • Action == Action , 사용자의 관점에서 증가
  • 증가 → inc / 빼기 → dec는 데이터를 변경하기 위한 함수이다

/* 여기는 유닛 테스트 */
// 데이터
data
// 계산
증가 -> inc
빼기 -> dec
 
/* 여기서 부터는 E2E 테스트  */
// 액션
Action
// 뷰
onClick = dispatch(Action)
View(props, handler)

• readonly 형태의 객체로만 만들어내는 것을 하고 있다
• immutable로 객체를 생각하고 있으면 괜찮을 수 있다. → 객체 지향 관점에서는 말도 안된다!
• Scala 객체지향 형태를 띄는데 함수형을 지향한다

• 그렇지 않아요
• 상태를 변경하는 코드와, 그렇지 않은 코드를 분리해서 보는 개념이 함수형 프로그래밍이기 때문에 개념적인 이해로만 남겨두고, 그걸 꼭 배워야 하는 건 아니다.
• 오히려 이쪽으로 빠지면 위험하다. “파이프라인이다.” 라는 생각만 하면 좋다
• rxjs가 그나마 추천, 리액트 진영 계열에서는 독자적인 생태계, 주류가 많이 만들어져있음. 리액트가 너무 좋아서도 있지만 누가 짜도 그렇게 만들어질 가능성이 있다.
• 주류 픽을 선택하지 않는게 위험할 수 있다.감각만 이해하고 개념만 이해하자

• adorable css는 CSS 측면이라 좀 다르긴 하다.
• 스벨트는 주류인게 없다.
• rxjs랑 궁합이 좋다.
• 언제까지할 수 있을지는 모르겠다
• 리액트 하게되면 리액트 쿼리 + 상태관리 할것 같다

• rxjs
• svelte

• 기본적으로 만들어진 생태계가 있다.
• 예전에는 리액트 라이브러리 X, JS 라이브러리였다.
• 리액트는 html도 쓰지 않고 css도 안쓰고 자체만의 문법을 만들었다
• 외부에 있는 라이브러리를 만들려면 내부적으로 useState로 만들어줘야 함
• 그 형태로 쓸 수 없고 랩핑해주어야 함 (use~)
• 이렇게 만들어진 라이브러리는 리액트에서만 쓸 수 있다
• 리액트 라이브러리를 만들면 리액트 전용이 된다
  • 신규 혹은 과거 라이브러리들은 리액트 눈치 봐야함 (ㅋㅋㅠㅠ)
• 리액트를 사용해야 하는 생태계가 거대해서 많이 사용하는데 npm이라는 거대한 생태계의 절반이 리액트
• 과도기 시절에 만들어진 라이브러리 → 많은 것을 개선할 수 없었다
  • useEffect를 어떻게 잘 써야하는지 알아야댐
    • 최신 프로젝트는 알아도 될 필요 없음
  • useMemo, useCallback 어떻게 해야하는지 컨퍼런스 ? 이런걸 또 열어 면접 배워야함 이걸 잘하는 사람이 잘하는 사람이 된다는 부분이 비선호
• (민수박)
  • 리액트 최적화 관련된 내용이 공감이 되었다.
  • 예전에는 JS 라이브러리만 만들었는데, 리액트 쪽에서는 hook 관련된 라이브러리던지 결국 react 한정 라이브러리를 만든다.
  • 스벨트도 결국 스벨트 관련된 상태 관리가 있을텐데, 스벨트도 라이브러리를 만들면 스벨트를 위한 라이브러리를 만드는 게 아닌가요?
• 테오님
  • JS로 되어있다면, 스벨트는 그걸 읽는다.
  • 스벨트를 위한 라이브러리를 만들어야 하는 건 맞다.
• 종현: redux / react-redux 의 구조는 어떤가요?
  • 테오: 그게 맞는 구조인 것 같다.
  • 다양함을 포용해줬기 때문에 이렇게 웹이 성장할 수 있었던 것 같다.

• 좋았던 점
  • 스터디를 직접 운영해본 경험 자체가 저한테는 너무 뜻깊고 좋은 경험이었습니다.
  • 콘텐츠를 만드는 느낌이라, 뭔가 안 해본 경험을 하는 것 같아서 재밌고 좋았습니다.
  • 비슷한 연차의 프론트엔드 그리구 함수형 프로그래밍에 관심이 있는, 이런 공통 관심사를 가진 분들끼리 모아놓으니 뭘 준비를 안 해도 꽉찬 구성을 할 수 있다는 것 자체가 재밌는 경험이었어요
• 개선했으면 좋았을 내용 또는 아쉬운 내용
  • 모든 처음이라 많이 아쉬웠던 것 같아요, 이번 특별 세션도 그렇고 뭔가 매번 준비가 부족했다 라는 생각이 들고, 다음에 한 번 더 하면 잘할 수 있을 것 같다는 느낌을 많이 받아서 매주, 매번이 저한테는 조금씩 아쉬웠던 점들이 항상 남아있었던 것 같아요.

세션의 시간이 길어져서 오히려 너무 좋았어요!!! 너무 많은 인사이트들을 얻은 것 같아서 알찼습니다.

스터디 멤버분들을 잘 만났다는 생각이 드는 것 같습니다. 다들 열심히 해주시고 서로 좋은 인사이트를 주고 받을 수 있어서 파트1 너무 만족스럽게 하고 있습니다!

• 책 한 권을 다 읽기
• 안전지대, 순수함수 단어
• 행복해요..

• 민수(김)님이 스터디에 정성을 쓰시는게 느껴져서 따스한 스터디라는 느낌을 받아 좋습니다.
• 책 내용이 아니더라도 한가지나 여러가지 주제에 대해 각자의 생각을 공유할 수 있어 좋습니다.
• 스터디 참석률…. 너무 높아서 좋습니다.
• 솔직담백한 스터디 좋습니다.

• 스터디 준비를 너무 잘해주셔서 항상 감탄하고 있습니다!! 👍👍
• 다른 분들이 하고 계시는 일들(ex, 오픈소스 참여, 영어, 라이브러리 관리, 발표, 사이드 플젝, 인턴 과제 등등)도 옆에서 들으면서, 자극 받을 수 있어서 좋습니다~!
• 더 친해지고 싶어요 😃!! 오프라인 만남도 언젠간 꼭 했으면 좋겠습니다!

• 현생을 살다보면 사실 책 한 권 우직하게 다 읽기가 좀 힘든데 역시 이렇게 모여서 스터디로 하니까 책을 읽는다는 점에서 좋았고, 관심사가 같은 FE 개발자들과 책 읽은 부분에 대해 의견 나눌 수 있어서 좋았습니다.
• 체계를 너무 잘 잡아주셔서 너무 좋습니다. 파워 J와 함께 여행 따라가는 P의 기분같은..