알라딘

헤더배너
1/0 photos
신간알리미 신청
 상품평점 help

분류

이름:살림 시디퀴

최근작
2024년 6월 <테스트 주도 개발 입문>

살림 시디퀴

소프트웨어 개발자, 교육자, 연사이자 저자다. 몇 번의 기술 호황과 불황이 반복되는 시기를 겪으며 의료, 유통, 관공서, 금융 및 제약 부문에서 크고 작은 팀의 일원으로 소프트웨어를 개발했다. 소프트웨어를 개발하는 동안 부끄러운지도 모른 채 저질렀던 실수에서 얻은 교훈을 다른 이들과 공유하고자 한다.
노력을 토대로 세계 무대로 나아가길 즐긴다. 경험을 글로 풀어 블로그(http://thesaleem.com/blog)에 게시하는데, 가끔은 제삼자의 관점에서 쓴 글도 볼 수 있다.  

대표작
모두보기
저자의 말

<테스트 주도 개발 입문> - 2024년 6월  더보기

우리는 말로 표현할 수 없을 만큼 운이 좋다. 우리는 수년간 테스트 주도 개발을 했다. 머큐리 우주 프로그램 코드를 작성한 개발자들이 펀치 카드로 테스트 주도 개발(Test-Driven Development, TDD)을 실천한 지도 수십 년이 지났다(https://oreil.ly/pKpSZ). 테스트 주도 개발적용을 수월하게 하는 XUnit 라이브러리는 세기를 거슬러 올라간다. 사실, 『테스트 주도 개발』(인사이트, 2014)을 저술하고 JUnit 프레임워크를 개발한 켄트 벡은 스스로 테스트 주도 개발의 실천(https://oreil.ly/zDyBr)을 발명이 아닌 ‘재발견’이라 말한다. 이 표현은 그의 겸손의 증거이면서도 사실이다. 테스트 주도 개발은 소프트웨어 개발만큼이나 오래됐다. 그렇다면 테스트 주도 개발이 표준 코드 작성 방식과 여전히 거리가 먼 이유는 무엇일까? 일정의 압박이 있을 때, 또는 IT 예산을 줄여야 할 때, 또는(개인적으로 가장 좋아하는) ‘소프트웨어 딜리버리 팀의 속도 향상’이 필요할 때 흔히 희생돼야 하는 첫 번째 대상이 테스트 주도 개발일까? 테스트 주도 개발은 결함 개수를 줄이고 설계를 더 간단하게 만들며 개발자 스스로가 갖는 코드에 대한 신뢰를 향상시키는 데 경험적이고 실험적인 증거가 있음에도 이런 모든 이유가 제시된다. 테스트 주도 개발이 마지못해 채택되거나 쉽게 버려지는 이유는 무엇일까? 테스트 주도 개발 실천을 꺼리는 이들이 주장은 크게 두 가지다. 첫째, 어디서부터 어떻게 시작해야 할지 모르겠다. 아마도 가장 흔한 이유는 인지도와 노출의 부족이다. 다른 기술과 같이, 테스트 주도 스타일의 코드 작성은 배워야 한다. 많은 개발자들은 이 기술을 배울 외적 동기(시간, 리소스, 지침, 격려)도 내적 동기(꺼리는 마음과 두려움 극복)도 없다. 둘째, 테스트 주도 개발은 토이 프로그램이나 인터뷰에서는 쓸 법하나 ‘실제 세계’ 코드 작성에는 제대로 작동하지 않는다. 사실이 아니지만 이해는 된다. 대부분의 테스트 주도 개발 튜토리얼과 이 책을 포함한 서적에서는 뻔한 도메인에서 비교적 간단한 예제를 선택하도록 강요한다. 상업적으로 배포된 애플리케이션(예: 금융 기관, 의료 관리 시스템, 자율주행자동차)에서 빼낸 소프트웨어 조각의 실제 코드를 바탕으로 테스트 주도 개발 기사나 책을 쓰기는 어렵다. 우선 한 가지 이유는, 실제 코드는 대부분 독점 소유권이 있으며 오픈 소스가 아니다. 다른 이유로는, 가장 많은 청중들에게 가장 폭넓은 관심을 가질 도메인의 코드를 보여주는 것은 저자의 역할이다. 고도로 전문적인 도메인의 문맥상에서 테스트 주도 개발을 보여주는 것은 애매함에 경계에 있어 비논리적이다. 그렇게 하려면 무엇보다 해당 도메인의 난해한 전문 용어와 은어들의 장황한 설명이 필요하다. 테스트 주도 개발을 이해하기 쉽고, 접근하기 쉬우며, 심지어 사랑스럽게 만들려는 저자의 의욕을 꺾게 될 것이다. 테스트 주도 개발 문헌에서 실제 세계 코드를 사용함에 있어 이런 장애물에도 불구하고, 개발자는 어김없이 테스트 주도 개발로 프로덕션 소프트웨어를 작성한다. 아마도 최고의 설득력 있는 예시는 JUnit 프레임워크(https://oreil.ly/UCPcg) 자체에 대한 단위 테스트 스위트일 것이다. 리눅스 커널(아마 세계에서 가장 활발히 사용되고 있는 소프트웨어 조각)은 단위 테스트를 바탕으로 개선되고 있다. 코드 작성부터 하고 테스트를 작성해도 충분하다. 테스트 주도 개발은 너무 제한적이고 현학적이다. 이 주장은 ‘단위 테스트는 지나치게 과대 평가됐다(https://oreil.ly/Y7S5M)’라고 가끔 큰소리치는 것을 듣는 것보다 더 신선하다! 프로덕션 코드를 작성한 후 작성하는 테스트는 아무런 테스트도 작성하지 않는 것보다는 낫다. 개발자가 자신의 코드에 신뢰를 높이고 우발적인 복잡성을 줄이며, 믿을 만한 문서를 제공하는 모든 일은 좋다. 다만, 단위 테스트를 프로덕션 코드를 작성하기 전에 작성하면, 임의의 복잡성의 발생을 예방하도록 강제하는 기능을 제공한다. 테스트 주도 개발은 다음 두 가지 실용적인 규칙을 방호책으로 제공해 더 간단한 설계를 할 수 있다. 1. 실패하는 테스트를 고치기 위해서만 프로덕션 코드를 작성하라. 2. 테스트가 그린일 때만 열성적으로 리팩터링하라. 우리가 작성하는 모든 코드를 자동으로 그리고 필연적으로 동작하는 가장 간단한 코드가 되도록 테스트 주도 개발이 보장하는가? 아니다. 그렇지 않다. 그렇게 할 수 있는 어떤 사례, 규칙, 책, 선언서는 없다. 단순성이 달성되고 유지되도록 이런 사례에 숨을 불어넣는 사람에게 달려 있다. 이 책은 테스트 주도 개발이 세 가지 다른 프로그래밍 언어에서 어떻게 작동하는지 설명하고 지도한다. 테스트 주도 개발을 꾸준히 연습하는 습관과 자신감을 심어주는 것이 목적이다. 야심에 찬 목적일 순 있지만 달성하기 힘들진 않기를 소망한다.

가나다별 가 l 나 l 다 l 라 l 마 l 바 l 사 l 아 l 자 l 차 l 카 l 타 l 파 l 하 l 기타
국내문학상수상자
국내어린이문학상수상자
해외문학상수상자
해외어린이문학상수상자

(주)알라딘커뮤니케이션

대표이사 최우경 고객정보보호 책임자 최우경 사업자등록 201-81-23094 통신판매업신고 2003-서울중구-01520 이메일 privacy@aladin.co.kr 호스팅 제공자 알라딘커뮤니케이션 (본사) 서울시 중구 서소문로 89-31
ⓒ Aladin Communication. All Rights Reserved.

고객센터 1544-2514 (발신자 부담)

서울시 마포구 백범로 71 숨도빌딩 7층 Fax 02-6926-2600
1:1 문의 FAQ
중고매장 위치, 영업시간 안내