리팩터링

클래스로 묶으면 함수들이 공유하는 공통 환경을 더 명확하게 표현할 수 있고, 각 함수에 전달되는 인수를 줄여서 객체 안에서의 함수 호출을 간결하게 만들 수 있습니다. 그리고 이런 객체를 시스템의 다른 부분에 전달하기 위한 참조를 제공할 수 있습니다. 클라이언트가 객체의 핵심 데이터를 변경할 수 있고, 파생 객체들을 일관되게 관리할 수도 있습니다. (1) 함수들이 공유하는 공통 데이터 레코드를 캡슐화: 공통 데이터가 레코드 구조로 묶여 있지 않다면 '매개변수 객체 만들기'로 데이터를 하나로 묶는 레코드를 만들기 (2) 공통 레코드를 사용하는 함수 각각을 새 클래스로 옮기기: 공통 레코드의 멤버는 함수 호출문의 인수 목록에서 제거 (3) 데이터를 조작하는 로직들을 '함수로 추출'해서 새 클래스로 옮기기 아래..

매개변수 객체 만들기 데이터 항목 여러개를 함수로 넘겨주게 되면, 데이터 구조를 묶어서 보내주면 좋습니다. 데이터 뭉치를 데이터 구조로 묶으면 데이터 사이의 관계가 명확해짐 함수는 데이터 구조를 받음으로써 매개변수 수가 줄어듦 같은 데이터 구조를 사용하는 모든 함수가 원소를 참조할 때 같은 이름을 사용하기 때문에 일관성을 높여줌 (1) 적당한 데이터 구조가 없으면 새로 만들기 (2) 테스트 (3) 함수 선언 바꾸기로 데이터 구조를 매개변수로 추가 (4) 테스트 (5) 함수 호출시 새로운 데이터 구조 인스턴스를 넘겨주도록 수정하고, 수정할 때마다 테스트 (6) 기존 매개변수를 사용하던 코드를 새 데이터 구조의 원소를 사용하도록 변경 (7) 기존 매개변수를 제거하고 테스트 아래는 온도측정값(reading) ..

변수 캡슐화하기 데이터는 참조하는 모든 부분을 한 번에 바꿔야 코드가 제대로 동작하는 까닭에 함수보다 까다롭습니다. 유효범위가 넓어질수록 다루기 어려워집니다. 전역 데이터가 골칫거리인 이유. 그래서 접근 범위가 넓은 데이터를 옮길 때는 먼저 그 데이터로의 접근을 독점하는 식의 '캡슐화'하는 것이 좋을 때가 많습니다. 캡슐화를 하면 데이터를 변경하고 사용하는 코드를 감시할 수 있는 확실한 통로가 되어주기 때문에 데이터 변경 전 검증이나, 변경 후 추가로직을 쉽게 끼워 넣을 수 있습니다. (Swift에서는 프로퍼티들에 willSet, didSet을 제공하기 때문에 통로를 이유로 캡슐화를 하지는 않습니다) '불변 데이터'는 가변 데이터보다 캡슐화할 이유가 적습니다. 데이터가 변경될 일이 없어서 갱신 전 검증 ..

함수 선언 바꾸기 함수의 이름이 좋으면 함수의 구현 코드를 볼 필요도 없이 호출문만 보고도 무슨일을 하는지 파악이 가능합니다. 💡 좋은 이름을 떠올리는 효과적인 방법은 '주석으로 함수의 목적을 설명해보기'. 주석이 멋진 이름으로 바뀌어 되돌아 올 때가 있음. 매개변수도 마찬가지. 함수를 사용하는 문맥을 설정하는 것. 함수 선언 바꾸기를 할 때는 변경사항을 보고 함수 선언과 호출문들을 단번에 고칠 수 있을지 가늠해보고 가능해 보이면 간단한 절차로 수행할 수 있습니다. [간단한 절차] (1) 매개변수를 제거하려거든 먼저 함수 본문에서 제거 대상 매개변수를 대상 매개변수를 참조하는 곳은 없는지 확인 (2) 메서드 선언을 원하는 형태로 변경 (3) 기존 메서드 선언을 참조하는 부분을 모두 찾아서 바뀐 형태로 수..

변수 추출하기 Extract Variable 표현식이 복잡하여 이해하기 어려울 땐, 지역 변수로 표현식을 쪼개어 관리하기 쉽게 만들수 있습니다. 추가한 변수는 디버거에 breakpoint를 지정하거나, 상태를 출력하거나, 상태를 임의로 변경할 수 있어 디버깅에도 많은 도움이 됩니다. (1) 추출하려는 표현식에 부작용은 없는지 확인 (2) 상수를 하나 선언하고 이름을 붙일 표현식의 복제본을 대입 (3) 원본 표현식을 만든 변수로 교체 (4) 테스트 (5) 표현식을 여러 곳에서 사용한다면 각각을 새로 만든 변수로 교체. 하나 교체할 때마다 테스트. 아래에 딱 봐도 복잡한 주석이 꼭 필요해보이는 계산식의 예시가 있습니다. func price(order: Order) -> Double { // 가격(price)..

함수 추출하기 Extract Function 코드 조각을 찾아 무슨 일을 하는지 파악한 다음, 독립된 함수로 추출하고 목적에 맞는 이름을 붙이는 작업입니다. '목적과 구현을 분리'하는 방식이 가장 합리적인 기준. 코드를 보고 무슨 일을 하는지 파악하는 데 한참이 걸린다면 그 부분을 함수로 추출한 뒤 '무슨 일'에 걸 맞는 이름을 짓습니다. (1) 함수를 새로 만들고, 목적을 잘 드러내는 이름을 붙임('어떻게'가 아닌 '무엇을' 하는지가 드러나야 함): 대상 코드가 함수 호출문 하나처럼 간단하더라도 함수로 뽑아서 목적이 더 잘 드러나는 이름을 붙일수 있다면 추출할 것(이런 이름이 떠오르지 않는다면 추출하면 안 된다는 신호) (2) 추출한 코드를 원본 함수에서 복사하여 새 함수에 붙여넣음 (3) 추출한 코드..

테스트 코드는 리팩터링이 아니더라도 새 함수, 새 기능을 만들 때 생각하지 못했던 버그를 검출할 수도 있고, 코드가 테스트 가능하게 만들기 위해서 좀 더 나은 코드로 리팩터링 할 수도 있음. → 좋은 테스트를 구축하는 일은 개발효율을 높여줌. 모든 테스트를 완전히 자동화하고 결과까지 스스로 검사하도록 만들어야 함. → 요즘 툴들은 자동으로 테스트를 진행해 줌. 우리가 예상하는 값을 코드로 명시해 두면 알아서 검사해 주고 문제가 있을 땐 문제를 찾아줌. 컴파일할 때마다 테스트도 함께 하면서 생산성이 급상승. 디버깅 시간이 크게 줄어듦. 테스트를 자주 수행하는 습관도 버그를 찾는 강력한 도구가 됨. → 새로운 코드를 작성할 때, 코드 리뷰를 진행할 때에도 테스트코드를 함께 작성하도록 권장해야 함. 테스트 코..

코드에서 나쁜 냄새가 나면 리팩터링할 시간. 당신은 당신이 뭘 모르는지 모른다. → 어떤 코드가 나쁜 코드인지 모르면, 어떻게 개선해야 하는지도 모름. → 리팩터링이 필요한 코드들의 일정한 패턴(악취!)이 있어서 이를 알아야 함. 1. 기이한 이름 Mysterious Name 코드는 단순하고 명료하게 작성해야 함. 코드를 명료하게 표현하는데 가장 중요한 요소 중 하나는 '이름'. 마땅한 이름이 떠오르지 않는다면 설계에 근본적인 문제가 숨어 있을 가능성이 높음. 각각의 이름이 정확히 무얼하는지 이해하기 어렵거나, 구현사항이 이름과 맞지 않은 경우 코드 이해력, 가독성이 떨어짐. → 함수, 모듈, 변수, 클래스 명은 그 이름만 봐도 각각 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 ..

리팩터링은? 코드를 깨끗이 만드는 작업. → 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법 → 함수, 모듈, 소프트웨어 전체적인 설계가 대상 💡목표: 복잡성 감소 → 모든 개발자들이 쉽게 이해할 수 있도록 함 가독성 향상 → 나를 포함한 개발자들이 쉽게 코드를 이해하고 유지보수를 잘 할 수 있음 유지보수성을 개선 → 버그가 생겼을 때 쉽게 다른 사람의 코드를 개선시킬 수 있음 확장성을 높임 → 새 기능을 추가할 때 짧은 시간안에 기능을 추가 가능해짐 ⇒ 더 단순하고, 깔끔하고 표현력이 뛰어난 코드, 내부 아키텍처/객체 모델을 만듬 ⚠️ 금지: 기능 변경/추가 버그 수정 성능 개선 (라이브러리, 디펜던시)버전 업데이트 리팩터링이 필요한 이유 개발 ..