매일 성장하기

소프트웨어 개발에서 복잡한 클래스의 초기화는 테스트 작성과 유지보수성을 어렵게 만드는 주요 요인 중 하나입니다. "정적 메소드 드러내기(Expose Static Method)" 기법은 이러한 문제를 해결하기 위한 효과적인 리팩토링 방법으로, 특정 메소드를 정적(static) 메소드로 변환하여 클래스 초기화 없이 직접 호출할 수 있도록 만듭니다. 이 글에서는 해당 기법의 개념, 예제 코드, 그리고 테스트 코드 작성 방법을 설명합니다. 1. 정적 메소드 드러내기란?정적 메소드 드러내기는 다음과 같은 상황에서 유용합니다:클래스 초기화 문제: 테스트 또는 사용 중 클래스 생성이 어렵거나 불필요하게 복잡한 경우.독립적 로직: 메소드가 클래스의 멤버 변수에 의존하지 않고 독립적으로 동작하는 경우.유틸리티화: 메소드..

임베디드 시스템을 개발하는 환경에서 테스트는 종종 골칫거리로 여겨집니다. 특히 레거시 코드가 많이 쌓여 있는 경우에는 더욱 그렇습니다. 하지만 이런 상황에서도 기능 수준에서 동작을 확인할 수 있는 방법이 있습니다. 이번 글에서는 임베디드 시스템의 C++ 코드를 직접 다루지 않고도 외부에서 Python을 사용해 기능 테스트를 수행하는 방식을 소개하겠습니다. 또한 이 과정에서 Cucumber를 활용해 쉽고 읽기 좋은 테스트 코드를 작성하는 방법도 다룹니다.왜 Python을 사용하는가?Python은 단순함과 강력한 라이브러리 생태계 덕분에 테스트 자동화에 매우 적합한 언어입니다. C++로 작성된 임베디드 시스템의 테스트 코드를 직접 작성하려면 복잡한 빌드 환경과 코드 수정이 필요할 수 있지만, Python을 ..

소프트웨어 개발에서 전역 변수는 편리하지만, 유지보수성과 테스트 가능성을 크게 저하시킬 수 있습니다. 전역 참조 캡슐화(Encapsulate Global Reference)는 이러한 문제를 해결하기 위해 전역 변수를 추상화 계층 뒤로 숨기고, 코드의 결합도를 줄이며, 테스트 가능성을 높이는 의존성 제거 기법입니다. 이 글에서는 해당 기법의 개념, 적용 방법 및 테스트 코드 작성 예제를 살펴봅니다. 1. 전역 참조 캡슐화란?전역 참조 캡슐화는 전역 변수나 전역 함수와 같은 전역 상태를 직접 참조하지 않도록 하여 코드의 결합도를 줄이는 기법입니다. 이를 위해 전역 참조를 캡슐화한 클래스나 인터페이스를 생성하고, 해당 인터페이스를 통해 전역 상태를 간접적으로 관리합니다.이 기법은 다음과 같은 이점을 제공합니다..

소프트웨어 개발에서 의존성을 제거하거나 줄이는 작업은 유지보수성과 테스트 가능성을 크게 향상시킵니다. 특히, "메소드 객체 추출(Break Out Method Object)" 기법은 기존의 복잡한 메서드를 분리하여 단일 책임 원칙(Single Responsibility Principle)을 따르는 독립된 클래스로 재구성하는 유용한 방법입니다. 이 글에서는 메소드 객체 추출의 개념, 이점, 적용 방법 및 이를 활용한 테스트 코드 작성법을 살펴봅니다. 메소드 객체 추출(Break Out Method Object)란?기존의 클래스가 지나치게 복잡한 메서드를 포함하고 있을 때, 해당 메서드를 별도의 클래스로 추출하여 책임을 분리하고 코드를 단순화하는 기법입니다. 이를 통해 다음과 같은 효과를 얻을 수 있습니다:..

레거시 코드는 소프트웨어 개발자에게 큰 도전 과제가 될 수 있습니다. 시스템이 커지고 복잡해질수록 코드의 의존성은 점점 더 강해지고, 이는 유지보수와 테스트를 어렵게 만듭니다. 하지만 의존성을 제거하고 코드를 개선하는 작업은 매우 중요한 과정입니다. 이 글에서는 의존성이 무엇인지, 왜 의존성을 제거해야 하는지, 그리고 의존성을 제거하는 여러 기법 중 매개변수 적응(Adapt Parameter) 기법에 대해 다뤄보겠습니다. 의존성이란 무엇인가?의존성(dependency)이란, 코드가 다른 클래스, 모듈, 라이브러리 등 외부 요소에 얼마나 의존하고 있는지를 나타냅니다. 의존성이 높으면 높을수록 코드가 다른 시스템에 강하게 결합되어 독립적으로 테스트하기 어렵고, 시스템을 변경할 때마다 리스크가 증가합니다. 예..

소프트웨어(SW) 개발의 본질을 이해하는 것은 성공적인 프로젝트를 위해 반드시 필요한 요소입니다. 많은 사람들이 개발이 단순히 코드를 작성하는 작업이라고 생각하지만, 실제로는 훨씬 복잡하고 예측하기 어려운 과정을 포함합니다. 개발 과정에서 본질적인 어려움을 무시하면 고객의 요구와는 동떨어진 결과물이 나올 가능성이 높습니다.개발의 본질: 어렵고, 예측 불가능하다개발은 근본적으로 복잡한 문제를 해결하는 과정입니다. 고객의 요구는 추상적이거나 모호할 수 있고, 이를 명확히 이해하지 못하면 프로젝트 방향은 흔들리기 마련입니다. 여기에 시장의 변화, 기술적 제약, 팀 역량 등 다양한 변수까지 더해지면 성공적인 결과를 예측하기란 거의 불가능에 가깝습니다. 제가 경험한 대부분의 프로젝트에서 운 좋게 모든 것이 한 번..

소프트웨어 개발에서 코드 리뷰는 단순히 코드 품질을 확인하는 과정 이상의 가치를 제공합니다. 특히 팀원 간의 코드에 대한 멘탈 모델(Mental Model)을 동기화하는 데 중요한 역할을 합니다. 이러한 멘탈 모델의 중요성과 이를 강화하는 방법, 그리고 궁극적으로 코드 리뷰가 어떻게 더 나은 코드와 아키텍처 개선으로 이어질 수 있는지 살펴보겠습니다. 멘탈 모델이란 무엇인가? 멘탈 모델은 사람들이 세상이나 특정 시스템이 어떻게 작동하는지에 대해 가지는 정신적 틀이나 이해를 의미합니다. 소프트웨어 개발 맥락에서는, 멘탈 모델은 코드, 시스템 아키텍처, 도메인 로직에 대한 개발자의 직관적 이해와 추론 방식을 포괄합니다. 팀이 효과적으로 협업하려면 팀원 간 멘탈 모델이 유사해야 합니다. 한 개발자가 특정 함수나..

클린 아키텍처(Clean Architecture)는 소프트웨어 설계 원칙을 통해 시스템의 유지보수성과 확장성을 극대화하려는 개발 방법론입니다. 로버트 C. 마틴(Uncle Bob)이 제안한 이 개념은 의존성 역전(DIP: Dependency Inversion Principle)을 중점으로, 비즈니스 로직과 UI, 데이터 계층 간의 결합도를 낮추는 데 초점을 맞춥니다. Screaming Architecture (스스로 외치는 아키텍처)Screaming Architecture는 소프트웨어의 아키텍처가 "이 시스템이 무엇을 하는지"를 명확히 드러내야 한다는 개념을 의미합니다. 즉, 디렉토리 구조와 코드 네이밍이 시스템의 주요 비즈니스 목적을 전달해야 한다는 것입니다. 이를 통해 새로운 개발자가 코드를 처음 접..

끝나지 않는 굴레, 그리고 소프트웨어 개발의 본질소프트웨어(SW) 개발은 끝없는 반복의 연속입니다. 생각을 구체화하고 이를 코드로 실현하며, 결과물을 통해 요구사항을 더 잘 이해하는 과정을 거칩니다. 이 과정은 단순히 한 번으로 끝나지 않습니다. 부족한 점이 발견되면 다시 생각을 정리하고, 수정된 요구사항을 반영하며, 코드를 개선하고 또 개선합니다. 이는 소프트웨어 개발에서 피할 수 없는 굴레입니다.  이 피할 수 없는 굴레가 선순환으로 자리 잡아 하나의 개발 문화가 되는 회사가 있는가 하면, 끝내 잡히지 않는 신기루처럼 느껴지는 회사도 있습니다. 선순환 구조를 구축한 회사는 조직 전체가 소프트웨어 개발의 가치를 깊이 이해하고 실천하는, 좋은 SW 회사일 가능성이 높습니다. 소프트웨어의 진화: 자연스러움..