함수 추출하기(6.1) ↔ 함수 인라인하기(6.2) 변수 추출하기(6.3) ↔ 변수 인라인하기(6.4) 함수 선언 바꾸기(6.5) - 함수 이름 변경 변수 이름 바꾸기(6.7) - 변수 이름 변경 매개변수 객체 만들기(6.8) - 자주 함께 사용되는 인수들 묶기 추출은 결국 이름 짓기이며 함수 구성과 이름 짓기는 가장 기본적인 저수준 리팩터링 여러 함수를 클래스로 묶기(6.9) - 함수를 그룹으로 묶기 여러 함수를 변환 함수로 묶기(6.10) - 읽기 전용 데이터 다루기 단계 쪼개기(6.11) 묶은 모듈들의 작업 처리 과정을 명확한 단계로 구분 짓기 6.1 함수 추출하기 ↔ 함수 인라인하기(6.2) 배경 코드가 무슨 일을 하는지 파악한 다음 독립된 함수로 추출하고 목적에 맞는 이름 붙이기 독립된 함수로 ..
테스트 작성 - 개발 효율을 높여줌 - 리팩터링 시 불가피하게 저지르는 실수를 잡아줌 4.1 자가 테스트 코드의 가치 실제 코드를 작성하고, 버그를 수정하는 것보다 현재 상황 파악, 설계 고민, 버그 찾기 시간을 많이 씀 버그를 해결하는 과정에서 또 다른 버그를 만들기도 하고, 이 버그를 찾느라 시간을 보냄 모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자 테스트를 작성하려면 소프트웨어를 위한 코드 외에 부가적인 코드를 상댱량 작성해야 하기 때문에 이렇게 개발하기 어렵지만, 테스트를 작성하고 자주 실행하면 추가된 코드 양이 많지 않아 버그 발생 지점을 찾기 쉬워져 프로그래밍 속도를 높여줌 테스트를 작성하기 좋은 시점은 프로그래밍을 시작하기 전. 원하는 기능을 위해 무엇이 필요한지 고민하..
언제 리팩터링 할지는 경험을 많이 해보고 개인이 판단해야 함 감을 잡는데 도움이 될만한 리팩터링이 필요한 코드들에서 보이는 일정한 패턴을 아래에 나열 3.1 기이한 이름 함수, 모듈, 변수, 클래스 등의 이름은 무슨 일을 하고, 어떻게 사용하는지 명확히 알 수 있도록(의도, 목적) 지어야 함 마땅한 이름이 떠오르지 않는다면 설계를 다시 살펴보기 이름을 잘 정리하면 코드가 훨씬 간결해질 수 있음 3.2 중복 코드 코드가 중복되면 중복된 코드 사이의 차이점이 무엇인지 살펴봐야 하고, 하나를 수정 시 비슷한 모든 코드를 살펴 수정해주어야 함 3.3 긴 함수 오랜 기간 잘 활용되는 프로그램들은 짧은 함수로 구성되어 있음 함수가 길면 이해하기 어려움. 함수 호출 비용이 거의 없기 때문에 작은 함수로 분리해 줄 것..
2.7 리팩터링과 소프트웨어 개발 프로세스 리팩터링 지속적 통합 자가 테스트 코드 팀으로 개발할 때 다른 사람의 작업을 방해하지 않으면서 언제든지 리팩터링 할 수 있어야 함 지속적 통합을 적용하면 팀원 각자가 수행한 리팩터링 결과를 동료와 빠르게 공유할 수 있음 (리팩터링의 결과가 팀원의 작업에 문제를 일으키면 즉시 알아낼 수 있음) 지속적 배포는 소프트웨어를 언제든 릴리스할 수 있는 상태로 유지해 줌 2.8 리팩터링과 성능 직관적인 설계 vs 성능 소프트웨어를 이해하기 쉽게 만들기 위해 속도가 느려지는 방향으로 수정하는 경우가 많음 그러나 성능을 개선하기 더 쉬워짐 빠른 소프트웨어를 작성하는 방법 세 가지 1. 시간 예산 분배 방식 하드 리얼타임 시스템에서 많이 사용 설계를 여러 컴포넌트로 나눠서 컴포..
Enums: 특정 값들을 모아둔 자료형 숫자형 이넘(Numeric enums) enum Direction { Up = 1, Down, // 2 Left, // 3 Right, // 4 } 초기값부터 +1씩 증가 enum Direction { Up, // 0 Down, // 1 Left, // 2 Right, // 3 } 지정하지 않는 경우 0부터 1씩 증가 - 사용 예시 enum UserResponse { No = 0, Yes = 1, } function respond(recipient: string, message: UserResponse): void { // ... } respond("Princess Caroline", UserResponse.Yes); 문자형 이넘(String enums) enum ..