개발 이야기 안하는 개발자

리팩터링 12번째 장 - 상속 다루기 상속은 굉장히 유용하면서 동시에 오용하기 쉽다 보통 상속을 사용하는 경우는 여러개의 비슷한 기능을 하는 클래스들을 묶는 것에 사용하는데 그렇기 때문에 해당 리팩터링은 하나이상의 클래스들을 정리하는데에 사용된다. 1. 메서드 올리기 왼쪽은 원래 기본 코드 코드를 보면 같은 부모이고 AFunc() 같은 내용의 메소드를 쓰고있다. 이를 오른쪽 처럼 부모에 메서드를 올리면 된다. 1) 똑같은 기능의 메서드인가? -> 실질적 일이 같은데 코드가 다르면 코드가 똑같아질때 까지 리팩터링 해야한다. 2) 참조하는 다른 필드들은 부모클래스로 올릴수 있는지 확인해본다. 3) 메서드이름이 다르면 이름부터 바꾸고 부모클래스로 올린다. 2. 필드 올리기 메서드 올리는 방식과 비슷하다. 1)..

오케이 오늘도 가보자 책에서 계속 말하는 리팩터링은 반드시 테스트가 동반되어야 한다고 이야기 한다. 리팩터링은 코드를 읽기 쉽게 하는 기법으로 코드의 버그를 해결하는 시간이 아니다. 즉, 리팩터링 하기 전에 생겼던 문제들은 리팩터링 하고 난 뒤에도 생겨야 한다. 이번 장에서 말하는 테스트 구축하기는 이런 내용들을 모두 포함해서 리팩터링하고 난 다음에도 같은 테스트 결과가 나오도록 확인해야 한다라는 결론을 포함한다. (어쨌든 코드가 수정된거니까 이걸로 버그가 생길수도?!) 두등탁 책에선 모카라는 프레임워크를 사용했는데 Unity는 그런거 없으니까..? 4장까지 공부하면서 리팩터링에서 가장 중요한 건 함수 추출하기 인것같다. 어쨌든 리팩터링은 잘 알아보기 쉽도록 만드는 과정이고, 가장 쉬운건 기능단위로 쪼개..

리팩터링할 시점은 냄새날때 이다. 냄새란? 그냥 딱 봐도 이게 뭐야...? 하는 그 순간이 바로 냄새인가 보다. 근데 여기서 말하는 냄새라는게 그냥 경험이 좀 필요해 보인다. 쓰일 리팩터링이 필요할 때는 서술하지 않을 예정이고, 냄새가 난다라는 표현도 모호한게 요즘에선 리팩터링이 필요하다라는 생각은 경험이 좀 필요해 보인다. 오케이 들어가보자 1. 기이한 이름 알아보기 어려운 이름? 딱 봤을때 무슨 기능인지 모르겠는 이름? -1. 함수 선언 바꾸기 -2. 변수 이름 바꾸기 -3. 필드 이름 바꾸기 2. 중복 코드 겹치는 코드들은 하나의 함수로 만들어서 여러군대에서 호출하거나 상속받으면 부모에게 줘버리자. -1. 함수 추출하기 -2. 문장 슬라이드하기 -3. 메서드 올리기 3. 긴 함수 함수 자체가 너무 ..