12월 프리온보딩 프론트엔드 챌린지 후기
올 해의 마지막인 12월의 프리온보딩 챌린지가 종료됐다.
이번에도 프론트엔드와 마케팅 챌린지 강의에 참여하여, 관련 지식을 쌓았다.
특히, 프론트엔드 챌린지는 이전에 Next.js 강의를 진행하셨던 리멤버에 재직중인 강사님께서 진행해 주셨다.
역시나, 기대를 저버리지 않는 주제와 넘치는 분량, 그리고 실시간으로 재미있는 소통이 진행되었다.
더 유익했던 것은 일반적인 기술 강의에서는 들을 수 없는, 경험이 많은 선배가 알려주는 좋은 내용들이 많았다.
2주 간 3시간 씩 진행됐던 네 번의 강의들을 세세하게 정리하고 싶지만, 넘치는 분량을 정리하는 것은 조금 힘들다.
그래서 간략하게 어떤 내용을 다루었는지 정리하자면,
첫 번째 날, 컴포넌트가 복잡해지는 이유는 무엇일까?
일을 줄이기 위한 일을 해야 한다.
무작정 구현을 하고 나서, 나중에 코드를 최적화하는 것은 정말 힘든 시간일 수 있다. 아니, 어려울 것이다.
그래서 시작부터 동시에 코드 최적화를 진행해야 한다.
이 때, 여러 라이브러리를 사용해 처리하는 방법보다 지금 이 구현 방식이 맞는지부터 생각을 해야 하며, "내 코드는 어디에 문제가 있을까?" 고민해봐야 한다.
그리고 리소스가 제한된 상황에도 복잡도를 최대한 줄여 일을 줄이는 일을 최대한 빠르게 진행해야 한다는 것이다.
이 때, "추상화"를 생각하게 되는데, 가장 중요한 것은 "협의점을 찾아갈 수 있는 대화가 가능한가?"이다.
동료들 모두 동일한 생각을 갖고, 동일한 맥락으로 소통이 가능할 때 의사 소통이 가능해지며, 이것이 바로 "멘탈 모델"을 갖춰야 하는 이유이다.
최소한 "데이터/계산/액션"만 분리해도 중간 이상은 간다. 이 세 가지만 지켜도 코드를 적절히 분리할 수 있으며, 효율성은 크게 증가할 것이다.
또한, 부수 효과가 없이 입력 값에 대해 항상 같은 결과를 반환하는 "순수 함수"와 함수의 핵심 목적에서 벗어나 외부 세계에 영향을 주는 행위가 포함된 함수인 "부수 효과"에 대해 구분할 줄 알아야 하며, 이들을 잘 이용한다면 효과적인 코드 작성이 가능할 것이다.
마지막으로 꼭 알고 있어야 하는 개념은 "클로저"이다. 함수 컴포넌트가 상태를 저장하는 방식으로 이를 제대로 이해하고 있다면 더욱 효과적인 개발을 할 수 있을 것이다.
12월 프리온보딩 프론트엔드 챌린지, 컴포넌트가 복잡해지는 이유를 고민해보기
hseongchan2.tistory.com
두 번째 날, 비즈니스 로직
가끔은 초심을 버려야 할 때도 있다.
종종 주니어 단계의 개발자는 백엔드에서 처리해야 할 로직들을 협동심이라는 이유로 프론트엔드로 가져와 처리하려고 하는 경우가 있는데, 이는 본인을 힘들게 할 뿐만 아니라 구현면에서도 비효율적이다.
API 처리, 데이터 베이스에 경우 백엔드에서 처리하고, 프론트엔드에서는 값을 받아 나타내는 것에 집중해야 한다.
만약, 비효율적으로 프론트엔드에서 처리할 경우, 핵심 비즈니스 로직이 노출되는 보안 상 문제 등 여러 가지 문제들이 발생하며, 앱 애플리케이션을 동시 개발할 시, 앱에서도 똑같은 문제가 발생할 것이다.
이를 예방하기 위해서 확실히 구분해서 로직을 구현해야 한다.
여기서 우리는 비즈니스 로직과 이 로직들에 대한 책임을 어떤 기준으로 나누고 어떤 기준으로 격리할 것인지 고민해야 한다.
"비즈니스 로직"과 "UI 로직"을 구분하여 코드를 작성하는 것에 집중해야 한다.
그리고 소프트웨어는 단어 그대로 부드러워야 한다. 무겁고 단단한 것보다 부드럽게 각 컴포넌트가 명확해지고, 재사용이 가능하도록 해야 한다. 이 때, 고려해볼만한 것이 "컴파운드 컴포넌트 패턴"이다. 이를 사용하는 것을 고려해봐도 좋을 것이다.
그렇다면, 우리는 "캡슐화"된 구현이 가능해지고, "응집도"가 높은 코드를 작성할 수 있을 것이다.
"캡슐화"의 효과가 바로 "응집도"를 높이는 것이다.
이 때, 단순히 분리하는 것은 의미가 없다. "추출"과 "추상화"를 제대로 이해하고, "쉬움"과 "간결함"을 제대로 파악하여야 한다. 이 때, 확장 가능한 것의 의미가 담긴 "모듈성"이 중요하니 기억해야 한다.
12월 프리온보딩 프론트엔드 챌린지, 비즈니스 로직
hseongchan2.tistory.com
세 번째 날, SOLID 컴포넌트
이 시간에는 SOLID 컴포넌트에 대해 강의가 진행됐다. 그 전에, 그 어떤 도구도 사용하는 사람에 따라 방법이 달라진다는 내용으로 강의가 시작됐다.
"Context API"에 대해 장점과 단점으로 나뉘어 사람마다 바라보는 시각이 다른데, 이 또한, 사용하는 사람에 따라 잘 사용할 수도 있고 반대로 잘못 사용할 수도 있다고 한다.
그리고 캡슐화를 통해 높은 응집도와 낮은 결합도를 가지는 것에 알아가고, 이 때, 컴파운트 컴포넌트 패턴을 활용한다면 이에 가까워질 수 있을 것이다.
보통 프론트엔드에서 부정적으로 바라보는 Class도 불편하지만, 캡슐화할 수 있는 좋은 도구이다.
모든 좋은 로직을 만들기 위한 상황에서는 그에 맞는 도구를 사용하는 것이 중요하다.
그렇다면, "SOLID 원칙"은 우리의 고민들을 해소시켜 줄 중요한 해결책이 될 수 있다.
우리가 생각해야 하는 것은 "프론트엔드한테 구조를 추구하면 안될까?"에 대한 질문에 답변하는 것이다.
당연히, 반복적인 단순 노동을 하지 않기 위해서는 구조적으로 구현하는 것이 중요하며, 이 때, "SOLID 원칙"을 활용해보는 것이다.
이와 관련된 내용들과 예시 코드들을 정리하며, 반복적으로 복습하여 꼭 이해하도록 하자.
12월 프리온보딩 프론트엔드 챌린지, SOLID 컴포넌트
hseongchan2.tistory.com
네 번째 날, First Logic-Later React
이전 시간들에서 배운 내용들을 다시 한 번 복습하고, 조금 더 자세하게 다루는 시간을 가졌다.
특히, 이번 시간에는 "캡슐화"의 중요성을 더욱 자세하게 다루었고, 프로젝트를 만들기 위해서 우선적으로 생각해야 할 것들이 무엇인지, 어떻게 구현해 나가야 하는지에 대해 알아가는 시간이었다.
이에 대해, 다른 기업들은 이를 어떻게 다루었는지 예시를 통해 알아보는 시간도 가졌으며, 단순하게 "비즈니스 로직"과 "UI 로직"을 나누는 것만 생각하는 것이 아니라, 이를 어떻게 더 효율적이고 효과적으로 구현할 수 있는지에 대해 많은 이야기를 나누는 시간을 가졌다.
정리하자면, 어떤 라이브러리, 어떤 프레임워크를 사용하든 어떻게 사용할 건지가 중요하고, 무조건 패턴의 규약에 맞춰서 구현할 필요는 없으며, "Core"에 집중하여 여러가지 상황을 고려한 채 무조건 코드부터 작성하지 말고 설계부터 고려하자는 것이다.
12월 프리온보딩 프론트엔드 챌린지, 로직을 먼저-리액트는 나중에
hseongchan2.tistory.com
후기
좋은 주제, 훌륭한 내용답게 거의 대부분 이해하기 어려웠지만, 이전의 그 어떤 챌린지 때보다 유익했던 시간이었다.
정말 실무에 필요한 지식들을 전달하고자 하셨고, 그에 맞게 정말 실무에 활용해야만 하는 내용들로 이루어진 강의였다.
정말 어려운 내용들이기 때문에 반복적으로 복습이 필수이기 때문에, 이해할 때까지 계속해서 학습해 나갈 계획이다.
그리고 이번 챌린지에서 배운 내용들을 나의 프로젝트에 활용해보고, 내 구현이, 내 로직이 더 나아지는 것을 확인해보고 싶다는 생각이 들었다.
이번 계기로 프론트엔드 개발에 대해 더 고민해볼 수 있었고, 나중에 발생할 수 있는 문제들을 예방하고, 코드를 처음보는 사람들도 쉽게 이해할 수 있는 개발을 할 수 있는 개발자가 되고 싶다는 생각을 하게 됐다.
이번 챌린지를 진행하신 강사님께서 다음 챌린지도 진행하신다면 무조건