1장. 깨끗한 코드

클린코드를 읽는 이유는 말 그대로 깨끗한 코드를 짜기 위함이다.

그렇다면 "나쁜 코드"는 무엇일까?

 

사실 정의하기에는 각각 다양한 정의가 나오기때문에 딱 잘라서 말하기 힘들다.

굳이 정의하자면.. 클린코드에서 권장하는 예시들이 있는데 그것들이 나쁜 코드라고 할 수 있을 것 같다.

"나쁜 코드"는 내가 이제까지 개발하면서 알게모르게 아니 알면서도 많이 썼던 것 같다.

 

예전 코드를 돌이켜 봤을때 나는, 컨트롤러에 비지니스 로직을 작성한것도 있고, 불필요한 주석과 로그들, 생각없이 짠 중복된 코딩들 .. 등등이 눈에 보였다.

 

책에서도 비슷한 내용이 나온다.

처음부터 소위말하는 나쁜코드로 결과물만 바라보고 코딩하게 된다면 처음에는 생산성은 높을 수 있으나, 점점 생산성은 0이 되버리고 만다.

1장은 깨끗한 코드는 무엇인지, 나쁜 코드는 무엇인지 그러한 내용이 대부분이다.

 

그중에서도 마지막 부분에 2가지 원칙을 이야기해주는데.

- 보이스카우트 규칙

"캠핑장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라." 라는 미국 보이스카우트가 따르는 규칙이다.

잘 짠 코드가 전부가 아니라, 시간이 지나도 언제나 깨끗하게 유지시켜주어야 한다는 말이다.

- SOLID 설계 원칙

• SRP(Single Responsibility Principle): 클래스에는 단 한가지, 한 가지 변경 이유만 존재해야 한다.
  • SRP 책임이 분명해짐 → 변경에 의한 연쇄 작용에서 자유로움.
  • 가독성, 유지보수 용이
  • 클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 함.
• OCP(Open Closed Principle): 클래스는 확장에 열려있어야 하며 변경에 닫혀 있어야 한다.
  • 변경을 위한 비용을 줄이고, 확장을 위한 비용을 극대화.객체지향 프로그래밍의 추상화와 다형성을 활용하여 개발.
  • 요구사항이 변경,추가 되더라도 기존 구성요소는 수정이 일어나지 않고 확장해서 재사용
  • 개방 - 폐쇄의 원칙
• LSP(Liskou Subsitution Principle): 상속 받은 클래스는 기초 클래스를 대체할 수 있어야 한다.
  • 클래스 상속, 인터페이스 상속을 이용해 확장성을 획득한다.인터페이스를 사용하는 것이 좋다. (다형성과 확장성 극대)
  • 서브 타입은 기반 타입이 약속한 규약(접근제한자, 예외) 을 지켜야 한다.
  • 리스코프 치환 원칙.
    
    
• ISP(Interface Seregation Principle): 클라이언트에 밀접하게 작게 쪼개진 인터페이스 유지한다.
  • 가능한 최소한의 인터페이스만 구현.
  • SRP는 클래스 단일책임, ISP는 인터페이스 단일 책임.
  • 인터페이스 분리 원칙
• DIP(Depending Inversion Principle): 추상화에 의존 해야 하며, 구체화에 의존 하면 안 된다.
  • 하위 모델의 변경이 상위 모듈의 변경을 요구하는 관계는 끊는다.
  • 의존성 역전 원칙