개발 이야기 안하는 개발자

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

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

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

오케이 오늘도 가보자 리팩터링 소프트웨어의 겉보기 동작은 그대로! 하지만 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법. 리팩터링 하기 전과 후는 성능이 변할 수 있지만, 사용자 관점에서는 달라지는 점이 없어야 한다. 즉, 리팩터링하는 과정에서 발견된 버그는 리팩터링 후에도 버그가 그대로 있어야 한다. 습관처럼하는 리팩터링은 프로그래밍 속도를 높인다. 리팩터링을 함으로써(코드를 이해하기 쉽게 바꿈으로써) 새로운 기능을 추가할 때 마다 쉽게 활용할 수 있기 때문이다. 리팩터링을 해야 할 때 리팩터링은 시간을 잡고 한다기 보다는 보고 바로바로 보기싫은 코드를 바로 리팩터링 해야 한다. 리팩터링을 계획적으로 하는것도 상관없다. 리팩터링 관점에서 브랜치같은 경우는 하루에 한번씩 마스터와 합쳐서 작업..

리팩터링 책 독후감 http://www.yes24.com/Product/Goods/89649360 리팩토링 들어가 보자 리팩터링 다른 사람이 읽고 이해해야 할 일이 생겼는데 읽고 파악하기 어렵다면 시간이 오래걸리고 문제가 생길 수 있기 때문에 이를 방지하고자 읽기 쉽고 파악하기 쉬운 코드로 수정해주는 기법이다. 리팩터링을 하면 코드 줄이 늘어날 수 있다. 하지만 각 기능에 맞는 코드를 모듈화하면서 늘어난 코드는 다른 사람이 보기에 더 빨른 이해를 돕기때문에 코드 자체는 늘어났지만 다른 사람이 사용하기엔 더 빠르게 이해하고 작업을 할 수 있게 돕는다. - 테스트 리팩터링하기 전엔 제대로 된 테스트부터 마련해야 한다. 리팩터링은 코드를 이해하기 쉽게 기존에 있던 코드를 수정하는 내용이다. 즉, 새로운 기능을..