2022-01-30
제로베이스-한달한권 클린코드 DAY13
Chapter.17
Chapter 17 - 냄새와 휴리스틱(클린코드 규칙들 총정리)
01. 철학
나쁜 코드가 나쁜 이유
- 생산성 저하
- 나쁜 코드는 팀 생산성을 저하시킨다.
- 기술부채를 만들어 수정을 더 어렵게 한다.
클린 코드
- 성능이 좋은 코드
- 의미가 명확한 코드 = 가독성이 좋은 코드
- 중복이 제거된 코드
창발적 설계 4번째 규칙
- 실용적 관점에서 타협한다.
- 여러가지 규칙에 극단적으로 심취해 클래스와 메서드를 무수하게 만들지 말라.
- 결국 좋은 코드를 만드는 이유는 생산성을 올리기 위한 것이다.
- 실용적인 관점에서 타협해야 한다.
보이스카우트 룰
전보다 더 깨끗한 코드로 만든다
02. 공동 창작 매너
- 네이밍
- 함수
- 주석
- 포맷팅
- 위 4가지 관점을 생각하면서 개발하도록 노력한다.
함께 코드를 공동 창작하고 소비하는 나와 동료 개발자들을 위한 매너
Team Coding Convention
- 팀의 코딩 스타일에 관한 약속
우리 팀의 컨벤션이 가장 중요하다
03. 객체 지향 패턴
캡슐화(Encapsulation)
- 객체의 실제 구현을 외부로부터 감추는 방식
외부 코드와 호환하기 - Adapter 패턴
- 외부 코드를 호출할 때, 우리가 정의한 인터페이스 대로 호출하기 위해 사용하는 패턴
높은 결합도, 낮은 응집도
결합도 - 다른 모듈간의 의존도
응집도 - 모듈 내부의 기능 집중도
SOLID 원칙
객체지향 설계의 5가지 원칙
S : SRP(Single Responsibility Principle) - 단일 책임 원칙
O : OCP(Open Close Principle) - 개방-폐쇄 원칙
L : LSP(Liskov's Substitution Principle) - 리스코프 치환 원칙
I : ISP(Interface Segregaion Principle) - 인터페이스 분리 원칙
D : DIP(Dpendency Inversion Principle) - 의존성 역전 원칙
Chapter.3 - https://jin-blog-blush.vercel.app/posts/CleanCode-2/
04. 오류 처리
Unchecked Exeption을 사용하자
안정적인 소프트웨어를 제작하는 요소로 확인된 예외가 반드시 필요하지는 않다는 사실이 분명해졌다.
C#은 확인된 예외를 지원하지 않는다 영웅적인 시도에도 불구하고
C++역시 확인된 예외를 지원하지 않는다. 파이썬이나 루비도 마찬가지다.
그럼에도 불구하고 C#, C++, 파이썬, 루비는 안정적인 소프트웨어를 구현하기에 무리가 없다.
Chapter.7 - https://jin-blog-blush.vercel.app/posts/CleanCode-6/
05. 테스트
Test Pyramid
-
Unit Test: 프로그램 내부의 개별 컴포넌트의 동작을 테스트한다. 배포하기 전에 자동으로 실행되도록 많이 사용한다.
-
Integration Test: 프로그램 내부의 개별 컴포넌트들을 합쳐서 동작을 테스트한다. Unit Test는 각 컴포넌트를 고립시켜 테스트 하기 때문에 컴포넌트의 interaction을 확인하는 Integration Test가 필요하다.
-
E2E Test: End to End Test. 실제 유저의 시나리오대로 네트워크를 통해 서버의 Endpoint를 호출해 테스트한다.
FIRST 원칙
F(Fast): 빠르게
- 테스트는 빨리 돌아야 한다. 자주 돌려야 하기 때문이다.
I(Independent): 독립적으로
- 각 테스트를 독립적으로 작성한다. 서로에게 의존하면 실패한 원인을 찾기 어려워진다.(다른 테스트의 실패로 인한건지, 코드 오류인지)
R(Repeatable): 반복가능하게
- 테스트는 어떤 환경에서도 반복가능해야 한다. 실제 환경, QA환경, 모든 환경에서 돌아가야 한다.
S(Self-Validating): 자가검증하는
- 테스트는 bool값으로 결과를 내야 한다.
T(Timely): 적시에
- 테스트 하려는 실제 코드를 구현하기 직전에 구현한다.
Chapter.9 - https://jin-blog-blush.vercel.app/posts/CleanCode-8/
06. 개선
점진적으로 개선하기
-
코드가 나빠지고 있음을 느꼈을 때 기능을 추가하지 않고 개선을 시작한다.
-
테스트 코드를 작성한다.
- 변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아가야 한다.
- 테스트 코드가 없다면 작성하고, 코드를 수정하기 전 상태에서 모든 테스트가 통과해야 한다.
- 점진적으로 개선한다.
- 책임에 따라 클래스를 나누고, 코드를 옮긴다. 테스트가 깨지지 않도록 확인하며 자잘한 변경을 조금씩 진행한다.
Chapter.14 - https://jin-blog-blush.vercel.app/posts/CleanCode-12/
제로베이스-한달한권 클린코드 DAY12
Chapter.13, 14
제로베이스-한달한권 클린코드 END
후기