매일 성장하기

1. FSD란 무엇인가?Feature-Sliced Design(FSD)은 프로젝트를 기능 중심으로 구조화하여 유지보수성과 확장성을 높이는 방법론입니다. 기존 계층 기반 아키텍처(MVVM, 클린 아키텍처)와 달리 기능 단위로 모듈을 나누고, 관련된 코드(UI, 비즈니스 로직, 데이터 등)를 한 곳에 배치하는 방식을 따릅니다. 이를 통해 코드의 응집도를 높이고, 기능 단위의 독립성을 유지할 수 있습니다. FSD는 여러 계층으로 구성되며, 각 계층이 서로 긴밀히 연결됩니다. 각 계층이 어떻게 상호작용하는지를 이해하는 것이 중요합니다. 이제 FSD의 핵심 계층을 살펴보고, 하나의 기능을 중심으로 이 계층들이 어떻게 유기적으로 연결되는지 예제를 통해 설명하겠습니다. 2. FSD의 핵심 계층1) App Layer ..

소프트웨어 개발에서 구조화의 중요성개발을 하다 보면 코드가 점점 커지고 복잡해지면서 유지보수가 어려워지는 순간이 옵니다. 작은 프로젝트라면 괜찮겠지만, 기능이 추가되고 팀원이 늘어나면서 코드의 일관성과 재사용성을 유지하는 것이 점점 힘들어집니다. 전통적으로 MVC, MVVM, Clean Architecture 같은 다양한 패턴을 사용해 왔습니다. 하지만 이러한 패턴에도 모호한 부분이 존재하고, 기능이 많아질수록 구조를 유지하는 것이 어려워집니다. 여기서 등장하는 것이 바로 Feature-Sliced Design (FSD)입니다.  FSD는 기능 중심으로 코드를 정리하는 방법론으로, 코드의 위치를 명확히 정의하고, 유지보수성과 확장성을 극대화하는 데 초점을 맞춥니다. 이제, 기존 아키텍처와 비교하며 FSD..

클린 코드(clean code)는 로버트 C. 마틴(Robert C. Martin)의 저서에서 제안된 개념으로, 이해하기 쉽고, 변경하기 용이하며, 예측 가능해야 한다는 특징을 갖습니다. 클린 코드를 달성하는 방법 중 하나는 OOP 원칙을 따르는 것입니다. OOP는 현실 세계의 개념을 모델링하는 방식으로, 객체와 클래스를 활용해 소프트웨어 시스템을 구성합니다. 하지만 단순히 객체를 사용하는 것만으로는 클린 코드가 보장되지 않습니다. 잘못된 객체 모델링은 오히려 복잡성을 증가시키고, 유지보수를 어렵게 만들 수 있습니다. 이러한 문제를 해결하기 위해 등장한 것이 바로 MAPPER 원칙입니다.MAPPER 원칙이란?현실 세계를 반영하는 소프트웨어 설계 원칙에서 설명한 내용을 MAPPER라는 원칙으로 설명하는 책..

소프트웨어 개발에서 가장 중요한 목표 중 하나는 예측 가능성과 유지보수성을 확보하는 것입니다. 이를 위해 가장 중요한 원칙은 각 도메인 개념이 소프트웨어 엔터티와 1:1로 대응되어야 한다는 것입니다. 이 원칙은 객체지향 프로그래밍(OOP), 도메인 주도 설계(DDD), 그리고 클린 코드 접근법에서도 동일하게 적용됩니다.1. 현실 세계를 반영하는 1:1 매핑 원칙소프트웨어는 현실을 그대로 반영해야 합니다. 현실 세계에 존재하는 개념이 소프트웨어에서도 하나의 모델로 존재해야 하며, 여러 개의 객체나 시스템에 분산되어서는 안 됩니다. 예를 들어:현실에서 자동차(Car)가 존재한다면, 소프트웨어에서도 Car 클래스가 있어야 합니다.직원(Employee)이 있고, 그 직원이 월급과 직책을 가진다면, 이 속성들은 ..

저는 발표를 시작할 때 분위기를 부드럽게 만들기 위해 농담을 던지곤 했습니다. "이 발표가 끝나면 다들 졸지 않고 끝까지 들었으면 좋겠습니다!" 같은 말을 했었죠. 그런데 "How to Speak" 유튜브 영상을 보고 중요한 사실을 깨달았습니다. 발표를 들으면 무엇을 얻을 수 있는지를 먼저 알려주는 것이 청중의 집중력을 높이는 데 훨씬 효과적이라는 것입니다. 이 방식을 적용해 보니, 청중이 발표에 더 집중하고 발표 내용에 대한 반응이 더욱 활발해졌습니다. 그래서 저는 발표 초반에 가볍게 웃을 수 있는 요소는 유지하되, "이 발표를 들으면 이런 것들을 배울 수 있습니다!" 라는 메시지를 명확하게 전달하는 방식으로 개선했습니다. 많은 도움이 되었던 내용을 정리하는 차원에서 기록으로 남깁니다. 이 글을 읽어보..

소프트웨어 유지보수와 테스트 자동화를 어렵게 만드는 주요 요인 중 하나는 의존성(Dependency)입니다. 레거시 코드에서는 특히 static 메서드가 이러한 문제를 심화시키는 경우가 많습니다. static 메서드는 특정한 상태를 가지지 않고 클래스 레벨에서 호출되기 때문에, 객체를 주입하여 대체하기 어렵습니다. 이러한 문제를 해결하는 방법 중 하나가 Introduce Instance Delegator 기법입니다. 이 기법은 기존 static 메서드를 인스턴스 메서드로 감싸서 객체를 통해 호출할 수 있도록 만드는 방식입니다. 이를 활용하면 기존 코드를 크게 변경하지 않으면서도 의존성을 줄이고, 테스트 가능성을 높일 수 있습니다. Introduce Instance Delegator 기법 적용Introdu..

소프트웨어 유지보수와 테스트 자동화를 어렵게 만드는 주요 요인 중 하나는 의존성(Dependency)입니다. Working Effectively with Legacy Code에서 소개된 "인터페이스 추출(Extract Interface)" 기법은 이러한 의존성을 줄이고, 테스트 가능성을 높이는 데 중요한 역할을 합니다. 이번 글에서는 인터페이스 추출 기법의 개념과 이를 활용하여 코드의 테스트 가능성을 높이는 방법을 살펴보겠습니다.1. 인터페이스 추출이란?인터페이스 추출(Extract Interface)은 기존 클래스에서 특정한 역할을 수행하는 메서드들을 추출하여 새로운 인터페이스를 정의하는 기법입니다. 이를 통해 기존 코드의 직접적인 의존성을 줄이고, 테스트를 위한 대체 구현(Fake, Mock 등)을 ..

코드의 테스트 가능성과 유지보수성을 높이기 위해 의존성 관리가 핵심 과제가 됩니다. 오늘은 "Extract and Override Getter" 기법을 살펴보며, 클래스 내부의 복잡한 의존성을 어떻게 효과적으로 분리하고 테스트 가능한 구조로 바꿀 수 있는지에 대해 이야기하겠습니다.문제 정의: 내부 의존성의 문제점클래스 내부에서 객체를 직접 생성하거나 관리하면, 그 클래스는 해당 의존성에 강하게 결합됩니다. 이로 인해 다양한 문제가 발생합니다. 첫 번째로, 테스트 작성이 복잡해집니다. 외부에서 의존성을 대체하거나 모의(Mock) 객체를 주입하기 어려운 구조 때문에 코드 테스트가 제한적이 됩니다. 두 번째로, 요구사항 변화에 따른 코드 변경이 어렵습니다. 의존성이 코드에 하드코딩되어 있으면 수정 범위가 넓어..

Working Effectively with Legacy Code는 레거시 코드와 마주했을 때 작업을 안전하고 점진적으로 진행할 수 있는 구체적인 전략과 마음가짐을 제시하는 책입니다. 레거시 코드 속에서 오랜 시간 고통받아 왔던 제게, 이 책은 큰 깨달음을 주었습니다. 테스트는 이제 선택이 아니라 필수라는 마음가짐을 갖게 되었습니다. 비록 주변에서는 여전히 테스트에 대한 관심이 크지 않아, 개발자 수준의 테스트가 필수적인 활동으로 여겨지지 않더라도, 저는 꾸준히 테스트를 놓지 않고 이어나갈 결심을 하게 되었습니다. 퇴사하기 전까지, 적어도 제가 있는 동안만이라도 계속 노력할 생각입니다. 어떤 책에서는 더 나은 환경의 회사로 이직하는 것도 방법이라고 조언하지만, 오랜 시간을 버텨온 이곳을 떠나는 게 참 어..

소프트웨어 개발자는 종종 기존 코드(레거시 코드)를 다룰 때 어려움을 겪습니다. 이러한 코드는 종종 유지보수하기 어렵고, 테스트 가능성이 낮으며, 새로운 요구 사항에 맞게 변경하기도 까다롭습니다. "호출 추출과 재정의(Extract and Override Call)"는 이러한 문제를 해결하기 위한 의존성 제거 기법입니다. 이 글에서는 호출 추출과 재정의의 개념, 적용 방법, 코드 예제, 그리고 테스트 작성법을 살펴보겠습니다.호출 추출과 재정의란 무엇인가요?호출 추출과 재정의는 클래스 내에서 특정 호출을 별도의 보호(protected) 메서드로 분리하고, 이 메서드를 서브클래스에서 재정의할 수 있게 만드는 기법입니다. 이 리팩토링 방법은 테스트 가능성을 크게 높이고, 외부 의존성을 관리하며, 코드의 유연성..