리팩터링

명사 : 소프트웨어 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부구조의 변경동사 : 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러 가지 리팩터링 기법을 적용 해서 소프트웨어를 재구성한다.코드정리와 리팩터링은 다르다. 리팩터링 도중 코드가

함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확이 알 수 있도록 엄청나게 신경 써서 이름을 지어야 한다.마땅한 이름이 떠오르지 않는다면 설계에 더 근본적인 문제가 숨어 있을 가능성이 높다.똑같은 코드 구조가 여러

04 테스트 구축하기 리팩터링을 재대로 하려면 불가피하게 저지르는 실수를 잡아주는 견고한 테스트 스위트가 뒷받침돼야 한다. 자가 테스트 코드의 가치 모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자. 테스트 코드 자체뿐 아니라 테스트를 자주 수행하는

강의 등록 함수오늘 공부한 함수 추출하기를 적용 해보려 한다.한눈에 봤을때 흐름이 명확해 보이지 않는다.이유는 길어진 함수 길이와 for문 때문인 것 같다.먼저 for문을 추출할 함수를 생성한다. 강의 리스트를 돌면서 강의 이름을 확인하는 작업이므로 validation

코드 조각을 찾아 무슨일을 하는지 파악한다음, 독립된 함수로 추출하고 목적에 맞는 이름을 붙인다.'목적과 구현을 분리'하는 방식이 가장 합리적인 기준으로 보인다.코드를 보고 무슨 일을 하는지 파악하는 데 한참이 걸린다면 그 부분을 함수로 추출한뒤 '무슨 일'에 걸맞는

7. 변수 이름 바꾸기 함수 호출 한 번으로 끝나지 않고 값이 영속되는 필드라면 이름에 더 신경 써야 한다. > ### 절차 폭넓게 쓰이는 변수라면 변수 캡슐화하기를 고려한다. 이름을 바꿀 변수를 참조하는 곳을 모두 찾아서, 하나씩 변경한다. 테스트한다. 8. 매개

모듈을 분리하는 가장 중요한 기준은 아마도 시스템에서 각 모듈이 자신을 제외한 다른 모든 부분에 드러내지 않아야 할 비밀을 얼마나 잘 숨기느냐에 있을 것이다. 클래스는 내부 정보뿐 아니라 클래스 사이의 연결 관계를 숨기는 데도 유용하다. 1. 레코드 캡슐화 하기 단순

클래스는 반드시 명확하게 추상화하고 소수의 주어진 역할만 처리해야 한다.메서드와 데이터가 너무 많은 클래스는 이해하기가 쉽지 않으니 잘 살펴보고 적절히 분리하는 것이 좋다.일부 데이터와 메서드를 따로 묶을 수 있다면 어서 분리하라는 신호다.클래스의 역할을 분리할 방법을

함수 옮기기 좋은 소프트웨어 설계의 핵심은 모듈화가 얼마나 잘 되어 있느냐를 뜻하는 모듈성이다. 모듈성이란 프로그램의 어딘가를 수정하려 할 때 해당 기능과 깊이 관련된 작은 일부만 이해해도 가능하게 해주는 능력이다. 모듈성을 높이려면 서로 연관된 요소들을 함께 묶고,

하나의 값이 여러 목적으로 사용된다면 혼란과 버그를 낳는다.역할 하나당 변수 하나다. 여러 용도로 쓰인 변수는 코드를 읽는 이에게 커다란 혼란을 주기 때문이다.변수를 선언한 곳과 값을 처음 대입하는 곳에서 변수 이름을 바꾼다.가능하면 이때 불변으로 선언한다.이 변수에

조건문 분해하기 복잡한 조건부 로직은 프로그램을 복잡하게 만드는 가장 흔한 원흉에 속한다. 긴 함수는 그 자체로 읽기가 어렵지만, 조건문은 그 어려움을 한층 가중시킨다. 거대한 코드 블록이 주어지면 코드를 부위벼롤 분해한 다음 해체된 코드 덩어리들을 각 덩어리의 의도를

좋은 API는 데이터를 갱신하는 함수와 그저 조회만 하는 함수를 명확히 구분한다.우리는 외부에서 관찰할 수 있는 겉보기 부수효과가 전혀 없이 값을 반환해주는 함수를 추구해야 한다.겉보기 부수효과가 있는 함수와 없는 함수는 명확히 구분하는 것이 좋다.값을 반환하면서 부수

메서드 올리기 중복된 두 메서드가 당장은 문제없이 동작할지라도 미래에는 벌레가 꼬이는 음식물 쓰레기로 전락할 수 있다. 무언가 중복되었다는 것은 한쪽의 변경이 다른 쪽에는 반영되지 않을 수 있다는 위험을 항상 수반한다. 메서드 올리기를 적용하기에 가장 이상하고 복잡한