매일 성장하기

과학은 문제에서 시작하며, 문제를 해결하기 위해 시행착오라는 방법을 선택합니다. 20세기 가장 위대한 철학자로 꼽히는 칼 포퍼는 모든 생물이 문제를 해결하기 위해 같은 패턴으로 움직인다고 이야기합니다. 이 글에서는 칼 포퍼의 3단계 모델을 통해 시행착오의 과정을 살펴보고, 아메바와 아인슈타인의 사례를 통해 시행착오가 갖는 의미를 살펴보고, 더 나아가, 소프트웨어 개발 분야에서 시행착오가 어떻게 적용될 수 있는지, 그리고 테스트 코드를 기반으로 코딩하는 것이 왜 효과적인 방법인지 SW 개발자의 관점에서 살짝 말해보려고 합니다.칼 포퍼의 시행착오 3단계 모델칼 포퍼는 시행착오를 통한 학습 과정을 3단계 모델로 정리했습니다.문제: 기대와 다른 결과가 나타나거나, 기존의 해결 방식이 더 이상 작동하지 않을 때 ..

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

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

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