1. 3달 전

    FECONF 2019

    FECONF 2019 세미나 참여 후기

  2. 6달 전

    Front ENDGAME 후기

    서재원, JBEE,벨로퍼트님의 세션을 포함

Tamm자바스크립트 웹 개발 환경을 좋아하고 사람들에게 재미를 주는 것에 관심이 많은 개발자 입니다.

FECONF 2019

FECONF 2019 세미나 참여 후기

featured image thumbnail for post FECONF 2019

헌집 줄게, 새집 다오


프로젝트 구조조정

이소영 https://so-so.dev

yoyoung@rainist.com

소비가 선택하는 서비스

정보가 수렴하는 곳

Domain 중심으로 소프트웨어를 설계

유저 행동은 변하지 않는다.

외부 의존성은 변한다.

Clean Architecture-in Banksalad

지난 발표를 참조해줘라 - Clean Architecture In banksalad

이사를 결정한 이유

PC 서비스 + 웹뷰(안드로이드) → 엉망

한 프로젝트에 너무 많은 스펙이 있어서 이 기능이 이미 존재하는 기능인지 찾는 데에도 10분 이상 소요.

개선해야 할 것

  1. core영역이 두 부분으로 나뉨
  2. view data

Presentational 컴포넌트는 도메인을 모르게 하자. 그래야 재사용성을 높일 수 있다.

props 를 원시값만 가지도록 하자. ( velopert님도 같은 말을 하셨다.)

함수형 프로그래밍


마플 유인동 님

indongyoo/FEConf2019

정리

  • Promise, async/await, try/catch를 정확히 다루는 것이 중요합니다.
  • 제너레이터/이터레이터/이터러블을 잘 응용하면 코드의 표현력을 더할 뿐 아니라 에러 핸들링도 더 잘할 수 있습니다.
  • 순수 함수에서는 에러가 발생되도록 그냥 두는 것이 더 좋습니다.
  • 에러 핸들링 코드는 부수효과를 일으킬 코드 주변에 작성하는 것이 좋습니다.
  • 불필요하게 에러 핸들링을 미리 해두는 것은 에러를 숨길 뿐입니다.
  • 차라리 에러를 발생시키는게 낫습니다. sentry.io 같은 서비스를 이용하여 발생되는 모든 에러를 볼 수 있도록 하는 것이 고객과 회사를 위하는 더 좋은 해법입니다.
  • Prmoise, async/await, try/catch 를 더 공부해야 한다.
  • 제너레이터/이터레이터/이터러블에 대해 이해가 부족하다.

script도 추가 하고 onload 함수를 사용하면 react-naver-login을 개선할 수 있지 않을까? 반복해서 setinterval 할 필요가 없지 않을까

  • 실제로 개선을 하였다.

React native 에서 애니메이션


오창영님

리액트 네이티브는 리액트랑 다르네요. 리액트 네이티브 환경에서 애니메이션 최적화 방법은 조금 특이하다.

리액트 네이티브는 자바스크립트 코드 영역과 안드로이드 코어 영역으로 나뉘고 이 사이에 브릿지라는 것을 통해 호출 하는 형태라, 리액트 네이티브의 최적화는 얼마나 브릿지를 적게 사용하냐에 따른다.

애니메이션은 보통 60 프레임이 되도록 해야 하고 그렇게 되면 주고 받는 과정에서 120번 이상의 브릿지를 사용하게 된다.

해결 → 모든 프레임에 대해미리 계산을 하고, 배열의 형태로 하나로 보낸다.

Canvas 애니메이션


유상엽

진짜 엄청나게 큰 데이터를 가지고 시각화 하려면 Canvas가 가장 좋을 것 같다. 뭐 WebGL이 더 빠르긴 하겠지만, 브라우저 호환성 문제가 있을 거긴 하니까....

이미지로 표현하면 수백메가가 넘을 때,, Canvas를 사용해서 확대 축소 하여 보이는 영역만 표현하기 좋고, 영역별로 다른 색 표현도 가능하다.

Lunit SCOPE

진정한 CI/CD를 위한 E2E Test 시작하기

김동우 - Node 방 구루

소포트웨어 테스트

수동 또는 자동

테스팅 - 결함을 발견

디버깅 - 결함의 원인을 찾음

E2E 테스트

전체 시스템이 제대로 동작하는지 테스트

동우님이 검토한 E2E 테스트 툴

  • Nightwatch.js

    셀레니움 기반, 느림, 버그가 많음, 다양한 브라우저 지원, Node 환경에서 테스트

  • Cypress CI/CD 테스트 후 배포

    브라우저 환경 최적화, 빠름, 크롬(파이어폭스)만 지원, 브라우저 환경에서 테스트

  • TestCafe

    동우님이 선택한 툴, 중간 속도, 버그가 꽤 있음, 다양한 브라우저 지원, Node 환경에서 테스트

유료 서비스를 사용하면 자동으로 테스트 돌리고 결과를 보여주는 등 편함.

치킨값이라도 아끼기 위해서 E2E Test Runner 개발,

webhook으로 테스트 결과를 github 댓글로 보내줌

테스트가 통과하면 믿고 배포 할 수 있다. → 이런 점은 좋지만, 정말 효용성이 좋을 까???

마지막 세션 시간에는 그냥 개발자랑 잡담하는 거 신청했다.

거기서 토스 개발자 분들이랑 대화하는 시간을 가졌다.

토스에서는 테스트 코드가 많지 않다. 픽쳐가 계속 변하고 새로운 것을 계속 시도 하기 때문. (핵심인 송금 같은 픽쳐에만 테스트를 한다.)

A/B 테스트를 정말 많이 하기 때문에, A/B테스트를 할 수 있는 구조를 만들어 뒀다.

디자인이 된 컴포넌트를 재사용한다. → 디자인이 통일 되어 있고 정형화 되어 있다.

디자인도 기본 디자인 시스템을 벗어 나지 않는다.

새로운 서비스를 추가하기 너무나 좋은 구조다. 쉽게 서비스를 추가 할 수 있다. 거의 CRA 처럼 쉽다고 한다.

간단하게 배포하기 쉬운 형태라고 한다.