2주차에서 나눈 얘기를 간단하게 정리해보았습니다. 내게 맞는 무대를 찾기 위한 이직 계획 세워보기 1. 이직을 계획한다면 어떤 회사를 가고 싶은지 - 원팀인 회사, 비즈니스 임팩트에 집중하는 회사, 인재 밀도가 높은 회사 2. 내가 원하는 환경은 어떤 포인트가 있는것 같은지 - 훌륭한 동료들이 있는 곳, 도전 과제들이 많은 곳, 노력에 대한 보상이 따르는 곳 지금의 회사, 다음 회사에서 이루고 싶은 나의 욕구 리스트 적어보기 - 회사 내의 동료들과 함께 스터디를 하고 제품에 바로 적용하는 싸이클 만들기 - 기획을 검증하기 위한 PoC를 빠르게 진행하여 회사의 비즈니스를 돕고 이모지 많이 받기 - 어려움이 있는 동료에게 먼저 다가가서 얘기를 나누고 내가 도울 수 있는 부분을 생각하고 실천하기 - 주변..
저번주부터 라는 책의 베타리딩에 참여하고 있다. 책을 읽는것 이상으로 디스코드를 통해 따로 모임을 하면서 개발자의 커리어에 대한 다양한 생각을 나누고 있는데 비슷한 연차를 가진 동료 개발자분들과 이야기를 나누고 선배 개발자분들의 경험을 들으면서 매주 뜻깊은 시간이 되고 있는 것 같아서 좋다. 최근에 글을 지속적으로 쓰기 시작하니 뭔가 기분이 좋아졌다. 뭔지 모르겠지만 그냥 좋다.
프론트엔드 개발을 하면서 우리는 다양한 비즈니스 로직을 다루고 있어요. 자바스크립트가 존재하지 않던 예전의 웹은 정말 UI만 다루고 있었다고 얘기할 수 있겠지만, 자바스크립트가 탄생하고 AJAX 프로그래밍을 통해 웹에서 서버와 통신을 하게 되면서 웹의 역할이 늘어나게 되었어요. 이제는 프론트엔드와 백엔드의 영역이 분리되었고 프론트엔드에서의 책임이 많이 증가하게 되었는데요. 그 책임중의 하나가 비즈니스 로직이라고 얘기할 수 있을 것 같아요. 우선 비즈니스 로직의 정의는 어떻게 내리면 좋을까요? 비즈니스 로직이란 현실 세상의 문제를 해결하는, 소프트웨어 기능의 핵심적인 처리를 담당하는 코드라고 얘기할 수 있을 것 같아요. 예를 들면 쇼핑몰에서의 주문하기, 블로그에서의 게시글 작성하기와 같은 기능들은 모두 비..
React에서 함수 컴포넌트가 도입된 이후 v16.8부터 다양한 hook들이 소개되고 있습니다. 그 중에서 상태를 관리하는 useState, useReducer와 같은 상태를 다루기 위해서 꼭 사용해야 하는 훅도 있지만 useCallback, useMemo, memo와 같이 겉보기 동작에는 전혀 영향을 주지 않는 훅들도 있습니다. 메모이제이션은 무엇일까? 사용하는 것과 사용하지 않는 것에 동작의 차이가 없다면 이 훅은 어떤 목적에서 사용되는 걸까요? 이미 알고 계시겠지만 React에서는 메모이제이션(Memoization)을 위해 사용하고 있습니다. 메모이제이션의 대한 위키를 찾아보면 '컴퓨터 프로그램이 동일한 계산을 반복해야 할 때, 이전에 계산한 값을 메모리에 저장함으로써 동일한 계산의 반복 수행을 제..
글또 9기를 신청했다. NEXTSTEP 글쓰기 워크숍2기도 신청했다. 요즘은 생각을 정리하며 글로 작성하는 게 어렵지만 매력적인 것 같다. 글쓰기를 재밌게 접하고 있는 시기인 것 같아서 잘 이어나가면 좋을 것 같다.
회사에서 오늘 제품을 출시하게 됐다. 다행이도 눈에 띄는 큰 버그는 없었고 치명적이지 않은 이슈들을 정리하고 바로 수정하는 식으로 개발을 진행했다. 고객의 반응을 보면서 앞으로 필요한 기능들을 빠르게 붙여나가면 좋을 것 같다. 리팩토링 2판을 다시 읽고 있다. 처음 읽었던 게 1년전 이맘때쯤인데 회사 스터디를 통해서 읽게 되었다. 그 당시에는 사실 이해가 잘 되지는 않았지만, 읽긴 읽었다. 코드에서 나는 악취들은 공감이 많이 됐던 것 같다. 그리고 객체지향이 어려웠던 것 같다. 그리고 1년 뒤인 지금 책을 읽으면서 느낀 것은 이해가 잘 된다는 것이다. 그리고 마틴 파울러가 제시하고 있는 이 리팩토링 방식이 정말 코드의 유지보수를 쉽게 만들고 복잡도를 낮춘다고 할 수 있나? 라는 의심을 가지며 책을 읽고 ..
프론트엔드 아키텍처가 CSR에서 다시 SSR로 넘어오고 있고 RSC도 많이 언급이 되고 있습니다. 이런 흐름에 맞게 프론트엔드 개발자들에게도 서버와 인프라에 대한 지식도 점점 요구되고 있습니다. 이러한 흐름속에서 BFF에 대한 개념을 정리해보려고 합니다. 내가 알고 있던 BFF 제가 BFF에 대해서 이해하고 있던 내용은 아래와 같습니다. 클라이언트와 서버간의 통신에서 중간에 서버(BFF)를 하나 더 둔다. BFF는 프론트엔드에서의 요구사항을 충족시키기 위해 사용한다. 예를 들면, 프론트엔드에게 화면에 보여질 데이터만 전달하기 위해 사용한다. BFF의 관리는 팀의 구성에 따라서 다르다. 그런데 이 정도의 이해로는 언제 BFF를 사용하고 장점이 무엇인지 누군가를 설득시킬 수는 없는 내용이었습니다. 결국에 화..
요즘 책을 읽고 있는데 객체지향 파트가 궁금해서 먼저 읽어보게 되었다. 프론트엔드에서 이미 객체 지향을 하고 있다는 것, Class가 객체 지향이 아니라는것을 얘기하면서 우아한 형제들의 한 팀에서 사용하고 있는 React 아키텍처를 설명하고 있다. 결국에 핵심은 뷰(View)와 비즈니스 로직을 분리하는 것이고, 배달의 민족과 같은 도메인 복잡도가 높은 서비스라 그런지 Business Logic에서도 여러 모듈들로 분리되어 있는 것을 확인할 수 있었다. 실제로 적용할때는 컴포넌트에서 비즈니스 로직을 먼저 떼어내고, 그 이후에 복잡도가 높아짐에 따라 비즈니스 로직에서도 객체간의 협력을 다양하게 가져가면 좋을 것 같다.
