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

괜찮아 보이는 개발 서적이 있으면 당장 필요하지 않더라도 '나중에 읽겠지' 하는 마음으로 일단 사두는 편입니다. 그러다 보니 쌓인 책들을 주기적으로 몰아서 읽는 시간을 갖곤 하는데, 작년 12월이 바로 그런 시간이었습니다. 한 달 정도 여유를 갖고 방치해두었던 책 몇 권을 읽었고, 그중 인상 깊었던 두 권을 소개합니다.첫 번째는 《클라우드 네이티브 스프링 인 액션(제이펍)》입니다. 이 책은 구성이 체계적이고 완급 조절이 정말 뛰어납니다. Spring Boot를 시작으로 다양한 Spring Cloud 프로젝트, 도커, k8s까지 방대한 기술을 연이어 다루는데, 이해에 부족함이 없도록 상세히 서술하면서도 너무 깊어지지 않게 불필요한 내용은 덜어내는 저자의 능력이 감탄스러울 정도였습니다.책의 구성 또한 훌륭합..

다음 강의 소식을 궁금해하시는 분들이 종종 계시는데, 현재 작업 중인 강의는 '유지보수성 향상'에 초점을 맞추고 있습니다. 이번 강의 역시 평소처럼 객체지향 설계 관점에서 코드를 이해하고, 수정하기 쉽게 만드는 기법들을 정리하려고 합니다. 개인적으로 병행하는 일이 있어서 작업 속도가 다소 느리지만, 분량이 많지는 않아서 조만간 마무리할 수 있을 것 같습니다.이번에는 기존과는 조금 다르게 '패턴 언어(Pattern Language)' 방식으로 설계 기법을 정리하고 있는데요. 최근에는 언급되는 빈도가 낮아졌지만 다양한 원칙, 기법, 프랙티스들의 관계와 혼용 방법을 체계화하고 설명할 수 있는 유용한 도구라고 할 수 있습니다. 예전부터 패턴 언어 형식을 빌려 강의 자료를 만들고 싶다는 생각을 품고 있었는데 이번..

소프트웨어 공학의 선구자들은 소프트웨어 개발이라는 미숙아를 양육하기 위한 정신적 모델을 구축하기 위해 상대적으로 성숙한 다른 공학 분야로부터 다양한 용어와 개념을 차용해 왔다. 소프트웨어 공학에 영향을 끼친 분야 중에서도 가장 중요한 메타포를 제공한 분야는 건축학이다. 건축학으로부터 차용한 용어 중 가장 많은 사람들에 의해 정의된 용어가 바로 ‘소프트웨어 아키텍처(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%를 넘지 않는 한 부차적인 작업에 쏟..