line·2025년 7월 9일원문

코드 품질 개선 기법 16편: 불이 'null'인 굴뚝에 연기가 'null'이 아닐 수 없다 (새 탭에서 열림)

널 객체(null object) 패턴은 `null` 대신 '비어 있음'을 나타내는 객체를 사용하여 호출부의 코드를 단순화하고 예외 처리를 줄이는 유용한 디자인 패턴입니다. 그러나 일반적인 상태와 오류 상태를 명확히 구분해야 하는 상황에서 이 패턴을 무분별하게 사용하면, 컴파일러의 정적 검증을 우회하게 되어 오히려 버그를 발견하기 어렵게 만듭니다. 따라서 오류 처리가 필수적인 로직에서는 널 객체 대신 언어 차원의 `null`이나 `Optional` 타입을 사용하여 타입 안정성을 확보하는 것이 권장됩니다. ### 널 객체 패턴의 활용과 장점 널 객체 패턴은 유효하지 않은 값이나 비어 있는 상태를 특정 객체로 정의하여 프로그램의 흐름을 끊지 않도록 돕습니다. - **코드 단순화**: 컬렉션의 경우 `null` 대신 빈 리스트(`.orEmpty()`)를 반환하면 호출 측에서 별도의 널 체크 없이 즉시 순회(iteration) 로직을 수행할 수 있습니다. - **폴백 데이터 제공**: UI 표시를 위한 데이터 모델에서 '알 수 없는 사용자'와 같은 기본 객체를 정의하면, 데이터가 없는 경우에도 화면 레이아웃을 깨뜨리지 않고 기본 정보를 안전하게 보여줄 수 있습니다. - **로직 통합**: 경계 조건이나 오류 상황을 일반적인 비즈니스 로직에 자연스럽게 통합시켜 코드의 가독성을 높입니다. ### 널 객체 패턴이 유발하는 타입 안정성 문제 오류 상태를 일반 객체처럼 취급하게 되면 개발자가 의도적으로 해당 상태를 확인해야 하는 로직을 누락했을 때 이를 잡아낼 방법이 부족해집니다. - **컴파일 타임 검증 부재**: `isInvalid`와 같은 속성으로 오류를 확인해야 하는 널 객체를 사용하면, 확인 로직을 잊더라도 컴파일러는 이를 정상적인 코드로 인식합니다. - **런타임 버그 발생**: 유효하지 않은 널 객체가 시스템 내부에서 계속 전달되다가 예상치 못한 지점에서 오작동을 일으킬 수 있으며, 이는 즉시 런타임 오류가 발생하는 것보다 원인 파악이 더 어렵습니다. - **대안으로서의 정적 타입**: Kotlin의 널 가능 타입(`?`)이나 Swift의 `Optional`을 사용하면 컴파일러가 강제로 널 처리를 요구하므로, 오류 조건과 일반 조건을 명확히 분리하여 처리할 수 있습니다. ### 널 객체 패턴 사용 시 주의할 점: 동일성과 동등성 널 객체를 정의하고 비교할 때는 객체의 비교 방식에 각별히 유의해야 합니다. - **동일성(Identity) 문제**: `UserModel.INVALID`와 같은 정적 인스턴스를 `==` 연산자로 비교할 때, 해당 클래스에 `equals`가 적절히 구현되어 있지 않으면 내용이 같더라도 다른 객체로 판별될 위험이 있습니다. - **값 기반 비교의 한계**: 단순히 기본값(ID 0, 빈 문자열 등)을 채워 넣은 새 객체를 생성해 비교할 경우, 실제 '무효한 상태'를 나타내는 싱글톤 객체와 일치하지 않아 로직 오류가 발생할 수 있습니다. ### 상황에 맞는 도구 선택 제안 널 객체 패턴은 만능 해결책이 아니며, 상황에 따라 적절한 도구를 선택하는 것이 중요합니다. - **널 객체를 권장하는 경우**: 일반적인 경우와 오류/경계 상황을 굳이 구분할 필요가 없거나, '오류'를 나타내는 후보가 너무 많아 정적 검증이 오히려 복잡해질 때 사용합니다. - **정적 타입을 권장하는 경우**: 비즈니스 로직상 오류 상태를 반드시 인지하고 별도의 처리(예: 에러 다이얼로그 표시)를 수행해야 한다면 널 객체 대신 언어에서 제공하는 `null`이나 `Optional`을 활용하여 타입 시스템의 보호를 받아야 합니다.

코드 품질Kotlintype-safetydesign-patterns+2

line·2025년 6월 11일원문

코드 품질 개선 기법 15편: 문법은 이름을 나타낸다 (새 탭에서 열림)

개발 시 식별자의 이름을 지을 때는 선언부의 시각적 통일성보다 호출부에서 문법적으로 자연스럽게 읽히는지를 우선해야 합니다. 수식어를 뒤에 붙이는 방식은 목록화했을 때 보기 좋을 수 있으나, 실제 코드에서 사용될 때는 문법적 오해를 불러일으켜 가독성을 저해할 위험이 크기 때문입니다. 따라서 명명법의 기준을 ‘작성자의 편의’가 아닌 ‘사용자의 이해도’에 두는 것이 코드 품질 개선의 핵심입니다. **수식어 위치에 따른 가독성 차이** - 클래스를 분할할 때 `SettingRepositorySecurity`와 같이 수식어를 뒤에 붙이면(Postfix), 정의부에서는 일관성이 있어 보이지만 호출부에서는 문법적 오해를 낳을 수 있습니다. - 예를 들어 해당 클래스를 사용하는 측에서는 이를 'SettingRepository의 보안 모듈'로 잘못 해석할 수 있으며, 이는 코드를 읽는 속도를 늦추는 원인이 됩니다. - 반면 `SecuritySettingRepository`와 같이 수식어를 앞에 붙이는 방식(Prefix)은 영문법에 부합하여 클래스의 정체성을 훨씬 명확하게 전달합니다. **복합 수식어가 필요한 경우의 처리** - 수식어가 여러 개여서 단순히 앞에 나열할 경우 의미가 왜곡될 때는 전치사(of, for, at 등)를 활용하여 의미를 명확히 해야 합니다. - '세로 모드에서의 전송 버튼 높이'를 명명할 때 `portraitSendButtonHeight`는 '세로 이미지를 보내는 버튼'으로 오해받을 수 있으므로, `sendButtonHeightForPortrait`와 같이 표현하는 것이 바람직합니다. - 다만, 클래스나 구조체 같은 타입 이름에는 전치사 사용을 피하는 것이 좋은데, 이는 인스턴스 생성 시 타입 이름의 마지막 단어를 주로 사용하게 되는 관례 때문입니다. **언어 및 플랫폼 관습의 존중** - 문법적 정확성만큼이나 해당 언어 공동체의 관습을 따르는 것도 중요합니다. - Java나 Kotlin의 `currentTimeMillis`처럼 전치사가 생략되어도 충분히 의미가 전달되는 표준 API 사례가 있다면, 이를 참고하여 해당 플랫폼의 스타일과 일관성을 유지해야 합니다. 명확한 이름을 짓기 위해서는 항상 "이 이름을 처음 본 개발자가 문법적으로 오해할 여지가 없는가?"를 자문해 보아야 합니다. 선언부의 정렬된 모습보다는 코드가 실제로 쓰이는 맥락에서의 직관성을 최우선으로 고려할 것을 권장합니다.

코드 품질Kotlinrefactoringnaming-conventions+1

line·2025년 6월 4일원문

코드 품질 개선 기법 14편: 책임을 부여하는 오직 하나의 책임 (새 탭에서 열림)

단일 책임 원칙(SRP)을 기계적으로 적용하여 클래스를 과도하게 분리하면, 오히려 시스템 전체의 복잡도가 증가하고 사양의 제약 조건을 파악하기 어려워질 수 있습니다. 코드 품질을 높이기 위해서는 개별 클래스의 응집도뿐만 아니라, 분리된 클래스들이 맺는 의존 관계와 호출자가 짊어져야 할 관리 부담을 종합적으로 고려해야 합니다. 결국 핵심적인 제약 조건을 한곳에서 관리할 수 있다면, 약간의 책임이 섞여 있더라도 초기 구현의 단순함을 유지하는 것이 더 나은 선택일 수 있습니다. **과도한 책임 분리가 초래하는 문제** * 동적으로 실행 로직이 변하는 '론치 버튼'을 구현할 때, 버튼 바인딩 책임과 로직 선택 책임을 별도 클래스로 분리하면 각 클래스는 단순해지지만 시스템 구조는 복잡해집니다. * 로직별로 별도의 바인더 인스턴스를 생성하고 `isEnabled` 상태를 통해 실행 여부를 제어하게 되면, 버튼 하나에 여러 개의 리스너가 등록되는 등 내부 동작을 추적하기 어려워집니다. * 결과적으로 "단 하나의 로직만 실행되어야 한다"는 비즈니스 제약 조건을 확인하기 위해 여러 클래스와 루프 문을 모두 훑어야 하는 비용이 발생합니다. **제약 조건의 분산과 상태 중복** * 책임을 분리하면 특정 사양이 코드 전체로 흩어지는 '책임 떠넘기기' 현상이 발생할 수 있습니다. * 예를 들어 어떤 로직이 활성화되었는지 나타내는 상태를 상위 클래스(Selector)에 추가하면, 하위 클래스(Binder)의 `isEnabled` 속성과 데이터가 중복되어 상태 불일치 문제가 생길 위험이 있습니다. * 이러한 중복은 코드의 신뢰성을 떨어뜨리며, 사양 변경 시 수정해야 할 포인트가 늘어나는 결과를 초래합니다. **의존성 비대화와 라비올리 코드(Ravioli Code)** * 세부 사항을 은닉하기 위해 의존 관계를 더 잘게 쪼개면, 이를 조합해야 하는 호출자(Caller)의 코드가 비대해지는 '갓 클래스(God Class)' 현상이 나타날 수 있습니다. * 너무 작은 단위로 쪼개진 클래스들이 서로 얽히면 전체 흐름을 파악하기 위해 수많은 파일을 오가야 하는 '라비올리 코드'가 되어 유지보수성이 저하됩니다. * 객체 지향의 핵심은 캡슐화인데, 제약 조건을 보장하는 로직을 분리해버리면 오히려 캡슐화가 깨지고 외부 의존성만 강해지는 부작용이 생깁니다. **실용적인 설계를 위한 제언** 클래스를 분할할 때는 응집도라는 단일 지표에만 매몰되지 말고, 분할 후의 의존성 그래프와 호출자의 편의성을 반드시 확인해야 합니다. 만약 특정 클래스가 내부에서 핵심 제약 조건을 깔끔하게 관리하고 있다면, 억지로 책임을 나누기보다 그 응집된 구조를 유지하는 것이 시스템 전체의 결합도를 낮추고 코드의 가독성을 높이는 길입니다.

코드 품질AndroidKotlinsoftware-design+3

line·2025년 5월 28일원문

코드 품질 개선 기법 13편: 클론 가족 (새 탭에서 열림)

두 개의 상속 트리가 서로 암묵적으로 대응하며 발생하는 '클론 가족' 문제는 코드의 타입 안정성을 해치고 유지보수를 어렵게 만듭니다. 이 글은 코드 공통화를 위한 부적절한 상속 사용을 경계하고, 대신 컴포지션이나 제네릭을 활용하여 데이터 모델 간의 관계를 명확히 정의함으로써 런타임 오류 가능성을 줄이는 방법을 제시합니다. ### 클론 가족 현상과 타입 안정성 문제 데이터를 공급하는 클래스 계층과 데이터 모델 계층이 서로 일대일로 대응하지만, 이 관계가 코드상에서 명시되지 않을 때 문제가 발생합니다. * **다운캐스팅의 필요성**: 부모 공급자 클래스가 공통 데이터 모델 인터페이스를 반환할 경우, 실제 사용 시점에서는 구체적인 타입으로 변환하는 다운캐스팅(`as`)이 강제됩니다. * **암묵적 제약 조건**: '특정 공급자는 특정 모델만 반환한다'는 규칙이 컴파일러가 아닌 개발자의 머릿속에만 존재하게 되어, 코드 변경 시 실수로 인한 오류가 발생하기 쉽습니다. * **유연성 부족**: 하나의 공급자가 여러 모델을 반환하거나 구조가 복잡해질 때, 타입 검사만으로는 시스템의 안전성을 보장하기 어렵습니다. ### 상속 대신 애그리게이션과 컴포지션 활용 단순히 로직의 공통화가 목적이라면 상속보다는 기능을 분리하여 포함하는 방식이 더 효과적입니다. * **로직 추출**: 공통으로 사용하는 데이터 획득 로직을 별도의 클래스(예: `OriginalDataProvider`)로 분리합니다. * **의존성 주입**: 각 공급자 클래스가 분리된 로직 클래스를 속성으로 가지도록 설계하면, 부모 클래스 없이도 코드 중복을 피할 수 있습니다. * **타입 명확성**: 각 공급자가 처음부터 구체적인 데이터 타입을 반환하므로 다운캐스팅이 아예 필요 없어집니다. ### 제네릭을 이용한 매개변수적 다형성 적용 여러 공급자를 하나의 컬렉션으로 관리해야 하는 등 상속 구조가 반드시 필요한 경우에는 제네릭을 통해 타입을 명시해야 합니다. * **타입 파라미터 지정**: 부모 클래스에 타입 파라미터 `T`를 도입하여, 자식 클래스가 어떤 타입의 데이터를 반환하는지 컴파일 시점에 명시하도록 합니다. * **상한 제한(Upper Bound)**: 필요한 경우 `T : CommonDataModel`과 같이 제약 조건을 추가하여 최소한의 공통 인터페이스를 보장할 수 있습니다. * **업캐스팅 지원**: 제네릭을 사용하면 부모 타입으로 관리하면서도 각 인스턴스가 반환하는 타입의 안전성을 유지할 수 있어 활용도가 높습니다. 상속은 강력한 도구이지만 단순히 코드를 재사용하기 위한 목적으로 사용하면 의도치 않은 타입 문제를 야기할 수 있습니다. 클래스 간의 관계가 암묵적인 제약에 의존하고 있다면, 이를 컴포지션으로 분리하거나 제네릭을 통해 명시적인 관계로 전환하는 것이 견고한 코드를 만드는 핵심입니다.

코드 품질Kotlinrefactoringoop+3

line·2025년 5월 22일원문

코드 품질 개선 기법 12편: 세트 할인 (새 탭에서 열림)

여러 속성을 개별적으로 변경할 수 있게 허용하는 구조는 상태 간의 불일치를 초래하고 예기치 못한 버그를 유발할 수 있습니다. 이를 해결하기 위해 서로 연관된 상태들을 하나의 객체로 묶어 한 번에 업데이트하도록 인터페이스를 제한하면 시스템의 예측 가능성을 높일 수 있습니다. 결과적으로 코드의 의도가 명확해지고 스레드 안전성 확보와 디버깅이 훨씬 용이해집니다. **개별 속성 변경의 위험성** * **실행 순서 의존성:** 활성화 상태(`isActive`)와 세부 설정(`minImportanceToRecord` 등)이 분리되어 있으면, 설정을 변경하기 전에 활성화를 먼저 시도할 경우 의도치 않게 이전 설정값이 적용되는 문제가 발생합니다. * **상태 초기화의 불일치:** 특정 속성이 변경될 때 내부 카운터가 초기화되어야 함에도 불구하고, 어떤 속성은 초기화를 수행하고 어떤 속성은 누락하는 등의 관리 포인트가 파편화되어 로직이 복잡해집니다. * **경쟁 상태(Race Condition):** 비동기 환경에서 여러 속성을 순차적으로 변경하면, 변경 중간에 다른 로직이 개입하여 불완전한 상태의 데이터를 읽게 될 위험이 있습니다. **데이터 묶음과 인터페이스 제한을 통한 개선** * **객체 캡슐화:** 연관된 설정값들을 `SamplingPolicy`와 같은 별도의 불변(Immutable) 클래스로 묶어 관리함으로써 속성들이 항상 한 세트로 업데이트되도록 강제합니다. * **상태 표현의 최적화:** 별도의 불리언 플래그 대신 상태 객체의 `null` 여부로 활성화 상태를 표현하여, 활성 상태일 때는 반드시 유효한 설정값이 존재함을 보장합니다. * **원자적 업데이트:** `startRecording`과 같이 명시적인 메서드를 통해서만 상태를 변경하게 함으로써 내부 카운터 초기화와 설정 변경이 한 번에(Atomic) 이루어지도록 제어합니다. **실용적인 결론** 단순히 모든 필드에 세터(setter)를 열어두는 것보다, 비즈니스 로직상 함께 움직여야 하는 데이터는 하나의 '상태 객체'로 정의하는 것이 좋습니다. 특히 한 속성의 변화가 다른 속성의 의미나 동작에 영향을 주는 경우에는 인터페이스를 엄격하게 제한하여 잘못된 상태 조합이 발생하는 것을 원천적으로 차단해야 합니다.

코드 품질Kotlinsoftware-designrefactoring+2

line·2025년 5월 14일원문

코드 품질 개선 기법 11편: 반복되는 호출에 함수도 지친다 (새 탭에서 열림)

객체의 상태를 확인하고 그 결과에 따라 상태를 변경하는 로직은 호출자가 아닌 해당 객체 내부로 캡슐화하는 것이 코드 품질을 높이는 핵심입니다. 이를 통해 외부로 드러나는 상태 전이 로직을 단순화하고, 조건 확인 누락으로 인해 발생할 수 있는 잠재적인 버그를 효과적으로 방지할 수 있습니다. 특히 상태 변경 여부에 따른 후속 작업이 필요할 때는 복잡한 콜백보다 명확한 반환값을 활용하는 것이 코드의 가독성과 유지보수 측면에서 유리합니다. **상태 확인 로직의 내재화** * `if (receiver.a()) { receiver.b() }`와 같이 외부에서 객체의 상태를 묻고 동작을 결정하는 구조는 중복 호출의 번거로움과 확인 누락의 위험을 수반합니다. * 상태를 변경하는 함수(예: `markAsFriend`) 내부에서 직접 조건을 검사(예: `isFriend`)하도록 설계하면, 호출자는 객체의 내부 상태를 일일이 신경 쓰지 않고도 안전하게 기능을 수행할 수 있습니다. * 이러한 방식은 객체 내부의 상태 전이를 단순화하며, '이미 해당 상태인 경우 아무것도 하지 않는다'는 동작을 자연스럽게 보장합니다. * 만약 조건부 동작임을 명시적으로 드러내야 한다면 `markAsFriendIfNotYet`과 같이 함수 이름을 명확하게 짓거나 주석으로 보완하는 방법이 권장됩니다. **콜백 대신 반환값으로 결과 전달** * 상태 변경 성공 여부에 따라 팝업 노출과 같은 후속 작업이 필요할 때, 고차 함수를 통한 콜백(onSucceeded) 방식은 피하는 것이 좋습니다. * 콜백 방식은 의존성 순환을 일으킬 수 있고, 해당 로직이 동기적으로 실행되는지 비동기적으로 실행되는지 호출부에서 파악하기 어렵게 만듭니다. * 대신 `Boolean` 등의 반환값을 활용하면 호출자가 결과에 따라 후속 로직을 직접 제어할 수 있어 코드의 실행 흐름이 명확해집니다. * 이때 함수 이름에서 반환값의 의미가 명확히 드러나지 않는다면 문서화를 통해 보완하고, 호출자가 반환값을 반드시 확인하도록 강제하는 기법을 함께 사용할 수 있습니다. 객체 설계 시 "묻지 말고 시키라(Tell, Don't Ask)"는 원칙을 적용해 보시기 바랍니다. 객체 외부에서 상태를 묻고 판단하기보다, 객체가 스스로 자신의 상태를 확인하고 동작하게 함으로써 더 견고하고 읽기 쉬운 코드를 작성할 수 있습니다.

코드 품질Kotlinsoftware-designrefactoring+1

line·2025년 5월 9일원문

코드 품질 개선 기법 10편: 적절한 거리 유지에 신경 쓰자 (새 탭에서 열림)

코드 품질을 높이기 위해서는 각 레이어나 컴포넌트가 서로의 세부 구현을 알지 못하도록 적절한 거리를 유지하는 것이 중요합니다. 특히 UI와 데이터 레이어가 암묵적인 규칙을 공유하며 의존할 경우, 사양 변경 시 예측하지 못한 버그가 발생하기 쉬우므로 명확한 상태 값과 인터페이스를 통해 책임을 분리해야 합니다. **암묵적 정보 공유의 문제점** * 리포지터리 레이어에서 UI의 표시 형식을 고려해 '최대 개수 + 1'의 데이터를 조회하는 식의 구현은 레이어 간의 경계를 무너뜨립니다. * UI 레이어가 리포지터리의 특정 동작(예: 100개 초과 시 리스트 크기가 101임)에 의존해 비즈니스 로직을 판단하면 코드의 가독성과 유지보수성이 떨어집니다. * 이러한 방식은 주석으로만 의도를 설명할 수 있을 뿐, 코드 구조 자체로는 데이터의 의미를 명확히 전달하지 못하는 한계가 있습니다. **명시적인 속성을 활용한 책임 분리** * 모델 클래스에 `hasMoreItems`와 같은 명시적인 불리언 속성을 추가하여 데이터의 상태를 직접적으로 표현하는 것이 좋습니다. * 리포지터리는 모델 인스턴스를 생성할 때 추가 데이터 존재 여부를 판단하는 로직을 수행하고, UI에는 정제된 데이터만 전달합니다. * UI 레이어는 더 이상 특정 상수값이나 리포지터리의 조회 규칙을 알 필요 없이, 모델이 제공하는 속성에만 기반하여 화면을 구성할 수 있게 됩니다. **로직과 상수의 적절한 위치 선정** * 데이터 개수를 제한하는 상수(`ITEM_LIST_MAX_COUNT`)는 서비스의 성격에 따라 비즈니스 로직 레이어(도메인, 유스 케이스 등)에서 정의하는 것이 이상적입니다. * 비즈니스 레이어를 별도로 두기 어려운 규모라면 모델 클래스 내부에 정의할 수도 있으나, 이때는 데이터 구조와 알고리즘 간의 의존 방향이 모호해지지 않도록 주의해야 합니다. * 특정 기능에 국한된 로직이 범용적인 데이터 모델에 포함되어 재사용성을 해치지 않는지 검토하는 과정이 필요합니다. **실용적인 제언** 코드 작성 시 "이 컴포넌트가 다른 컴포넌트의 내부 사정을 너무 자세히 알고 있지는 않은가?"를 자문해 보시기 바랍니다. 다른 레이어의 세부 동작에 암묵적으로 의존하는 코드를 피하고, 인터페이스를 통해 명확한 정보를 주고받도록 설계하는 것이 변경에 유연한 소프트웨어를 만드는 핵심입니다.

코드 품질Kotlinsoftware-designrepository-pattern+2