본문 바로가기

전체 글

 (214)
회귀 방지와 리팩터링 내성의 관계 둘 다 정반대의 관점에서 테스트 스위트의 정확도에 기여한다. 두 가지 특성은 시간이 흐르면서 프로젝트에 영향을 다르게 미치는 경향이 있다. 테스트 정확도 극대화 테스트가 버그 있음을 얼마나 잘 나타내는가 = 거짓 음성이 잘 제외되는가 = 회귀 방지가 잘 되는가 테스트가 버그 없음을 얼마나 잘 나타내는가 = 거짓 양성이 잘 제외되는가 = 리팩터링 내성이 잘 지켜지는가 테스트 정확도 = 발견된 버그 수 / 허위 경보 발생 수 버그 못 찾음 & 허위 경보 안 울림 → 정확도 0에 수렴 (거짓 음성은 프로젝트 초반에 위험) 버그 다 찾음 & 허위 경보 다 울림 → 정확도 0에 수렴 (거짓 양성은 프로젝트 시간이 흐를수록 위험) 개발자 대부분은 회귀 방지에만 신경을 쓰는데, 프로젝트가 크고 오래 걸릴수록 리팩터링..
좋은 단위 테스트의 4대 요소 회귀 방지 리팩터링 내성 빠른 피드백 유지 보수성 1. 회귀 방지 회귀 = 소프트웨어 버그 : 코드를 수정한 후 기능이 의도한 대로 작동하지 않는 것 코드베이스가 커질수록 잠재적인 버그에 더 많이 노출되기 때문에 회귀에 대해 효과적인 보호를 개발하는 것이 중요하다. 회귀 방지를 위한 고려사항 테스트 중에 실행되는 코드의 양 코드 복잡도 코드의 도메인 유사성 실행되는 코드가 적을수록 회귀가 나타날 가능성이 낮다. 복잡한 비즈니스 로직을 나타내는 코드가 boilerplate code보다 훨씬 더 중요하다. 비즈니스에서 중요한 기능에서 발생한 버그가 가장 큰 피해를 입히기 때문이다. 우리가 작성하지 않은 코드(라이브러리, 프레임워크, 외부 시스템 등등)도 중요하다. 2. 리팩터링 내성 거짓 양성(false p..
공동소유 (Collective Code Ownership) http://www.extremeprogramming.org/map/code.html XP flow chart Copyright 1999 Don Wells all rights reserved www.extremeprogramming.org 페어 프로그래밍 (Pair Programming) 운영에 내보낼 모든 코드를 컴퓨터 한 대에서 두 명이 함께 작업한다. 페어 프로그래밍은 개발 시간에 영향을 주지 않으면서 소프트웨어의 품질을 향상시킨다. 직관에 반하는 것 같지만, 두 명이 함께 작업하는 것은 각자 작업하는 것만큼 많은 기능을 추가시킬 수 있으면서 품질도 훨씬 좋다. 품질이 향상되면 프로젝트 후반부에 비용이 크게 절감된다. 페어 프로그래밍을 하는 가장 좋은 방법은 모니터 앞에 나란히 앉는 것이다. 두 프..
완벽에 대한 반론(The Case against PERFECTION) - 마이클 샌델 1. 강화의 윤리학 (case 1) 둘 다 청각장애인인 레즈비언 커플. 청각장애를 하나의 문화적 정체성으로 생각했으며, 오히려 자랑스럽게 여겨 자신들의 아이도 청각장애를 가졌으면 좋겠다고 생각함. 5대째 청각장애를 갖고 있는 사람의 정자를 구해 청각장애를 가진 아이를 낳음. → 계획적으로 자녀를 청각장애로 만드는 것은 잘못된 일인가? (case 2) 하버드 대학을 포함한 아이비리그 대학들의 교내신문에 난자 제공자를 구하는 광고를 실은 불임 부부. 제공 여성은 키가 175cm에 탄탄한 몸매여야 하고 가족 병력이 없어야 하며 SAT 점수가 1400점 이상이어야 했음. 난자 제공자에게는 5만 달러 제공. → case1과는 달리 비난이 쏟아지지 않음. → 특정한 유전적 특성을 가진 아이를 '주문'하려는 부모의 ..
서문 주택담보대출 집을 사는 사람 - 30년 동안 매달 돈을 내겠다는 약속으로 집을 받음 집을 파는 사람 - 돈을 미래 시점들로 옮겨놓는 대가로 집을 넘겨줌 즉, 미래와 현재의 돈을 거래한 것 집을 사는 사람은 어떻게 자기 것도 아닌 거액의 집을 단숨에 얻어낼 수 있는걸까? 이 엄청난 힘은 어디서 왔으며, 대체 어떻게 작동하는 것일까? 주택담보대출이 잘못되면 무슨 일이 일어날까? 금융기술은 타임머신 사람이 아니라 사람의 돈이 타는 타임머신이다. 이 타임머신을 이용해 현재의 경제 상황과 미래의 경제 상황을 바꿀 수 있다. 이 타임머신은 생각하는 방식에도 영향을 미쳤다. 인간은 미래를 상상하고 계산하는 능력을 키웠으며, 과거를 깊이 이해하고 계량하는 능력도 키웠다. 문명 발달의 필요조건인 금융기술 문명이 발달하려..
[아이템 84] 프로그램의 동작을 스레드 스케줄러에 기대지 말라 [Why] 구체적인 스케줄링 정책은 운영체제마다 다를 수 있다. 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다. [How] 견고하고 빠릿하고 이식성 좋은 프로그램을 작성하는 가장 좋은 방법은 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것이다. 실행 준비가 된 스레드들은 맡은 작업을 완료할 때까지 계속 실행되도록 만들자. 이런 프로그램이라면 스레드 스케줄링 정책이 아주 상이한 시스템에서도 동작이 크게 달라지지 않는다. 여기서 실행 가능한 스레드의 수와 전체 스레드 수는 구분해야 한다. 전체 스레드 수는 훨씬 많을 수 있고, 대기 중인 스레드는 실행 가능하지 않다. 실행 가능한 스레드 수를 적게 유지하는 주요 기법은 각 ..
[아이템 83] 지연 초기화는 신중히 사용하라 [배경] 지연 초기화(lazy initialization): 필드의 초기화 시점을 그 값이 처음 필요할 때까지 늦추는 기법 주로 최적화 용도로 쓰이지만, 클래스와 인스턴스 초기화 때 발생하는 위험한 순환 문제를 해결하는 효과도 있다. [Why] 지연 초기화는 양날의 검이다. 클래스 혹은 인스턴스 생성 시의 초기화 비용은 줄지만 그 대신 지연 초기화하는 필드에 접근하는 비용은 커진다. 지연 초기화하려는 필드들 중 결국 초기화가 이뤄지는 비율에 따라, 실제 초기화에 드는 비용에 따라, 초기화된 각 필드를 얼마나 빈번히 호출하느냐에 따라 지연 초기화가 실제로는 성능을 느려지게 할 수도 있다. 지연 초기화가 필요할 때가 있다. 해당 클래스의 인스턴스 중 그 필드를 사용하는 인스턴스의 비율이 낮은 반면, 그 필드..
[아이템 82] 스레드 안전성 수준을 문서화하라 [Why] API 문서에서 동시성에 대한 언급이 없으면 그 클래스 사용자는 나름의 가정을 해야만 한다. 그 가정이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나(아이템78) 지나치게 한(아이템79) 상태일 것이며, 두 경우 모두 심각한 오류로 이어질 수 있다. 자바독이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자가 포함되지 않는다. (구현 이슈일 뿐이기 때문) 스레드 안전성에도 수준이 나뉜다. 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다. [How] 다음 목록은 스레드 안전성이 높은 순으로 나열한 것이다. 불변(immutable): 이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화도 필요 없다..

티스토리툴바