리팩터링 카탈로그

코드 조각을 찾아 무슨 일을 하는지 파악한 다음, 독립된 함수로 추출하고 목적에 맞는 이름을 붙인다.코드를 언제 독립된 함수로 묶어야 할지에 관한 의견은 수없이 많다. 먼저, 길이를 기준으로 삼을 수 있다. 가령 함수 하나가 한 화면을 넘어가면 안 된다는 규칙을 떠올릴

이 책은 목적이 분명히 드러나는 이름의 짤막한 함수를 이용하기를 권한다. 그래야 코드가 명료해지고 이해하기 쉬워지기 때문이다. 하지만 때로는 함수 본문이 이름만큼 명확한 경우도 잇다. 또는 함수 본문 코드를 이름만큼 깔끔하게 리펙터링 할 때도 있다. 이럴 때는 그 함

표현식이 너무 복잡해서 이해하기 어려울 때가 있다. 이럴 때 지역 변수를 활용하면 표현식을 쪼개 관리하기 더 쉽게 만들 수 있다. 그러면 복잡한 로직을 구성하는 단계마다 이름을 붙일 수 있어서코드의 목적을 훨씬 명확하게 드러낼 수 있다.이 과정에서 추가한 변수는 디버깅

변수는 함수 안에서 표현식을 가리키는 이름으로 쓰이며, 대체로 긍정적인 효과를 준다. 하지만, 그 이름이 원래 표현식과 다를 바 없을 때도 있다. 또 변수가 주변 코드를 리펙터링 하는 데 방해가 되기도 한다. 이럴 때는 그 변수를 인라인 하는 것이 좋다.대입문의 우변(

함수는 프로그램을 작은 부분으로 나누는 주된 수단이다. 함수 선언은 각 부분이 서로 맞물리는 방식을 표현하며, 실질적으로 소프트웨어 시스템의 구성 요소를 조립하는 연결부 역할을 한다. 건축과 마찬가지로 소프트웨어도 이러한 연결부에 상당히 의존한다. 연결부를 잘 정의하면

배경 리펙토링은 결국 프로그램의 요소를 조작한느 일이다. 함수는 데이터보다 다루기가 수월하다. 함수를 사용한다는 건 대체로 호출한다는 뜻아고, 함수의 이름을 바꾸거나 다른 모듈로 옮기기는 어렵지 않다. 여차하면 기존 함수를 그대로 둔 채 전달 함수로 활용할 수도 있

명확한 프로그래밍의 핵심은 이름짓기다. 변수는 프로그래머가 하려는 일에 관해 많은 것을 설명해준다. 단, 이름을 잘 지었을 때만 그렇다. 이름의 명확성은 프로그램의 이해도와 사용자의 요구, 프로그램의 목적에 따라 언제든 변할 수 있다.특히 이름의 중요성은 그 사용 범위

데이터 항목 여러 개가 이 함수에서 저 함수로 함꼐 몰려다니는 경우를 자주 본다. 나는 이런 데이터 무리를 발견하면 데이터 구조 하나로 모아주곤 한다.데이터 뭉치를 데이터 구조로 묶으면 데이터 사이의 관계가 명확해진다는 이점을 얻느낟. 게다가 함수가 이 데이터 구조를

클래스는 대다수의 최신 프로그래밍 언어가 제공하는 기본적인 빌딩 블로깅다. 클래스는 데이터와 함수를 하나의 공유 환경으로 묶은 후, 다른 프로그램 요소와 어우러질 수 있도록 그중 일부를 외부에 제공한다. 클래스는 객체 지향 언어의 기본인 동시에 다른 패러다임 언어에도

소프트웨어는 데이터를 입력받아서 여러 가지 정보를 도출하곤 한다. 이렇게 도출된 정보는 여러 곳에서 사용될 수 있는데, 그러다 보면 이 정보가 사용되는 곳마다 같은 도출 로직이 반복되기도 한다. 이런 도출 작업들을 한데로 모으는게 좋다. 모아두면 검색과 갱신을 일관된