클린코드..
꽤나 두꺼운 책이었다.
책 모퉁이에 적혀있는 페이지 최대 수만 550 페이지였다.
너무 내용이 많아서 기억나는 것만 정리해본다.
나중에 스스로 돌아봤을 때 클린한 코드를 실천하는 개발자가 되었는지 되돌아보기 위해
책의 순서와 상관 없는 기록이오니 참고 바람..
1. 주석은 꼭 필요한 내용만 쓴다.
소스에 대한 전체적인 흐름이나 프로세스만 알아보기 쉽게 정리한다.
모든 소스에 대해 일일이 설명할 필요는 없다.
소스 코드에 대해 일일이 해석이 필요한 주석은 사용하지 말아야한다.
소스코드가 바뀌면 주석도 바뀌나? 절대 아니다
소스코드에 대한 이력은 형상관리가 알아서 해줄 것이다.
2. 소스코드는 하나의 소설과 같다.
우리가 책을 읽을 때 내용을 쭈욱 읽어나가는 것처럼, 소스코드 또한 마찬가지이다.
하나의 정성스러운 글짓기로 봐야한다.
읽기 쉬운 책은 잘 판매되며, 책에서 전하고자 하는 메시지가 잘 전달된다.
읽기 어려운 책은 아무리 봐도 내용이 잘 전달되지 않고 오히려 난해해진다.
잘 읽혀지는 소설책처럼, 소스코드도 잘 정리하여 써야한다.
3. 의미와 용도를 분명하게
변수명과 함수명을 지을 때 너무 많은 의미가 함축된다면 무슨 의미인지 이해하기 어렵다.
"보험가입나이" 라는 변수를 사용할 때,
int age 라고만 쓰면 나이를 뜻하는 모든 변수에 대해 헷갈릴 수 있다.
좀 더 명확하게 용도를 구분해야한다.
int insuranceEnterAge 와 같이, 아니면 insEntAge와 같이 하면 의미를 명확하게 할 수 있다.
4. 이름이 길어지더라도 명확할수록 좋다.
위와 같은 예인데 변수명이 역할마다 구분될 수 있고, 또 사용 목적이 각각 존재한다면
최대한 구체적으로 짓는게 좋다.
보험가입나이, 만나이, 연금개시나이 모두 나이(Age)가 들어간다.
하지만 이 모든 변수를 age로 처리하기엔 한계가 있다.
insuranceEnterAge, onlyAge, annuityOpenAge 와 같이 세부적으로 변수에 대해 설명을 하면
역할이 분명해지고 값을 잘못 건드릴 확률이 낮아진다.
5. 하나의 함수는 하나의 역할만 하도록 한다.
객체지향 5대 원칙 중, SRP(Single Responsibility)를 준수하도록 프로그래밍 해야한다.
https://drcode-devblog.tistory.com/324
[Spring] 좋은 객체 지향 설계의 5가지 원칙의 적용
여기서 3가지 SRP, DIP, OCP 적용 SRP 단일 책임 원칙 "한 클래스는 하나의 책임만 가져야 한다." 클라이언트 객체는 직접 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가지고 있음 SRP 단
drcode-devblog.tistory.com
SRP는 위에 잘 설명되어있다.
하나의 함수에 여러가지 역할이 부여된다면, 소스가 굉장히 지저분해진다.
예를 들어서, 개인정보저장이라는 로직을 처리하는데,
개인정보저장에 해당되는 모든 일련의 과정들을 다 한 함수에 때려박으면 안된다.
handleIndividualInformation() {
// 유효값 확인
// 가입한도체크
// 신분증 확인
// 정보 저장
}
위와 같이 개인정보를 저장할 때 필요한 일련의 과정을 한 함수에 넣으면 역할이 애매해진다.
// 유효값 확인
checkValidValue() {}
// 가입한도 체크
checkEnterLimit() {}
// 신분증 확인
checkIdCard() {}
// 정보 저장
saveInformation() {}과 같이 세부적으로 나눠서 한 함수에 단일 책임을 준수할 수 있도록 해야한다.
6. 클래스는 작아야 한다.
클래스도 위에서 언급한 변수와 함수처럼 한 역할에 충실할 수 있도록 해야한다.
하나의 클래스를 작은 여러 클래스로 나누는 시도를 해보자.
비록 클래스가 많아져서 관리하기 어려워보이지만,
클래스가 하나의 역할을 하게 되어 에러 발생 시 관리가 용이하다
7. 구체화에 의존하지 말고 추상화에 의존해야한다.
구체화에 의존하게 되면, 모든 구현체에 에너지를 쏟게 된다.
잘 설계한 인터페이스는 구현하는데 에너지를 적게 쓰게 한다.
그리고 인터페이스가 잘 설계되어있을수록 구현체마다 각각의 책임을 갖게 되니
추상화에 의존할수록 깔금하고 효율적인 코드가 완성된다.
8. Exception은 한 뎁스만으로도 충분하다
try {
try {
try {
} catch(Exception e) {
}
} catch(Exception e) {
}
} catch(Exception e) {
}
위 코드는 벌써 보기만해도 피곤하다
뎁스는 적을수록 좋다.
뎁스가 많을수록 소스코드가 난해해진다.
그리고 디버그하기가 어려워진다.
에러처리는 하나만 처리할 수 있도록 해야한다.
9. Null을 반환하지 않고, Null을 전달하지 않아야 한다.
Null 전달 및 반환만큼 소스코드에서 제일 효율이 떨어지고 의미가 없다.
10. 중복을 최소화하라.
소스를 가장 더럽게 하는 것은 중복이다.
여러번 반복되는 로직을 하나의 함수로 처리하여
해당 로직이 필요할 때마다 만든 함수를 호출하면 그만큼 효율적으로 처리할 수 없다.
11. 클래스와 변수의 갯수는 최소화 해야한다.
세부적으로 역할을 나눈 클래스와 변수는 잘 짜여지고 효율적인 코드인 것은 맞지만,
같은 의미를 가지고 비슷한 역할을 가진 클래스와 변수를 묶어 갯수를 최소화하는 것이 더 이상적이다.
12. 테스트를 할 때는 모든 경우를 고려한 테스트 케이스를 작성해야한다.
테스트가 세부적이고 모든 경우가 다뤄진만큼 시스템은 안정적이다.
가능한 모든 케이스를 다룬 테스트를 해야한다.
13. 부정적인 조건은 피해야한다.
조건이 부정적이면, 해당 조건을 해석하고 그 해석한 조건에 부정을 달아야한다.
웬만하면 한번에 읽힐 수 있는 조건을 처리하도록 해야한다.
14. 이 모든 과정은 관리가 용이하고 버그를 쉽게 잡을 수 있게 하기 위함에 있다.
댓글