1장: 리팩터링 리팩터링하기
3p
좋은 코드란 사람이 읽기 쉽고, 유지보수가 용이하며, 의도대로 잘 동작하는 코드이다
3p
리팩터링이란 기능을 변경하지 않고 코드의 가독성과 유지보수가 쉽도록 코드를 변경하는 것이다
3p
대부분의 프로그래머는 코드를 작성하는 시간보다 읽고 이해하는데 더 많은 시간이 든다. 따라서 리팩터링의 첫번째 이유는 순전히 경제적인 것이다
2장: 리팩터링 깊게 들여다보기
17p
유지보수성은 얼마나 많은 후보를 조사해햐 하는지를 나타내는 표현이다. 읽고 살펴봐야 할 코드가 많을수록 시간이 더 오래 걸리고 무언가를 놓칠 가능성이 높다
17p
취약성의 근원은 일반적으로 전역상태(golbal state)이다
전역이란 고려한 범위를 벗어난 것을, 상태란 바뀔 수 있는 모든 것을 의미한다
17p
데이터가 전역일 경우 데이터와 연결된 변수에의해 변경될 수 있어 데이터가 손상되곤한다.
데이터가 불변속성이 유효한 상태로 유지되기란 거의 불가능하기 때문에 전역은 피해야한다.
18p
이런경우 리팩터링은 불벽속성을 더욱 쉽게 볼 수 있도록 서로 가깝게 이동시켜 유지보수성을 향상시킨다
'함께 변하는 것은 함께 있어야한다' 이를 불변속성의 범위제한(localizing invariatns)라고 부른다
19p
리팩터링의 세 가지 핵심은 아래와 같다
1. 의도를 전달함으로써 가독성 향상
2. 불변속성의 범위제한을 통한 유지보수성 향상
3. 범위 밖의 코드에 영향을 주지 않고 1,2항을 수행
19p
범위가 제한되지 않는 불변속성을 도입하는 상속보다는 컴포지션을 사용해야한다
컴포지션 중심으로 만들어진 시스템은 더 깔끔하게 코드를 결합하고 재사용할 수 있다
21p
컴포지션의 가장 큰 장점은 추가로 변경이 가능하다는 점이다. 이는 기존 기능에 영향을 주지않고 기능을 추가하거나 변경할 수 있음을 의미하며 SOLID의 개방폐쇄 원칙을 준수하는 것이다(소프트웨어 구성요소들은 확장에 대해 열려있고 수정에 대해 닫혀있어야한다)
21p
추가에 의한 변경방식을 따르는 코드는 기존코드를 보존할 수 있다
23p
소프트웨어는 실생활의 특정 측면을 모델링한 것으로 소프트웨어와 대응하는 실세계는 항상 존재한다.
이 실제세계의 구성요소를 도메인이라고 부른다
27p
메서드는 { 와 } 를 제외하고 5줄 이상 되지않는 것이 바람직하다
29p
메서드가 길다는 것 자체가 스멜이다. 한 번에 긴 메서드의 모든 논리를 머릿속에 담아 작업해야하기 때문이다
39p
자신감이 떨어지는 예쁜 코드를 만드는 것보다 특이하게 생긴 안전한 코드를 만드는 편이 낫다
40p
함수의 내용은 동일한 추상화 수준에 있어야한다
42p
좋은 함수 네이밍의 특징은 아래와 같다
1. 정직해야한다. 함수의 의도를 설명해야 한다.
2. 완전해야한다. 함수가 하는 모든 것을 담아야 한다
3. 도메인에서 일하는 사람이 이해할 수 있어야한다. 만약 도메인 전문용어가 있다면 도입해도 좋다
46p
If문은 함수의 시작에만 배치해야한다.
함수는 한가지 일만 해야한다. 다른 작업을 추출해서 if문 다음에 다른 작업을 하는 순간 코드스멜이다
기억하라 메서드는 반드시 한 가지 작업만 해야한다.
52p
if문에서 else를 사용하지 말것
프로그램에서 이해하지 못하는 타입인지를 검사하지 않는 한 if문에서 else를 사용하지 않는다
실생활과 달리 코드에서는 결정을 미루는 것이 낫다.
if-else를 사용하면 코드에서 결정되는 지점이 고정되어 유연성이 떨어진다
이 경우에 메서드를 인라인화 해보자
81p
일반화를 줄이고 좀 더 특정화한 버전의 함수를 도입하는 것을 메서드 전문화라고 부른다
프로그래머들은 일반화하고 재사용하려는 본능적인 욕구가 있지만 이렇게 되면 책임이 흐려지고 다양한 위치에서 코드를 호출할 수 없다. 좀 더 전문화된 메서드는 더 적은 위치에서 호출되어 필요성이 없어지면 더 빨리 제거할 수 있다.
85p
switch를 사용하지 말자! (?ㅅ? 그만해..)
default 케이스가 없고 모든 case에 반환 값이 있는 경우가 아니라면 switch를 사용하지 말자
86p
switch의 또 다른 문제는 break 키워드를 만나기 전까지 케이스를 연속해서 실행하는 fall-through 로직이라는 것이다.
86p
일반적으로 switch는 멀리하는 것이 좋다. 만약 사용한다면 모든 케이스에 return을 지정해서 풀스루 문제를 해결하자(검색해보니 Swift는 해당 안되는 문제임 참고!)
