MTFFM10 [MTFFM] 9일차: 이름 겹치지 않게 관리하기 저번 8일 차를 끝으로 가독성 파트가 끝나고, 오늘은 예측 가능성 파트의 첫 번째 주제인 '이름 겹치지 않게 관리하기'를 공부했다.이 주제는 단순히 “이름을 예쁘게 짓자”는 이야기가 아니었다. 예를 들어 다음 코드를 보자.export const UserList = ({ users }) => { return ( {users.map((users) => ( {users.name} ))} );};바깥의 'users'와 map 안의 'users'가 같은 이름을 쓰고 있다. 자바스크립트는 이걸 에러로 보지 않지만, 코드를 읽는 사람은 여기서 한번 멈춘다.'users.id'를 보는 순간 이 'users'가 배열인지, 배열 안의 한 명인지 다시 확인하게 된다. 코드는.. 2026. 6. 1. [MTFFM] 8일차: 왼쪽에서 오른쪽으로 읽히게 하기 오늘은 가독성 파트의 마지막 주제인 왼쪽에서 오른쪽으로 읽히게 하기를 공부했다.처음 주제를 들었을 때는 조금 추상적으로 느껴졌다. 코드는 원래 왼쪽에서 오른쪽으로 읽는 것 아닌가? 싶었다.그런데 예제를 보자마자 무슨 말인지 바로 이해됐다.{!isHideBenefit ? : null}이런 코드는 눈은 왼쪽에서 오른쪽으로 가는데, 머리는 중간에 한 번 멈춘다.1. isHideBenefit (혜택을 숨긴다)2. 앞에 !가 붙었네? (숨기지 않는다 = 보여준다)3. ? 참일 때 를 렌더링하고, 거짓일 때 null이구나. 코드 한 줄을 읽는 데 머릿속에서 번역 과정이 한 번 더 들어가는 것이다.오늘의 핵심은 다음과 같다고 생각했다.코드는 가능하면 사람이 읽는 방향 그대로 의미가 흘러야 한다.# Before .. 2026. 5. 29. [MTFFM] 7일차: 삼항 연산자 단순하게 하기 오늘은 가독성 파트의 여섯 번째 주제인 '삼항 연산자 단순하게 하기'를 공부했다.리액트에서 JSX를 작성하다 보면 삼항 연산자를 자주 쓰게 된다. 삼항 연산자는 간단한 조건에서는 꽤 직관적이다.{isEditing ? : }문제는 조건이 하나씩 늘어날 때다.로딩이면 로딩 UI, 에러면 에러 UI, 데이터가 없으면 빈 상태 UI, 그 외에는 리스트 UI.이런 식으로 분기가 3개, 4개가 되면 삼항 연산자는 금방 읽기 어려운 코드가 된다.즉, 삼항 연산자는 두 가지 중 하나를 고를 때만 단순하다.조건이 여러 개가 되는 순간, JSX는 화면 구조를 보여주는 곳이 아니라 ?와 :의 짝을 해석해야하는 인지 부하가 심한 곳으로 바뀐다.# Before code이번에 리팩터링 할 코드는 이런 형태였다.// 🎯 리팩.. 2026. 5. 28. [MTFFM] 6일차: 시점 이동 줄이기 오늘 다룬 주제는 시점 이동 줄이기였다.시점 이동 줄이기의 핵심은 다음과 같았다."코드를 읽는 사람이 지금 보고 있는 맥락 안에서 최대한 많은 것을 이해할 수 있게 만들기"즉, 읽는 사람의 시선이 위아래로 계속 튀지 않게 만드는 것이었다.# 시점 이동이라는 인지 부하5일차에서는 복잡한 조건식에 이름을 붙이는 연습을 했다.const canApplySpecialVipCoupon = ...이런 식으로 도메인 의미가 담긴 상수를 만들면, 읽는 사람은 조건식 내부를 매번 해석하지 않아도 된다.오늘 공부한 시점 이동 줄이기도 같은 방향에 있었다.코드를 읽다가 JSX에서 이런 코드를 만났다고 해보자.이때 handleNicknameSubmit이 컴포넌트 한참 위에 있거나, 심지어 외부 파일에 있으면 읽는 사람은 다시 .. 2026. 5. 27. [MTFFM] 5일차: 복잡한 조건에 이름 붙이기 # 개발자가 가장 어려워하는 것.. 이름 짓기우리는 복잡한 비즈니스 요구사항을 처리하다 보면, 컴포넌트 내부나 JSX 렌더링 영역에 다음과 같은 서면 형태의 조건식들을 무심코 작성하게 된다.if (user.isLoggedIn && user.membership === 'PREMIUM' && !user.isSuspended && cart.totalPrice >= 50000) { ... }이 코드가 화면에 그대로 노출되어 있으면 코드를 읽는 동료(혹은 미래의 나)는 이 조건식이 "무엇을 뜻하는지(의도)"를 파악하기 전에, 연산자들을 하나씩 머릿속으로 굴리며 "어떻게 계산되는지(구현 상세)"부터 먼저 해석해야만 한다.즉, 코드를 읽는 사람에게 엄청난 인지 부하와 맥락을 강요하게 되는 것이다.그래서 토스 Fund.. 2026. 5. 24. [MTFFM] 4일차: 로직 종류에 따라 합쳐진 함수 쪼개기 우리가 코딩을 하다 보면 흔히 하는 실수가 있다. 바로 usePageState나 usePayment 같은 이름으로 하나의 거대한 커스텀 훅을 만들고, 그 안에 쿼리 파라미터 파싱, 로컬 상태 관리, API 호출, 이벤트 핸들러까지 기술적으로 비슷해 보인다는 이유로 다 몰아넣는 것이다. 이렇게 기술적 종류나 페이지 단위로 훅을 크게 뭉쳐두면 어떤 문제가 생길까?책임의 비대화 (가독성 저하): 새 기능이 추가될 때마다 "어? 페이지 상태니까 여기 넣으면 되겠네?" 하고 그 거대한 훅에 코드가 계속 붙어서 이름도 역할도 모호한 훅이 탄생한다.리액트 렌더링 최적화 붕괴: 그 훅을 바라보는 컴포넌트들은, 훅 내부의 전혀 상관없는 다른 상태 변수가 바뀔 때도 쓸데없이 리렌더링을 겪게 된다. 렌더링 파이프라인에 굳이.. 2026. 5. 23. 이전 1 2 다음