IT LAB

모듈을 분리하는 가장 중요한 기준은 아마도 시스템에서 각 모듈이 자신을 제외한 다른 부분에 드러내지 않아야 할 비밀을 얼마나 잘 숨기느냐에 있을 것이다. 이러한 구조는 캡슐화를 통해 숨길 수 있다. 7.1 레코드 캡술화하기 간단한 레코드 캡슐화하기 변수 캡슐화를 한 후, 데이터 구조를 표현하는 클래스를 정의하고, 이를 반환하는 함수를 새로 만듬 중첩된 레코드 캡슐화하기 변수 캡슐화를 한 후, 데이터 구조를 표현하는 클래스를 정의하고, 이를 반환하는 함수를 새로 만듬 데이터 구조 안으로 들어가는 코드를 세터로 뽑아 작업함. 7.2 컬렉션 캡슐화하기 컬렉션을 소유한 클래스를 통해서만 원소를 변경하도록 캡슐화하기 => 컬렉션 변경자 메서드를 통해 원소를 변경하도록 하여 원본 모듈 밖에서 컬렉션을 수정하지 않도..

6.1 함수 추출하기 코드 조각을 찾아 무슨 일을 하는지 파악한 다음, 독립된 함수로 추출하고 목적에 맞는 이름을 붙인다 독립된 함수로 묶을때, 길이나 재사용성 또는 한 화면을 넘어갈 때 등등 많은 기준들이 있다. 하지만 핵심은 ‘목적과 구현을 분리’하는 방식이다. 즉, 무슨일을 하는지 함수의 이름을 통해 파악하도록 하는 것이다. (단, 함수의 이름이 잘 떠오르지 않으면 함수로 추출하면 안됨. 하지만 추출하는 과정에서 이름이 떠오를 수 있으니 일단 추출해 사용해보고 효과가 크지 않으면 인라인해서 써도 됨) 함수를 추출할 때, 원본 함수의 지역 변수를 참조하거나 추출한 함수의 유효범위를 벗어나는 변수는 없는지 검사하고, 있다면 매개변수로 전달한다. 또한 지역변수가 너무 많을 경우 변수 쪼개기나 임시 변수를..

리팩토링을 제대로 하려면 실수를 잡아주는 견고한 테스트 스위트가 뒷받침돼야 함. 테스트 작성에 시간이 걸리지만 결국 좋은 테스트를 작성하면 개발 효율을 높여준다. 4.1 자가 테스트 코드의 가치 테스트 케이스 작성을 통해 버그를 찾아낼 수 있음. 버그는 고치는 것보다 찾아내는 것이 어려움. “테스트 스위츠는 강력한 버그 검출 도구로, 버그를 찾는 데 걸리는 시간을 대폭 줄여준다” 저자는 반복적 개발 방법론을 경험할 당시 테스트를 반복 주기마다 포함시켜 작업했다고 한다. 이때 경험하고 누렸던 것중 버그 검출의 효과를 보았고 버그에 대해서는 테스트 코드로 신경을 덜 쓸수 있다고 자신의 경험을 소개하였다. 또한 저자는 개발하기 전에 테스트 케이스부터 작성한다고 한다. 얼핏 순서가 뒤바뀐듯 들리지만 테스트를 작..

저자는 리팩토링을 하는 시점을 코드에서 '악취'가 날 때라 말한다. '악취'가 나는 코드를 어떤 정확한 기준에 부합한다 라고 보기는 어렵다. 하지만 그동안의 경험을 토대로 하여 가지게 된 직관을 정리하여 제시한 악취들을 공부한 후 리팩토링 작업을 하게될 때, 감을 키워나가면서 리팩토링 실력을 쌓아 나가야 효과를 볼 수 있다. 3.1 기이한 이름 코드를 명료하게 표현하는데 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 알 수 있도록 신경써서 이름을 지어야 함. 이름만 잘 지어도 나중에 문맥을 파악하느라 해메는 시간을 크게 절약할 수 있음. 3.2 중복 코드 똑같은 코드 구조가 여러 곳에서 반복된다면 하나로 통합하여 더 나은 프로그램을 만들 수 있다. 코드가 중복되면 서로 차이점이 없는 지 주..

* 마틴 파울러의 "리팩토링" 책을 공부한 후 정리한 포스팅 * 비중이 적은 내용은 생략하였음. 2.1 리팩터링 정의 리팩터링 : 겉보기 동작은 그대로 유지한 채, 여러 가지 리팩토링 기법을 적용해서 소프트웨어를 재구성. + 특정한 방식에 따라 코드를 정리 작은 단계들을 거쳐 코드 수정하여 순차적으로 큰 변화를 만들어냄. ( 겉보기동작 : 코드의 동작은 전과 후가 완전히 같아야 함. 내부 동작은 달라져 성능은 변할 수 있음. ) 성능 최적화와 비슷. 코드의 목적을 이해하고 수정하기 쉽게 만듬. 오로지 성능이 목표가 아니다. 2.2 두 개의 모자 소프트웨어 개발시 ‘기능 추가’ 혹은 ‘리팩터링’ 목표를 구분해 작업함. 2.3 리팩터링하는 이유 설계가 좋아짐 내부 설계가 유지되기 위함. 지속적인 리팩토링이 ..