어떤 코드를 작성해야하나요?

https://www.wanted.co.kr/events/pre_challenge_fe_5

원티드 프리온보딩 프론트엔드 챌린지에 참여한 이후, 인상 깊은 내용을 정리한 글입니다.

프리온보딩 프론트엔드 챌린지 1월 | 원티드

 

'왜요?'

논리적으로 기술에 대한 자신의 견해를 밝힐 수 있는 사람이 되어야합니다.

그렇다더라 식의 공부는 전혀 논리적이지 못하고, 이는 경험이 부족하더라도 앞으로의 성장을 기대할 수 있음

이는 기본기와 연관되는 표현으로 기본 지식이 아니라, 지식을 다뤄온 태도를 볼 수 있음.

 

따라서 취향은 갈릴 수 있지만 이유가 있는 코드를 작성하는 것이 중요하고

화려하고 복잡한 코드보다는 오히려 독이 될 수 있으므로 늘 필요한 만큼의 코드를 작성하는 것이 좋음

 

결과적으로, 이를 통해 어디서 뭘 찾아보고 언제 어떻게 물어봐야 할지 안다는 것을 증명하자

 

 

 

상태 관리 (Form Validation, Local State, Global State)

웹 프론트엔드의 구현 포인트

서버에서 데이터를 받아서 사용자에게 보여줍니다.

사용자에게 입력을 받아서 서버에게 보내줍니다.

즉, 서비스 전체적인 관점에서 보면 웹 프론트엔드는 사용자와 서버 / DB 사이에 존재하는 입출력 인터페이스라고 볼 수 있습니다.

웹 프론트엔드는 유저에게서 받아온, 서버에서 받아온 상태 등 여러 요소의 각 상태를 관리함.

컴포넌트 단위로 현대 웹을 관리하면서 각 컴포넌트 내부의 상태가 먼 곳으로 전달되거나, 전체에서 접근이 가능하게 관리해야하는 상황이 발생하는데, 이러한 요구사항을 충족하며 상태를 관리하는 것이 어렵기때문에 MVC, Observer Pattern, Flux, Container-Presenter를 사용하여 관리하는 양상을 쉽게 찾아볼 수 있음.

따라서 MVC, Observer Pattern, Flux, Container-Presenter는 상태 관리 문제에서 발생할 수 있는 어려움들을 패턴화 한 일종의 모범답안이라고 생각할 수 있음

 

• 인증 (Authentication) - 누구세요? (신원 확인 → 진짜 ‘그 사람’이 맞는지)
• 인가 (Authorization) - 구매할 권한이 있으신가요? (권한 검증 → 진짜 ‘그 권한’이 있는지)

 

 

 

관심사의 분리

문제를 해결하는 가장 기본적이고 효과적인 방식은 ‘한번에 한 가지 일로 나누어 처리 하는 것’입니다.

각각의 관심사에 따라 코드를 분리하는 기법을 관심사의 분리라고 합니다.

 

관심사의 분리가 적절히 구현된 코드에서는 Loose Coupling(낮은 결합도, 각각의 코드가 서로 얽혀있지 않고 독립적으로 잘 분리되어 있음)과 High Cohesive (높은 응집도, 유사한 내용끼리 비슷한 위치에 잘 모여 있음)와 같은 특성을 발견할 수 있습니다.

 

관심사의 분리를 달성할 수 있는 대표적인 예제로서 보통 유저 인터페이스(View)와 비즈니스(Business, Domain) 로직의 분리를 들 수 있겠습니다.

• View
  • 사용자와 애플리케이션이 화면 상에서 상호작용 하는 영역
  • 데이터를 화면 상에 표시하는 영역
  • ex. Image, Form, Button 등
  • ex. 외부에서 주입 받은 props에만 의존하는 순수함수적 컴포넌트

• Domain(Business) Logic
  • 현실 세계의 비즈니스 규칙
    • 대출에는 대출 잔액, 이자율, 지급 일정이 필요하다 (엔티티)
    • 유저의 신용등급이 7등급 이하라면 대출이 불가하다 (유즈케이스)
  • 개발 시스템 전체 관점에서 웹은 세부사항에 가깝기 때문에 백엔드 서버 측 API에 많은 디펜던시가 있음
  • API 호출 로직을 view 로직과 분리하는 것만으로도 어느 정도 관심사의 분리를 달성할 수 있음

유사한 예시로 Headless UI 라는 개념이 있습니다.

 

 

 

명령형 프로그래밍(How)과 선언형 프로그래밍(What)

명령형은 특정한 동작을 어떻게(How)달성할 것인지에 집중하고, 선언형은 무엇을(What) 할지에 집중

명령형 프로그래밍의 패러다임으로 저의 출근길을 표현해보자면, 다음과 같습니다.

 💬 “집에서 나와 오른쪽으로 10m, 다시 왼쪽으로 10m, 언덕을 따라 30m 내려간 뒤 왼편에 보이는 지하철역에서 강남역 방향 지하철을 타고 7정거장을 이동하여 하차한다.” (How)

 

반면 선언형 프로그래밍에 가깝게 표현한다면 아래와 같습니다.

💬 “나는 강남역으로 이동한다” 

• goGangnam (= React render)

선언형 view를 만듦으로 예측가능하고 디버그하기 쉬운 view를 만들어줌

 

 

 

 

추상화

DRY(Don’t Repeat Yourself) 는 중복 코드를 만들지 말라는 뜻으로 코드가 줄어든다는 직관적인 장점 뿐만 아니라, 로직의 관리 포인트가 줄어들어 유지 보수 측면에서의 장점도 있습니다.

더불어 공통되는 로직을 추출하다보면 어떤 부분은 추상화가 되기도 하는데, 함수가 한가지 일을 하도록 코드를 작성하라는 단일 책임 원칙 을 따르도록 하는것이 좋다.