Eternity's Chit-Chat Eternity's Chit-Chat

소프트웨어 공학의 선구자들은 소프트웨어 개발이라는 미숙아를 양육하기 위한 정신적 모델을 구축하기 위해 상대적으로 성숙한 다른 공학 분야로부터 다양한 용어와 개념을 차용해 왔다. 소프트웨어 공학에 영향을 끼친 분야 중에서도 가장 중요한 메타포를 제공한 분야는 건축학이다. 건축학으로부터 차용한 용어 중 가장 많은 사람들에 의해 정의된 용어가 바로 ‘소프트웨어 아키텍처(Software Architecture)’일 것이다. 다양한 정의가 존재한다는 것은 역설적으로 용어를 사용하는 사람들 사이에 공감대를 거의 형성하지 못하고 있다는 이야기와 같다. 소프트웨어 아키텍처에 대한 수 많은 정의 중에서 비교적 널리 알려진 것은 아래 정의일 것이다.프로그램이나 컴퓨팅 시스템의 소프트웨어 아키텍처는 소프트웨어 구성요소와 ..

제 글이나 강의를 보신 분들은 잘 아시겠지만 설계에 있어 가장 중요하게 생각하는 개념은 트레이드오프(trade-off)입니다. 일반적으로 트레이드오프는 한 가지를 얻기 위해 다른 것을 포기해야 하는 긴장 상황을 의미합니다. 트레이드오프라는 용어를 가장 쉽게 이해할 수 있는 방법은 돈과 시간을 배분하는 경우를 상상하는 것입니다. 돈을 투자할 때는 항상 리스크와 수익 사이에서 트레이드오프를 하게 됩니다. 제 손에 쥐어진 꼬깃꼬깃한 지폐로 아이스크림을 사 먹으려면 과자는 포기해야 합니다. 지금처럼 긴 글을 쓰기 위해서는 게임을 플레이할 수 있는 시간을 포기해야 합니다. 제가 가장 좋아하는 예는 침팬지와 인간의 진화에 관한 이야기입니다. 아래 그림을 보면 인간에 비해 침팬지의 순간 기억력이 인간보다 훨씬 뛰어나..

이전 글 :도메인 특화 언어와 단위 테스트 - 7부테스트 케이스 리팩토링TEST DATA BUILDER를 구현했으므로 이제 이전에 작성한 테스트 케이스를 리팩토링하자. 먼저 대륙의 수가 정확한 지를 검증하는 ContinentSpecification의 테스트 케이스부터 살펴 보자. ContinentSpecification은 Continent가 명세를 만족하는 지만 검증하므로 ContinentSpecification테스트를 위해서는 Continent픽스처를 제외한 다른 정보들은 불필요하다. Atmosphere나 Ocean은 Planet을 생성하기 위해 요구되는 정보일 뿐 현재의 테스트 결과와는 직접적인 관계가 없다. 따라서 에 나열된 현재의 테스트 케이스는 핵심적인 정보가 불필요한 정보의 홍수 속에 묻혀 있..

이전 글 : 도메인 특화 언어와 단위 테스트 - 6부테스트 도메인에 특화된 언어지금까지 살펴 본 것처럼 픽스처로 사용할 객체의 구조가 복잡하고 그로 인해 테스트의 결과를 예측하기 어려울 경우 테스트 케이스를 작성하려는 개발자의 의지는 좌절된다. 테스트를 생성하기 위해 미로처럼 복잡한 픽스처의 내부 구조를 이해해야 할 경우 테스트 케이스의 작성을 미루는 경향이 있다. 실패한 테스트 케이스를 열어 보았을 때 픽스처 설정 부분이 길고 복잡해서 실패의 원인을 파악하기 어려운 경우 테스트 실행 목록에서 해당 테스트 케이스를 제외하거나 테스트가 실패하지 않도록 코드의 구조를 왜곡시킨다. 결국 테스트는 상환하지 못 할 기술 부채(technical debt)를 누적시키는 원흉으로 전락하고 만다. 픽스처로 사용할 객체의..

이전  글 : 도메인 특화 언어와 단위 테스트 - 5부내부 DSL(Internal DSL)내부 DSL은 호스트 언어가 가진 제약 내에서 DSL을 구축한다. 호스트 언어에 대한 의존성은 양날의 검과 같다. 별도의 파서나 도구를 개발하지 않고도 호스트 언어가 제공하는 컴파일러만 있으면 쉽게 DSL을 구축할 수 있다. 그러나 DSL의 표현력이 호스트 언어의 표현력에 의해 제약을 받기 때문에 외부 DSL에 비해 언어의 유창함과 간결함이 상대적으로 떨어지는 경향이 있다. 또한 호스트 언어에서 사용 가능한 어떤 표현이라도 DSL 내에서 적법한 표현이기 때문에 범용 언어의 자유로움 속에서 DSL의 단순함을 잃어버릴 여지가 있다. 또한 언어에 대한 설계와 언어를 사용하는 사고 방식이 호스트 언어의 틀 안에 구속될 수 ..

이전 글 : 도메인 특화 언어와 단위 테스트 - 4부소프트웨어의 본질적인 복잡성프레더릭 브룩스는 그의 기념비적인 논문 “은총알은 없다(No Silver Bullet)”에서 소프트웨어 개발과 관련된 작업을 본질적인 작업(essential task)과 부차적인 작업(accidental task)으로 구분하고 있다. 브룩스에 따르면 본질적인 작업이란 도메인 내의 추상적인 개념들을 명세하고 설계하고 구현 가능한 상태로 정교하게 다듬는 정신적인 작업을 의미한다. 이에 반해 부차적인 작업이란 고안된 추상화를 공간과 시간 제약 속에서 프로그래밍 언어로 변환하는 작업을 말한다.프레더릭 브룩스는 불행히도 소프트웨어 개발과 관련된 전체 작업 가운데 부차적인 작업이 차지하는 비율이 90%를 넘지 않는 한 부차적인 작업에 쏟..

이전 글 : 도메인 특화 언어와 단위 테스트 - 3부FACTORY를 이용한 생성 메서드(CREATION METHOD) 중복 제거픽스처 생성과 관련해서 테스트 케이스 간의 중복을 제거하는 또 다른 방법은 테스트 케이스의 슈퍼 클래스가 아닌 별도의 독립 클래스로 생성 메서드(CREATION METHOD)를 옮기는 것이다. 독립 클래스는 테스트에 필요한 픽스처를 생성하기 위한 오퍼레이션을 제공하는 일종의 FACTORY다. 이처럼 테스트 케이스 클래스 간의 중복 코드를 제거하기 위해 재사용 가능한 테스트 유틸리티 메서드(TEST UTILITY METHOD)를 제공하는 독립적인 클래스를 테스트 도우미(TEST HELPER)라고 한다.테스트 케이스 슈퍼클래스(TESTCASE SUPERCLASS)의 경우 테스트 케이..

이전 글 : 도메인 특화 언어와 단위 테스트 - 2부테스트 코드 리팩토링테스트와 관련 없는 정보(IRRELEVANT INFORMATION)를 너무 상세하게 노출시켜 애매한 테스트(OBSCURE TEST)가 되어버리는 문제를 해결할 수 있는 한 가지 방법은 안정적인 인터페이스를 이용해 픽스처를 생성하는 코드를 캡슐화시키는 것이다. 가장 간단한 방법은 픽스처 생성 코드를 메서드로 추출(EXTRACT METHOD 리팩토링)해서 별도의 테스트 유틸리티 메서드(TEST UTILITY METHOD)로 분리하는 것이다. 이처럼 픽스처를 생성하기 위한 목적을 가진 독립적인 테스트 유틸리티 메서드(TEST UTILITY METHOD)를 생성 메서드(CREATION METHOD)라고 한다. 다음은 픽스처를 생성하기 위해 ..