10/26(토) FeConf에 참여하였다. 시간상 하루종일 듣지는 못하고

오전 세션만 듣고 돌아왔는데, 오전에 들은 두 가지 세션에 대해 기억나는대로 정리해보고자 한다.

팀장님 : 우린 내일부터 React + TypeScript로 갑니다.

1. 현 시대에서 FE개발자가 마주한 상황들

   • 비즈니스의 빠른 변화 => 요구사항의 변화/번복
   • 대규모 어플리케이션 개발 => 높아지는 복잡성, 유지보수의 어려움
   • 브라우저 성능향상 => 복잡한 인터렉션과 기능 요구
   • 높아지는 제품에 대한 기대감 => 성능과 안정성 요구
   • JavaScript is everywhere! => FE개발자의 영역 확장

2. 좋은 제품의 기준

   • 성능 (Performance) - 더 빠르고 효고적인 어플리케이션
   • 특징 (Feature) - 제공하는 기능과 활용성
   • 신뢰성 (Reliability) - 안정성
   • 일치성 (Conformance) - 코드에 대한 신뢰
   • 내구성 (Durability) - 코드의 수명
   • 서비스성 (Serviceability) - 유지보수성
   • 심미성 (Aesthetics) - 가독성
   • 고객이 느끼는 품질 (Perceived Quality) - 핵심 결과물

3. React.js의 장점

   • 기술 스택 선택이 자유롭다.
   • 컴포넌트 단위 개발하기에 적합히다.
   • 다양한 라이브러리, 프레임워크와 함께 사용할 수 있다.
   • 가볍게 뷰 렌더링만 필요할때 사용하기도 적합하다.

4. TypeScript의 장점

   • private지원 등 JS class의 한계 극복
   • class, interface, generic 지원
   • 객체지향 프로그래밍 환경을 제공하여 복잡한 어플리케이션 개발에 유리

5. React.js 성능

   • React는 Dom을 더 빠르게 조작하기위한 라이브러리가 아니다. 유지보수를 가능한 앱을 만드는것을 도오주고 대부분의 경우 ‘충분히 빠르다’
   • 최적화의 핵심은 데이터의 불변성과 Reconciliation

ES6 + 비동기 프로그래밍과 실전 에러 핸들링

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