왜 이 내용을 정리하나로그 파일에서 사용자 ID별로 요청 기록을 모으거나, 판매 데이터에서 지역별 주문 목록을 나누는 일은 실무에서 자주 나온다. 같은 키를 가진 값들을 하나의 리스트로 모아 두면 이후에 개수를 세거나 합계를 내거나 정렬하기가 쉬워진다. 이런 작업은 반복문에서 키 존재 여부를 매번 검사하는 코드로도 할 수 있지만, 코드가 길어지고 실수가 생기기 쉽다. 그래서 collections 모듈의 defaultdict와 딕셔너리 컴프리헨션을 함께 쓰는 방법을 정리해 둘 필요가 있다.이 노트에서는 defaultdict(list)로 키별 리스트를 만드는 방법, 그 결과를 딕셔너리 컴프리헨션으로 가공하는 방법, 그리고 리스트 길이로 빈도를 확인하는 방법을 정리해 본다.개념 설명일반 딕셔너리에서 없는 키에..

왜 이 내용을 정리하나부모 컴포넌트의 상태가 바뀌면 그 안의 함수는 매번 새로 만들어진다. 자식 컴포넌트에 이 함수를 props로 넘기면, 자식은 props가 바뀌었다고 판단해 불필요하게 다시 렌더링된다. 자식 컴포넌트를 React.memo로 감싸 두었는데도 렌더링이 줄지 않는다면 이 문제를 의심해야 한다. 함수를 useCallback으로 감싸면 의존성이 바뀌지 않는 한 같은 참조가 유지되는데, 실제로 그런지 눈으로 확인하는 과정이 필요하다. 이 노트에서는 console.log로 자식의 렌더링 횟수를 세어 두 방식의 차이를 정리해 본다.개념 설명React.memo는 props가 이전과 얼가하게 같으면 컴포넌트 렌더링을 건너뛰는 고차 컴포넌트다. 비교는 얕은 비교(shallow compare)로 이루어진다..

왜 이 내용을 정리하나Swift에서 딕셔너리는 키로 값을 찾는다. 그런데 키가 없을 때의 동작을 모르고 값을 바로 쓰면 런타임에서 문제가 생긴다. 예를 들어 사용자 설정값, 외부 API 응답의 필드, 캐시 조회처럼 키가 있을 수도 없을 수도 있는 상황에서는 조회 결과가 옵셔널이라는 점을 먼저 알고 있어야 한다. 또 키가 없을 때 기본값을 주는 방식과 nil을 받아 분기하는 방식이 어떻게 다르게 동작하는지도 구분할 수 있어야 한다. 이 노트에서는 딕셔너리 subscript의 반환 타입을 확인하고, nil 반환과 subscript(default:)의 차이를 print로 비교해 본다.개념 설명Swift 딕셔너리에 키를 넣어 조회하는 dict[key] 형태의 subscript는 값 타입이 아니라 값 타입의 옵셔..

왜 이 내용을 정리하나React 컴포넌트는 state나 props가 바뀔 때마다 함수 본문 전체를 다시 실행한다. 그래서 목록 필터링이나 정렬처럼 무거운 계산이 렌더링마다 반복되면 입력 타이핑이 버벅이는 현상이 생긴다. 이때 useMemo를 쓰면 계산 결과를 캐시해 두고 재사용할 수 있다고 알려져 있다. 하지만 의존성 배열의 값이 같을 때 정말 계산 함수가 실행되지 않는지는 코드로 확인하지 않으면 감으로만 남는다. 이 노트에서는 console.count로 실행 횟수를 세어 보고, 의존성 값이 같을 때와 다를 때의 차이를 정리해 본다.개념 설명useMemo(factory, deps)는 두 인자를 받는다. factory는 값을 계산하는 함수이고, deps는 그 계산이 의존하는 값들의 배열이다. React는 ..

왜 이 내용을 정리하나Flutter 앱을 만들다 보면 MaterialApp에 theme을 한 번 지정해 두고, 그 뒤로 여러 화면을 Navigator로 쌓아 가는 구조가 흔하다. 이때 첫 화면에서는 색이 잘 보이는데 push한 새 화면의 AppBar나 버튼 색이 기대와 다르게 나오면 원인을 찾기 어렵다. 특히 화면마다 Theme 위젯을 따로 감싸 둔 경우에는 어느 쪽 설정이 이기는지 헷갈린다. 그래서 theme의 primaryColor가 새 라우트까지 실제로 내려가는지 눈으로 보는 대신 코드로 확인하는 방법을 정리해 본다.개념 설명MaterialApp의 theme 값은 앱 전체의 기본 ThemeData로 쓰인다. Navigator가 push하는 라우트는 같은 MaterialApp 아래에 있으므로 별다른 ..

왜 이 내용을 정리하나파이썬에서 함수 안에 yield가 있으면 일반 함수처럼 동작하지 않는다. 함수를 호출하는 순간 본문 코드가 한 줄도 실행되지 않고, 제너레이터 객체만 돌아온다. 이 사실을 모르고 코드를 짜면 print가 안 찍히는 이유를 찾느라 시간을 낭비하기 쉽다. 특히 디버깅 중에 함수의 반환값을 확인할 때, 값이 나오지 않고 객체만 보여 당황하는 경우가 많다. 그래서 이 동작을 직접 확인할 수 있는 방법을 알아 둘 필요가 있다. 이 노트에서는 inspect.isgeneratorfunction과 type()으로 이 동작을 확인하는 방법을 정리해 본다.개념 설명함수 정의 안에 yield 키워드가 하나라도 있으면, 파이썬은 그 함수를 제너레이터 함수로 취급한다. 일반 함수는 호출하면 본문을 처음부터..

왜 이 내용을 정리하나Dart로 함수를 설계하다 보면 매개변수 중 일부는 반드시 받아야 하고, 일부는 값이 없을 때 기본값으로 대체되어야 하는 경우가 많다. 이때 명명된 매개변수에 required와 기본값을 함께 쓰면 어떤 규칙이 적용되는지 정확히 알아두지 않으면, 호출부에서 빠뜨린 인자가 런타임 오류로 뒤늦게 드러나거나 의도와 다른 기본값이 조용히 들어가는 문제가 생긴다. 특히 Flutter 위젯 생성자처럼 명명된 매개변수가 많은 코드에서는 이 차이가 실제 버그로 이어지기 쉽다.이 노트에서는 required 매개변수를 빠뜨렸을 때 컴파일 단계에서 무엇이 일어나는지, 기본값이 있는 매개변수는 호출하지 않았을 때 어떤 값이 들어가는지를 코드로 확인해 본다.개념 설명Dart의 명명된 매개변수는 중괄호로 감싸..

왜 이 내용을 정리하나Swift를 처음 배울 때 var와 let의 차이를 설명으로만 익히면 실제로 어떤 상황에서 막히는지 감이 잘 오지 않는다. 특히 함수 안에서 값을 바꾸려다 컴파일러가 빌드를 거부하는 경우를 여러 번 겪게 된다. 이때 에러 메시지를 직접 읽어 보면 Swift가 무엇을 보장하려는지 바로 드러난다. 그래서 let 상수에 값을 다시 넣으려는 코드를 일부러 작성하고, 컴파일러가 어떤 메시지를 내는지 확인하는 과정을 기록해 둘 필요가 있다. 이 노트에서는 let의 의미와 재할당 시 에러 메시지, 그리고 헷갈리기 쉬운 지점을 정리해 본다.개념 설명let은 한 번 초기화된 뒤 값을 바꿀 수 없는 상수를 선언하는 키워드다. var은 이후에 값을 다시 할당할 수 있는 변수를 선언한다. Swift는 컴..

왜 이 내용을 정리하나React 컴포넌트를 작성하다 보면 화면에 보여줄 값을 JSX 안에서 바로 계산해야 하는 경우가 많다. 예를 들어 상품 가격에 수량을 곱하거나, 목록의 개수를 세서 표시하거나, 페이지 번호를 계산해서 출력하는 상황이다. 이때 계산을 별도의 변수로 빼지 않고 JSX 중괄호 안에 바로 적으면 코드가 짧아진다. 하지만 JSX의 중괄호가 어떤 식으로 해석되는지 정확히 알지 못하면, 계산 결과가 출력되는지, 문자열로 그대로 찍히는지, 아무것도 나오지 않는지 헷갈리게 된다. 이 노트에서는 JSX 중괄호 안에 산술 표현식을 넣었을 때 계산 결과가 화면에 출력되는지 직접 확인해 본다.개념 설명JSX는 자바스크립트 문법을 HTML과 비슷한 모양으로 쓸 수 있게 해 주는 확장 문법이다. JSX 안에서..

왜 이 내용을 정리하나Flutter 앱에서 비동기 호출이나 입력 검증을 하면 함수가 여러 값을 돌려줘야 하는 경우가 자주 생긴다. 예를 들어 서버 응답의 상태 코드와 본문을 함께 받거나, 폼 검증 결과와 에러 메시지를 한 번에 돌려주는 식이다. 이전에는 리스트나 맵에 값을 담거나, 별도의 클래스를 만들어 감싸는 방식을 많이 썼다. Dart 3부터 도입된 레코드(record)를 쓰면 이런 값을 가볍게 묶어 반환할 수 있고, 구조 분해로 바로 변수에 나눠 받을 수 있다. 이 노트에서는 레코드를 함수 반환값으로 쓰는 방법과 구조 분해로 받아 값을 확인하는 흐름을 정리해 본다.개념 설명레코드는 여러 값을 쉼표로 묶어 만든 불변(immutable) 값이다. 위치 기반 필드는 (int, String)처럼 쓰고, 이..