끄적끄적

Self Encapsulate Fieldfield에 직접 접근하고 있는데 Field에 대한 결합이 이상해지면,그 Field에 대한 get/set 메소드를 만들고 항상 이 메소드를 사용하여 Field에 접근하라direct variable access vs indirect variable access변수가 정의된 클래스 안에서는 직접 접근해도 된다 vs 클래스 안에서도 get/set으로 접근해야 한다 Replace Data Value with Object추가적인 데이터나 동작을 필요로 하는 데이터 아이템이 있을 때는데이터 아이템을 객체로 바꾸어라.동기간단한 데이터 아이템인 줄 알았는데 특별한 동작이 여럿 필요한 경우 데이터 값을 객체로 바꿔야 함절차데이터 값에 대한 클래스를 만든다. 소스 클래스의 값과 같은..

책임을 어디에 둘 것인가 Move FieldMove MethodExtract ClassInline Class Move Method(v)메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드를 만들어라. 그리고 이 전 메소드는 간단한 위임으로 바꾸거나 완전히 제거하라.동기자신이 속해 있는 클래스보다 다른 클래스를 더 많이 참조하는 메소드가 있는지 확인절차소스 클래스에 정의된 소스 메소드에 의해 사용되는 모든 부분을 조사어떤 부분이 지금 옮기려는 메소드에서만 사용된다면, 그 부분 또한 같이 옮기는 것이 낫다.소스 클래스의 서브클래스나 슈퍼클래스에서 옮기려고 하는 메소드에 대한 다른 선언이 있는지 확인타겟 ..

리팩토링의 많은 부분을 차지 Extract Method(v)그룹으로 함께 묶을 수 있는 코드 조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다.동기지나치게 긴 메소드주석이 필요한 코드( 목적을 이해하기 위한 )장점 ( 짧고 이해하기 쉬운 이름으로 메소드를 만들었을 때 )재사용 확률 높아짐메소드를 볼 때 주석을 읽는 것 같은 느낌이 들도록 할 수 있음오버라이드 하기 쉬움절차메소드를 새로 만듦의도를 잘 나타내도록 이름을 정함 ( 어떻게 하는지가 아닌 무엇을 하는지를 나타내도록 )뽑아내고자 하는 부분이 아주 간단한 경우에는 새로운 메소드의 이름이 그 코드의 의도를 더 잘 나타낼 수 있을 때만 뽑아낸다. )뽑아내고자 하는 부분의 코드를 복사하여 새 메소드로 옮김원래 메소..

테스트 만들기 모든 테스트를 완전히 자동화하고, 테스트가 자신의 결과를 스스로 확인하게 하라.테스트의 결과 또한 컴퓨터가 확인하도록 테스트 코드를 작성하라.TS_ASSERT_EQUALS( result, expected_result ) 언제 테스트 코드를 작성해야 하는가?프로그래밍 시작 전구현보다는 인터페이스에 집중할 수 있게 된다.코딩을 완료할 명확한 지점( 테스트를 통과하는 지점) 을 갖게 되는 것을 의미함 테스트를 자주 실행 시켜라. 컴파일 할 때마다 테스트를 하고, 적어도 하루에 한번 모든 테스트를 실행시켜라. 리팩토링을 할 때는 작업하고 있는 코드만 몇 가지 테스트를 실행시켜야 한다. 단위 테스트 ( Unit test ) vs 기능 테스트 ( functional test )단위 테스트프로그래머에게..

중복된 코드한 클래스의 서로 다른 두 메소드 안에 같은 코드가 있는 경우Extract Method동일한 수퍼클래스를 갖는 두 서브클래스에서 같은 코드가 있는 경우Extract Method 후 Pull Up Method비슷하지만 같지는 않다면비슷한 부분 Extract Method 후 Form Template Method 사용 가능한지 확인같은 작업을 하지만 다른 알고리즘을 사용한다면두 알고리즘 중 더 명확한 것 선택해서 Substitute Algorithm 사용서로 관계 없는 두 클래스에서 중복된 코드가 있는 경우Extract Class 사용한 다음 양쪽에서 이 새로운 클래스를 사용 긴 메소드어떤 것에 대해 주석을 달아야 할 필요를 느낄 때마다 대신 메소드를 작성하라단지 한 줄의 코드라 할지라도 그것이 설..

리팩토링(Refactoring)소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것 리팩토링 하다(Refactor)일련의 리팩토링을 적용하여 겉으로 보이는 동작의 변화 없이 소프트웨어의 구조를 바꾸다. 언제 리팩토링을 해야 하는 가?별도의 시간을 내서 하지말고 틈틈이 계속리팩토링 자체를 목적으로 하는 것이 아니라 다른 어떤 것을 하기 위해 리팩토링을 해야 한다삼진 규칙처음 할 때는 그냥 한다.두 번째로 비슷한 것을 하게 되면 중복되게 한다.세 번째로 비슷한 것을 하게 되면, 그 때 리팩토링 한다.기능 추가 할 때수정해야 할 코드에 대한 이해를 돕기 위해기능 추가가 쉽지 않은 디자인인 경우버그를 수정해야 할 때버그 리포트를 받았으..

리팩토링을 해야 할 순간"고장 나지 않았으면 고치지 말라"하지만 골치 아프게 하고 변경사항을 반영하기 어려울 때 리팩토링새로운 기능을 추가 할 때 새로운 기능 추가하기 쉽도록 구조화되어 있지 않은 경우 리팩토링 후 기능 추가 리팩토링의 첫번째 단계 - 테스트 세트 만들기 메소드의 분해 및 재분배논리적으로 연관이 있는 코드 덩어리 찾아서 Extract Method 적용switch문 변수 이름 바꾸기컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다.좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. Replace Temp with Query(임시변수는 가능하면 제거하는 것이 좋다.) Replace Conditional with Polymorphism(조건문을 다형성으로 바꾸기)