클린코드는 어떻게 보면 기본이기도 하지만
어떤 상황과 환경에서는 당장에 지켜야 할 수 없는 원칙이기도 합니다.
이는 대부분의 회사에서는 당장의 좋은 코드보다는 당장의 제품 출시 - 특히 경쟁사가 어떤 기능을 배포한다면 더더욱
가 훨씬 중요한 일이고 일정이 가장 중요한 일 중 하나이기 때문입니다.
그럼에도 코드의 퀄리티가 낮아지고 제품, 소프트웨어의 퀄리티가 낮아지는 것은 결국 복잡도가 증가함에 따라 유지보수나 개발의 속도를 저해시키는 주요 요소 중 하나입니다.
이런 클린 코드의 법칙을 기술한 책 중 파이브 라인즈 오브 코드라는 책이 있는데 관련 영상이 있어 조금 정리 해보았습니다.
파이브라인스 오브 코드 의 주요 목표
- 단일 책임 (SRP)
- 추상화(인터페이스 + 구현 구조)
- 캡슐화
이를 달성하기 위한 규칙 소개
다섯 줄로 만들기 위한 기본 패턴
- 메서드(함수) 추출
- 메서드의 이점 -> 이름을 가짐(맥락에 따른 의도/의미 표현) - 이는 함수의 복잡성을 단순화하고 읽는 사람(보통은 개발자)에게 있어 해당 코드의 의미를 보다 용이하게 유추하도록 합니다. 이는 리팩토링/클린코드에도 저술되어 있습니다.
단일 책임을 위한 두 규칙
- 규칙
- 이 두 규칙은 메서드 추출을 유도
추상화를 위한 규칙
- 규칙: if 문에서 else를 사용하지 말것
- 상태 + 코드 를 인터페이스 + 클래스로 변경
캡슐화
- 규칙: getter/ setter 사용하지 말기
Pull 기반의 구조(get으로 하는게 아니라) push 기반의 구조로 바꿔라
그러기 위한 규칙이 getter/ setter 사용하지 말기 이고 이를 통해서 캡슐화를 이뤄냄
그외
인라인
인터페이스만 상속
복잡한 조건 통합
유사코드 통합
코드 삭제
공통 접사 사용하지 말 것
영상에서 해당 내용의 추천이유는 다음과 같다고 저술하는데요,
1. 규칙이 단순해서 적용하기 쉬움
2. 객체 지향적으로 코드를 리팩토링하는 방법 익히기 좋음
3.동작이 눈에 보여 더 좋음
라는 장점을 가지고 있습니다.
개발에서 어떠한 기능을 이해하려고 할때, 혹은 내가 이 코드는 좀 이상한데?
혹은, 더 좋게 만들 수는 없을까? 라고 생각할 때 리팩토링을 시도하며 코드를 파악하고 개선해보려는 시도를 할 수 있습니다.
이와 같이 코드나 어떠한 것을 반드시 따라치면서 한다면, 때로는 기록으로 남기도 하고 머릿속에 시뮬레이션을 돌려볼 수 있기 때문에
눈으로만 단순히 보며 코드 변화를 따라가려고 시도하는 것보다 효율적일 수 있습니다.
다만 이러한 규칙들에 너무 매몰되지는 않고 자신의 환경과 상황, 특히 팀과 조직의 상황과 필요에 맞추어 필요한 내용들을 적용해 나가는 것이 바람직할 것입니다.
그럼에도 불구하고, 내가 가진 어떤 현재 상황에서 해당 내용을 적정 수준으로 적용해보는 것은 이러한 내용들을 자신의 능력으로 습득하기 위한 가장 빠르고 좋은 길 중 하나 일 것 입니다.
'디자인 패턴' 카테고리의 다른 글
개발 일상, 소소한 리팩토링 정리 (0) | 2024.01.11 |
---|---|
디자인패턴: 템플릿 메소드 패턴 (0) | 2022.12.15 |