Development47 프론트엔드에서 바라보는 추상화 프로그래밍을 하다 보면 '추상화'라는 단어는 늘 주위에 존재한다. 너무 흔하게 사용될 수 있는 용어라 가끔은 의미에 어긋남에도 혼용될 때도 있다. 대충 코드 내에서 중복되는 부분을 발견한 다음 따로 추출하여 공통화하면, 그걸 추상화라고 말하는 경우도 있으니까. 사전적 의미추상화라는 단어를 설명하기 위해 가장 적절한 문장을 고르라고 한다면, 아마 다음과 같을 것이다.복잡한 내부 구현은 감추고 필수적인 기능만을 외부에 노출하여 단순화하는 과정 추상화는 OOP의 대표적인 특징 중 하나로 꼽히는 개념이다. 그렇지만 꼭 프로그래밍 측면이 아니더라도 이 의미는 어디에서든 통용될 수 있다. 가령 어떠한 분야를 공부하면서 전문성을 쌓을 수 있는 까닭은, 밑바닥의 세부 요소를 하나씩 이해해 가면서 그것을 일반화(추상화).. 2025. 2. 24. [리팩터링 후기] Model은 View를 아예 몰라야 할까? (feat. View Model) 회사에 복직 후 맡게 된 첫 프로젝트에서 새로운 기능 추가와 더불어 기존 모델을 리팩터링 해보는 게 어떻겠냐는 논의가 팀 내에서 이루어졌다. 으레 배포 일정은 타이트하게 주어지는 게 태반이기에, 처음에는 두 작업을 병렬적으로 가져가는 게 일정 관리 상 괜찮을지 걱정이 앞섰다. 그러나 프로젝트를 잘 마무리하고 보니 이번 업무를 진행한 과정과 구현한 결과물이 꽤 인상 깊게 남아 이 경험을 남겨보고자 글을 쓰게 되었다. 문제 정의 & 해결하고 싶었던 부분현재 회사에서 제공하는 서비스의 특성상 앱 내에서 사용자가 어떤 값을 설정하는 데 필요한 에디터를 제공하는 UI가 많다. 이번 작업 영역도 에디터와 관련성이 높았는데, 기존에 백엔드에서 내려오는 모델은 아래와 같았다.type DraftResponse = { .. 2025. 2. 1. [23.09.26] 프로젝트의 초기 렌더링 성능 향상시키기 이미지 출처 프로덕트를 만들 때, 프론트엔드 개발자가 최우선으로 고려하게 되는 것 중 하나가 바로 사용성이다. 좀 더 구체적으로 디자이너가 주로 UX 흐름이나 심미적인 부분에서 사용성 증진을 고민한다면, 프론트엔드 개발자는 그것을 받아 서버 데이터와 연결할 때 사용자 관점에서 어떻게 하면 더 쾌적함을 제공할 수 있을지 고민해야 한다. 회사로부터 주어진 프로젝트를 구상할 때 위와 같은 측면에서 주로 고심했던 부분은 각 화면 진입 시 초기 렌더링 방식이었다. 이전의 프로젝트 경험을 비추어 보면, 대부분 로딩 중인 화면을 표현하기 위해 별도의 상태를 선언하고 해당 상태를 보여줄 UI 코드를 작성하며 컴포넌트는 쉽게 비대해졌다. 이런 책임을 분리하기 위해 Suspense라는 솔루션이 나왔지만, 여전히 전체 화면.. 2024. 1. 9. [23.07.29] 프론트엔드에서 Route를 확장성있게 관리하기 리팩터링 배경 앱 내의 페이지가 많아지고 기획이 복잡해질수록 각 페이지의 주소를 나타내는 route 또한 심도 있게 관리될 필요가 있다. route의 경로뿐만 아니라 해당 경로로 안내된 페이지가 public 한 지, 해당 route의 하위 route는 무엇인지 등 여러 가지 상태를 표현할 수 있어야 하기 때문이다. 현재 관리되고 있는 route 객체는 이러한 요구사항을 충족시키기에 다소 부족하다는 생각이 들었고 이를 보완하기 위해 확장성을 높이는 방향으로 리팩터링을 시도해보았다. 기존 구조가 가지고 있던 문제점 const Route = { Public: { SignIn: '/signin', }, Private: { Main: '/', Billings: { Orders: '/billings/orders',.. 2024. 1. 9. 이전 1 2 3 4 ··· 12 다음
