(스터디) 파이브 라인스 오브 코드 리뷰 1-3장

1장 리팩터링, 리팩터링하기

좋은 코드란 (정의)

• 사람이 읽기 쉽고, 유지보수가 용이하며, 의도한 대로 잘 동작하는 코드

 

리팩터링이란

• 기능을 변경하지 않고 코드의 가독성과 유지보수가 쉽도록 코드를 변경하는 것

 

리팩터링 핵심

• 의도를 전달함으로써 가독성 향상
• 불변속성의 범위제한을 통한 유지보수성 향상
• 범위 밖의 코드에 영향을 주지 않고 1항과 2항을 수행

 

요약

• 리팩터링을 수행하려면 리팩터링 대상을 식별하는 스킬과 리팩터링 단계를 명시적으로 가진 문화, 리팩터링을 돕는 도구의 조합이 필요합니다.
• 일반적으로 코드 스멜은 리팩터링 대상을 설명하는 데 사용됩니다. 이것들은 모호해서 주니어 프로그래머가 내면화하기 어렵습니다. 이 책에서는 학습하는 동안 코드 스멜을 대체할 구체적인 규칙을 제공합니다. 규칙에는 세 가지 추상화 수준이 있습니다 매우 구체적인 이름, 예외 형태로 뉘앙스를 더하는 설명, 마지막으로 그것들이 나오게 된 스멜의 의도입니다.
• 자동화된 테스트와 리팩터링을 별도로 학습하면 진입 장벽을 낮출 수 있습니다. 자동화된 테스트 대신 컴파일러, 버전 관리 및 수동 테스트를 사용합니다.
• 리팩터링의 작업 절차는 레드-그린-리팩터 반복에서 테스트 주도 개발로 연결됩니다. 이는 자동화된 테스트에 의존하다는 것을 의미합니다. 그래서 이를 대신해 새로운 코드를 만들 때 사용하는 6단계의 작업 절차(탐색, 명세화, 구현, 테스트, 리팩터링, 전달)를 사용하거나 코드를 변경하기 직전에 리팩터링을 수행하도록 권장합니다.
• 이 책의 1부에서는 비주얼 스튜디오 코드, 타입스크립트, Git을 사용해 2D 퍼즐 게임의 소스코드를 바꿉니다.

 

2장.리팩터링 깊게 들여다보기

이번 장에서 다룰 내용

가독성을 통한 의도 전달

유지보수성 개선을 위한 불변속성(invariant) 지역화

개발 속도 향상을 위한, 추가(addition)을 통해 변경 가능하게 만들기

리팩터링의 일상 업무화

코드 개선:

• 가독성개선
• 유지보수성개선

중요한 포인트

• 코드가 하는 일을 바꾸지 않고 유지보수하기

속도, 유연성 및 안정성 확보 방법

1. 상속보다는 컴포지션 사용 하는 방법
   • 유연성 증가
2. 수정이 아니라 추가로 코드를 변경
   • 프로그래밍 속도에 이득
   • 안정성 이득

기술 부채란

• 프로그래밍에서 "기술부채(technical debt)"는 시스템 또는 소프트웨어 개발에 있어서 단기적으로는 빠르게 문제를 해결하거나 기능을 개발하기 위해 택한 비효율적인 설계나 접근법 때문에, 장기적으로는 추가적인 시간이나 노력을 들여서 수정해야 하는 상황을 의미합니다. 간단한 예를 들면, 빠르게 프로젝트를 완료하기 위해 코드의 재사용성을 고려하지 않고 특정 기능만을 위한 코드를 작성하는 것입니다. 이렇게 되면 나중에 같은 기능이나 비슷한 기능을 추가할 때 많은 시간을 소모하게 될 수 있습니다. 이렇게 기술부채는 실제 부채처럼 초기에는 작은 문제처럼 보일 수 있지만, 시간이 지날수록 그 부채의 "이자"가 커지게 되어 결국 큰 문제로 변하게 됩니다. 이 "이자"는 나중에 코드를 수정하거나 재사용하기 위해 필요한 추가적인 작업을 의미합니다. 기술부채를 관리하지 않으면, 소프트웨어의 유지보수가 어려워지고, 심각한 버그가 발생할 확률이 높아지며, 새로운 기능을 추가하는 데에도 많은 시간이 소요될 수 있습니다. 따라서, 프로젝트를 진행할 때는 단기적인 해결책에만 의존하지 않고, 장기적인 관점에서 코드의 품질과 유지보수성을 고려하는 것이 중요합니다.

2장 요약

• 리팩터링은 기능 변경 없이 코드의 의도를 전달하고 불변속성의 범위를 제한하는 것입니다.
• 상속보다 컴포지션을 사용함으로써, 추가를 통한 변경으로 개발 속도, 유연성, 안정성을 확보합니다.
• 리팩터링을 일상 업무에 포함시켜 기술 부채가 쌓이지 않도록 해야 합니다.
• 리팩터링을 연습하면 코드에 대한 독특한 관점을 얻을 수 있으며, 이로 인해 더 나은 해결책을 찾을 수 있습니다.

 

3장 긴 코드 조각내기

이번 장에서 다룰 내용

• 다섯 줄 제한으로 지나치게 긴 메서드 식별하기
• 세부 사항을 보지 않고 코드 작업하기
• 메서드 추출(EXTRACT METHOD)로 긴 메서드 분해하기
• 호출 또는 전달, 한 가지만 할 것(EITHER CALL OR PASS)으로 추상화 수준 맞추기
• if 문은 함수의 시작에만 배치로 if 문 분리하기

첫 번째 규칙: 왜 다섯 줄인가?

다섯 줄 제한

정의

• 메서드는 {와 }를 제외하고 5줄 이상이 되어서는 안됩니다.

설명

• 특정 수치로 줄 수를 제한하는 것보다 제한이 있다는 것 자체가 중요
• ex)메서드 안에 10줄이라면 메서드 2개로 나눠서 각각 5줄씩으로 라인되도록 코딩(계층적으로 가능)

용어 설명: 코드 스멜

"코드 스멜(code smell)"은 프로그래밍에서 코드에 문제가 있을 가능성을 나타내는 경고 신호나 징후를 의미합니다. 코드 스멜 자체는 버그가 아니지만, 코드의 품질 문제나 잠재적인 오류의 원인이 될 수 있으므로 주의를 기울여야 합니다.

코드 스멜의 예시로는 다음과 같은 것들이 있습니다:

1. 긴 메서드: 한 메서드나 함수가 너무 많은 일을 하거나 너무 길면 이해하기 어렵고 수정하기 힘들 수 있습니다.
2. 중복 코드: 같은 코드가 여러 군데에서 반복되면 유지보수가 어려워집니다. 변경을 할 때마다 모든 중복 코드를 찾아 수정해야 하기 때문입니다.
3. 의미 없는 이름: 변수나 함수의 이름이 그 기능이나 역할을 잘 나타내지 않으면 코드를 읽는 사람이 혼란스러울 수 있습니다.
4. 너무 많은 인자: 함수나 메서드에 너무 많은 인자가 전달되면, 해당 함수나 메서드의 복잡도가 높아지고 이해하기 어려워집니다.
5. 전역 변수의 과도한 사용: 전역 변수를 과도하게 사용하면 예측하기 어려운 버그가 발생할 가능성이 높아집니다.

이러한 코드 스멜을 발견했을 때는 리팩토링을 통해 코드의 품질을 개선하는 것이 좋습니다. 리팩토링은 코드의 외부적인 동작을 변경하지 않으면서 내부 구조를 개선하는 작업을 의미합니다.

결국, 코드 스멜은 좋은 코드와 나쁜 코드를 구분하는 데 도움을 주는 경험적인 지표입니다. 주기적으로 코드를 검토하고 코드 스멜을 찾아내어 개선하면, 소프트웨어의 품질을 높이고 장기적인 유지보수를 용이하게 할 수 있습니다.

함수 분해를 위한 리팩터링 패턴 소개

리팩터링 패턴: 메서드 추출

• 메서드 추출은 한 메서드의 일부를 취해서 자체 메서드로 추출합니다.

추상화 수준을 맞추기 위한 함수 분해

• 위의 설명으로 5줄이상 코드는 메서드 추출로 한 메서드당 5줄 제한 달성
• 메서드는
  • 호출 또는 전달 한가지만 할 것

좋은 함수 이름의 속성

• 정직해야 합니다. 함수의 의도를 설명해야 합니다.
• 완전해야 합니다. 함수가 하는 모든 것을 담아야 합니다.
• 도메인에서 일하는 사람이 이해할 수 있어야 합니다. 작업 중인 도메인에서 사용하는 단어를 사용하십시오. 그렇게 하면 의사 소통이 더욱 효율적이게 되고 팀원 및 고객과 코드에 대해 더 쉽게 이야기할 수 있다는 장점이 있습니다.

너무 많은 일을 하는 함수 분리하기

• 규칙: if 문은 함수의 시작에만 배치
• 정의: if 문이 있는 경우 해당 if 문은 함수의 첫 번째 항목이어야 합니다.

3장 요약

• 다섯 줄 제한 규칙은 메서드는 다섯 줄 이하여야 한다는 말입니다. 이것은 두 가지 이상의 작업을 수행하는 메서드를 식별하는 데 도움이 됩니다. 리팩터링 패턴인 메서드 추출을 사용해서 긴 메서드를 분해하고 메서드 이름으로 주석을 대신합니다.
• 호출 또는 전달, 한가지만 할 것 규칙은 하나의 메서드 내에서 객체에 있는 메서드를 호출하거나 객체를 매개변수로 전달할 수 있지만, 둘 다 해서는 안 된다는 말입니다. 여러 수준의 추상화가 섞여 있는 메서드를 식별하는 데 도움이 됩니다. 이 또한 메서드 추출을 사용해 서로 다른 수준의 추상화를 분리합니다.
• 메서드 이름은 투명하고 완전해야 하며 이해할 수 있어야 합니다. 메서드 추출을 사용하며 가독성이 향상되도록 매개변수의 이름을 바꿀 수 있습니다.
• if 문은 함수의 시작에만 배치 규칙은 if를 사용해 조건을 확인하는 경우 한 가지 작업만 수행하므로 메서드가 다른 작업을 수행하지 못하게 합니다. 이 규칙은 또한 하나 이상의 작업을 수행하는 메서드를 식별하는 데 도움이 됩니다. if 문을 분리하기 위해 메서드 추출을 사용합니다.