원티드 12월 프론트엔드 챌린지 4일차

원티드 12월 프론트엔드 챌린지

 

Logic First, React Later

1. React 다운 코드 다시 생각하기

오늘은 React 스러운 코드를 버려라는 내용이다. (?)

코드의 데이터, 계산, 액션으로 분리해서 생각했다. 코드에 액션만 존재한다면 어떨까?

React로 JSX 코드를 작성하면 구체적인 렌더링을 고려하지 않아도 알아서 해준다.

React란 무엇인지 다시 생각해보고, 비즈니스 로직이 잘 드러나도록 하는 방법에 대해 생각해보자.

지금까지 주인공은 React 였다. 이제는 비즈니스 로직이 주인공이 될 때이다.

 

1-1. React 다운 코드

- React 스럽지 않다는 이유로 어떻나 코드 스타일을 근거 없이 거부하는 경향이 존재한다.

- 의도적으로 작동하지 않을 것인지 구체적으로 아는 것과 무지성 '으 ~ 싫어' 하는 것과는 다르다.

- 어떤 장점과 단점이 있고 상쇄할 수 있는지 알아두는 것이 중요하다.

- React 컴포넌트 외부에서 let 변수 선언하기 (?) : 상태관리가 어렵고 리렌더링이 안될 수 있다.

- React에 Class 문법을 사용하기 : Angular, Nest.js에서는 잘 사용하고 있고, 캡슐화로 사용가능

- SOLID, IoC, 캡슐화 등의 원칙이 가지는 위력이 얼마나 강력한가에 대해서 우리는 알고 있다.

- React는 UI Renderer 이다. 화면을 그리는데 특화되어 있다.

- 렌더링은 React의 영역이고 개발자가 손댈 수 없다.

- '액션'은 시점과 횟수에 의존한다.

- 계산을 사용할 떄는 시간의 축을 신경쓰지 않아도 되었다. 계산에 액션이 끼어드는 순간 로직을 파악하는 일의 복잡함에는 하나의 차원이 더 추가되는 셈이다.

- 상태와 부수 효과 관리가 React가 정말 잘하는 걸까?

-React 코드 작성 전에 React 없이 작성할 로직부터 고민하자

 

2. Core에서 Adaptor로, 다시 React로

- Wessttrate가 쓴 'UI는 좀 이따 생각해봅시다'라는 글의 번역글

- 먼저 사용자가 시스템과 어떻게 상호작용할지 코드로 작성하는 일부터 시작해야 한다. 앱을 사용하면서 어떤 과정을 거치게 되는지, 또 어떤 정보를 필요로 할지, 어떤 정보를 서버로 전송할지 등 달리 말하면 해결해야 하는 문제의 도메인(domain)을 모델링하는 작업부터 시작하는 것이다. 이런 문제를 해결하는데 코드를 작성하는 일은 굳이 UI 라이브러리를 사용하지 않고서도 할 수 있다. 비즈니스 로직을 수행하는데 필요한 동작을 추상적인 형태로 만들 수 있다.

- 기능 구현 보다는 도메인에 대한 이해가 중요하다.

- iOS 앱 개발도 프론트엔드이다. 개념은 같다. 게임 개발도 그렇게 확장될 수 있다.

- 프로그래밍 언어나 분야에 국한되지 말고 참고해서 

- 안드로이드 공식 문서 내용에는 다음과 같은 내용이 있다. 일반적인 아키텍처 원칙을 고려하여 각 애플리케이션에는 레이어가 두 개 이상 있어야 합니다. 화면에 애플리케이션 데이터를 표시하는 UI레이어, 앱의 비지니스 로직을 포함하고 애플리케이션 데이터를 노출하는 데이터 레이어, UI와 데이터 레이어 간의 상호작용을 간소화하고 재사용하기 위한 도메인 레이어라는 레이어를 추가할 수 있습니다.

- 안드로이드에서도 외부 의존성에 대한 DI(의존성 주입) 패턴을 권장한다.

UDF 단방향 데이터 흐름 (안드로이드)

- ViewModel의 목적은 UI 컨트롤러의 데이터를 캡슐화하여 구성이 변경되어도 데이터를 유지하는 것 

- 대부분의 비즈니스 로직이 데이터 레이어에 있지만 UI 레이어에도 비즈니스 로직이 포함될 수 있다.

- ViewModel은 UI 레이어의 비즈니스 로직을 처리하기에 적합한 위치이다.

 

2-1. React의 경우 

- React 개발 흐름은 일반적으로 JSX로 UI요소를 작성하고, 해당 요소들을 이벤트, API 호출 등에 대한 로직을 작성하고 View와 연결한다.

- 이 흐름을 뒤집어 API에 대한 로직부터 먼저 작성해보자.

1) 비즈니스에 필요한 기본적인 요소들을 먼저 정의하고

2) 그 요소들이 행동할 수 있는 케이스를 수집하여 기능을 구현한 뒤

3) 마지막에 UI를 작성하여 기능과 연동하는 방법

- 이렇게 했을 때 가장 큰 장점은,
   > 비즈니스 로직에 대한 SSOT(Single Source Of Truth)를 얻을 수 있다.

   > 새로운 팀원 합류 시 혼란 없이 빠른 온보딩이 가능하다.

   > 테스트를 작성하기 쉬워진다.

- 프론트엔드에서 테스트하기 어렵다는 말이 나오는 것은 테스트가 UI라는 변하기 쉬운 대상에 의존하는 경우가 많아서이다.

좋은 소프트웨어 아키텍처는 시스템을 운영하는 데 필요한 요구도 알려준다. 아키텍처의 이 역할을 달리 표현하면, 시스템 아키텍처가 개발자에게 시스템의 운영 방식을 잘 드러내 준다고 할 수 있다. 시스템 아키텍처는 유즈케이스, 기능, 시스템의 필수 행위를 일급(first-class) 엔티티로 격상시키고, 이들 요소가 개발자에게 주요 목표로 인식되도록 해야 한다. 이를 통해 시스템을 이해하기 쉬워지며, 따라서 개발과 유지보수에 큰 도움이 된다.

 

2-2. Core를 UI에서 분리하고 Adaptor로 연결하기

- 애플리케이션의 (비즈니스)로직을 다양한 UI에서 사용될 수 있도록 설계하고 개발하세요.

- 웹 어플리케이션이 아니라 CLI를 만들듯이 상태와 스토어, 프로세스를 설계하세요.

- 당근 원지혁 개발자의 '이벤트 기반 웹뷰 프레임워크 설계와 플러그인 생태계 만들기'

- Stack 자료구조 기반의 Core 로직을 설계하고, dispatch로 인해 상태 변경이 일어났을 때 React UI 쪽에서 구독에 따른 상태 변경을 감지하도록 설계 상의 개선이 있었다.

- 로직을 React Router에 의존하지 않고 별도로 Stack 구조의 React 외부 상태로 분리하고, Core 로직을 별도 관리하는 방식으로 개선하였다.

 

3. 난잡한 코드베이스를 위한 추상화 벽 시공법

- 강사님께서는 Juntao Qiu 글의 한국어 번역을 꼭 읽어보길 권장한다.

- '잘 알려진 UI 패턴을 사용하여 리액트 애플리케이션 모듈화하기'

- 엔터프라이즈 레벨의 복잡도를 가진 코드베이스에 어떻게 구조를 부여할 것인지 설명한다.

- 강의 내용을 기반으로 'UI를 나중에 생각합시다'와 위 글을 100번 읽으시오.

- 애플리케이션을 작동시키려면 라우터, 로컬 스토리지, 다양한 수준의 캐시, 네트워크 요청, 서드파티 통합, 서드파티 로그인, 보안, 로깅, 성능 튜닝 등이 필요하다. 이 모든 추가적인 맥락을 고려할 때, 모든 것을 리액트 컴포넌트나 훅에 구겨 넣는 것은 더 많은 혼란을 야기하기 때문에 좋은 생각이 아니다.

- 그래서 우리는 제품에 다양한 추상화 방법을 동원해야 하고, 그것의 핵심은 '인터페이스'라는 사실이다.

- 구체적인 이름 대신 일반적 이름을 가진 인터페이스로만 만나도록 한다면 각 로직 간 결합도는 낮아질 것이며 자연스럽게 그 '추상화 벽'이 그어질 것이다.

- JSON 데이터를 가공해주는 방식으로 개발을 하지만, 도메인에 깊은 이해를 가지고  있으면 API 응답(데이터 모델과 UI를)을 캡슐화해서 사용해주면 되어 간편하고 직관적인 코드가 된다.

- 난잡한 코드 베이스를 CLI 명세서처럼 캡슐화와 추상화를 하여 사용할 수 있도록 하자

프론트엔드 제품 또한 성장을 견딜 수 있는 좋은 외피를 필요로 한다. 오직 프론트엔드 엔지니어만이 할 수 있는 일이다. 업계의 많은 개발자들이 이 사실을 간과하는 듯 보인다. 계산과 액션을 분리함으로써, UI와 비즈니스 로직을 분리함으로써, SOLID와 IoC 관점에서 올바른 추상화를 통하여 단단한 컴포넌트를 설계함으로써, 그리고 도메인 로직을 UI Renderer인 React와 분리된 Core 영역에 정의하여 비즈니스의 SSOT로 관리함으로써 말이죠.
우리는 제품을 만드는 것이지 React 개발을 하는 것이 아닙니다. React를 사랑하기 때문에 더더욱 React 개발자를 거부하십시오. 비즈니스 로직에 가장 걸맞는 옷을 입혀주는 개발자를 추구하면 좋겠습니다. 그제서야 React는 우리가 제품을 만다는데 있어 유용한 도구로서 다시 우리에게 돌아올 것 입니다.
(오종택 강사님)

 

- 작성한 코드를 클린 아키텍처로 만들기 위한 리팩터링을 회사에는 유지보수 측면에서 인정해준다. 하지만 기능구현이 우선되고 일을 줄이기 위한 일로 진행해야 한다.

- 소요일을 10일이라고 말하면, 7일 코드 작성 3일 리팩터링의 의미이다. (7일 중 4일은 로직 설계)

- 강사님은 6일 코드 작성, 1일 다시 짜고, 3일 리팩터링하여 10일을 쓴다. 4일 코드 리뷰

- 그렇기 때문에 Domain에 대한 이해가 필요하다. 그 다음 UI 바인딩은 어렵지 않다.

 

[아하! 모먼트 - 04] 내가 그때 성장이라고 믿었던 것들

- '어떤 것을 알아야 프론트엔드로서 단단하면서 빠르게 취업을 할 수 있는지'에 대한 질문에 대한 정리이다.

- 오늘 뭐라도 했으면 어제보다는 더 많이 알게 됐으니 그럼 시간들의 누적만으로도 성장을 하고 있다고 할 수 있다 말한다.

- 1년차의 임계점을 넘지 못하고 10년을 하면 1년차에 머물러 있는 것이다.

- 기계적인 반복이 아니라, '의식적인 노력'과 '피드백'이 반드시 따라야 한다.

- 프론트엔드의 대표적인 함적 예시로, 하던대로만 하는 관성적인 개발, 그런 회사의 업무 환경, 무지성 개발 스터디나 아티클 정리이다.

- 핵심적인 성장의 기회를 놓칠 수 있다는 점에서 기회비용적으로 손실일 수 있다. 열심히 노력하고 있다는 사실 때문에 내가 정말 집중해야할 것이 무엇인지 탐색하는 시간을 갖기 어렵다.

- 특히 주니어 개발자들은 자신의 좁은 시야 안에서 뭘 알아야 할지 판단해야 하는데, 그 시점에서 그나마 만만한 것이 언어나 프레임워크 관련 서적이나 강의다. 혹은 최신 기술 관련한 아티클이나 fancy한 주제들에 대한 소식을 팔로우업하는 일 등이다. (이런 일들은 대체로 투자 시간 대비 영양가가 없다.)

- 결론은 웹 개발을 잘 알고 잘 하고 싶으면, 웹 개발에 진짜 필요한 핵심 지식들을 공부해야 한다.

- 공부하기 위해 공부하는 게 아니라, 내일 출근해서 당장 업무에 사용하게 될 것들을 공부해야 한다.

- 개발적인 문제들은 대부분 React18 버전의 Suspense나 Fiber 내부 구현 같은 최신의 주제 혹은 어디 구석에 숨겨져 있는 지식의 형태로 찾아오지 않는다. 가짜 문제에 속으면 안된다. 기본기가 탄탄할 때 좀 더 빠르고 우아하게 해결할 수 있다.

여러가지 라이브러리나 기술 스택, 혹은 자바스크립트나 타입스크립의 신규 기능 혹은 기발한 로직이 기여할 수 있는 자리는 극히 제한적이다. 내가 이 글을 통해 전달하고 싶었던 핵심이 바로 이 부분이다. 오히려 굉장히 오랜 기간동안 웹의 척추를 떠받쳐온 낯익은 기술들을 생소하게 보고 깊게 이해하기 위해 노력해야 한다.