author
postNo
status
thumbnail
description
category
tags
createdAt
updatedAt
10/26(토) FeConf에 참여하였다. 시간상 하루종일 듣지는 못하고
오전 세션만 듣고 돌아왔는데, 오전에 들은 두 가지 세션에 대해 기억나는대로 정리해보고자 한다.
팀장님 : 우린 내일부터 React + TypeScript로 갑니다.
- 현 시대에서 FE개발자가 마주한 상황들
- 비즈니스의 빠른 변화 => 요구사항의 변화/번복
- 대규모 어플리케이션 개발 => 높아지는 복잡성, 유지보수의 어려움
- 브라우저 성능향상 => 복잡한 인터렉션과 기능 요구
- 높아지는 제품에 대한 기대감 => 성능과 안정성 요구
- JavaScript is everywhere! => FE개발자의 영역 확장
- 좋은 제품의 기준
- 성능 (Performance) - 더 빠르고 효고적인 어플리케이션
- 특징 (Feature) - 제공하는 기능과 활용성
- 신뢰성 (Reliability) - 안정성
- 일치성 (Conformance) - 코드에 대한 신뢰
- 내구성 (Durability) - 코드의 수명
- 서비스성 (Serviceability) - 유지보수성
- 심미성 (Aesthetics) - 가독성
- 고객이 느끼는 품질 (Perceived Quality) - 핵심 결과물
- React.js의 장점
- 기술 스택 선택이 자유롭다.
- 컴포넌트 단위 개발하기에 적합히다.
- 다양한 라이브러리, 프레임워크와 함께 사용할 수 있다.
- 가볍게 뷰 렌더링만 필요할때 사용하기도 적합하다.
- TypeScript의 장점
- private지원 등 JS class의 한계 극복
- class, interface, generic 지원
- 객체지향 프로그래밍 환경을 제공하여 복잡한 어플리케이션 개발에 유리
- React.js 성능
- React는 Dom을 더 빠르게 조작하기위한 라이브러리가 아니다. 유지보수를 가능한 앱을 만드는것을 도오주고 대부분의 경우 '충분히 빠르다'
- 최적화의 핵심은 데이터의 불변성과 Reconciliation
ES6 + 비동기 프로그래밍과 실전 에러 핸들링
- Promise, async/await, try/catch를 정확히 다루는것이 중요하다.
- 제너레이터/이터레이터/이터러블을 잘 활용하면 코드의 표현력을 더할 뿐 아니라 에러 핸들링도 더 잘 할 수 있다.
- 순수 함수에서는 에러가 발생하도록 그냥 두는것이 더 좋다.
- 에러 핸들링 코드는 부수효과를 일으킬 코드 주변에 두는것이 더 좋다.
- 불필요하게 에러 핸들링을 미리 해두는 것은 에러를 숨길 뿐이다.
- 차라리 에러를 발생시키는것이 낫다. sentry.io 같은 서비스를 이용하여 발생되는 모든 에러를 추적하는것이 고객과 회사를 위한 더 좋은 해법이다.
