#1_Clean Code(클린 코드)를 읽고(1,2,3장 정리) :: 개발/일상_Mr.lee

#1_Clean Code(클린 코드)를 읽고(1,2,3장 정리)

Posted by Mr.mandu.
2019. 3. 28. 00:01 개발/서적

안녕하세요.

개발자분들 혹시 책들 자주 읽으시나요?

특히 공부하려고 개발 서적들 많이들 구매하시나요?

 

저는 의욕만 앞서 책들을 하나씩 구매하곤 했습니다.....

그중 하나인 Clean Code 입니다.

 

책은 다음과 같습니다.

Clean Code 클린코드

 

책에 대한 내용을 포스팅하게 된 계기는...

일단 책을 읽으면서 술술 읽어 나가다가 막히는 부분에서 대충 넘어가게 되면

그 내용은 기억에 남질 않더라고요.

그래서 공부할 부분도 적고 약간의 내용도 적어놓아서 나중에 기억을 되찾기 위함입니다.

 

그리고 Clean Code는 개발을 시작하시는 분들에게 참 좋은 내용이 많습니다.

기본적인 내용이 들어있어 1~2년 차 분들에게도 좋고

나중에 가서는 의존성 주입, 디자인 패턴 등의 내용이 나오기 때문에 5년 차 이상분들에게도 도움이 될거라 생각합니다.

5년차 이상이신 분들은 한 번씩은 읽어 보셨으리라 생각됩니다.

 

서론이 길었습니다.

 

제가 1장부터 3장까지의 내용을 적어둔 부분입니다.

포스팅을 보신분들은 내용만 ...아 이런것들이 있구나 라고 보시면 될것 같습니다.

철저히 저의 기준으로 적었기때문에 빼놓은 부분들도 많습니다.

 

주황색 부분은 제가 따로 공부할 것들이며 그냥 넘기셔도 좋습니다.

 

1장 : 깨끗한 코드

   ○ 깨끗한 코드는 한가지에 ‘집중’한다.

 

   ○ 나쁜코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다.

 

   ○ 가독성이 좋아야 한다.

 

   ○ 다른사람이 고치기 쉬워야 한다.

 

   ○ 중복 줄이기, 표현력 높이기, 추상화 고려하기

 

   ○ 공부 : 추상 메서드, 추상클래스, ppp책(prin-ciples, Patterns. and Practies)

 

   ○ SRP(The Single Responsibility Principle)

      - 클래스에는 한 가지, 단 한 가지 변경 이유만 존재해야 한다.

 

   ○ OCP(The Open Closed Principle)

      - 클래스는 확장에 열려 있어야 하며 변경에 닫혀 있어야 한다.

 

   ○ LSP(The Leskov Substitution Principle)

      - 상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다.

 

   ○ DIP(The Dependency Inversion Principle)

      - 추상화에 의존해야 하며, 구체화에 의존하면 안된다.

 

   ○ ISP(The Interface Segregagion Principle)

      - 클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지해야 한다.

 

2장 :  의미있는 이름

   ○ 의도를 분명히 밝혀라

 

   ○ 그릇된 정보를 피하라

      - 서로 흡사한 이름을 사용하지 않도록 주의한다.

      - 유사한 개념은 유사한 표기법을 사용한다.

 

   ○ 의미있게 구분하라

      - ex) moenyAmount는 money와 구분이 안된다.

 

   ○ 발음하기 쉬운 이름을 사용하라

 

   ○ 검색하기 쉬운 이름을 사용하라

 

   ○ 인고딩을 피하라

      - 인터페이스 클래스와 구현 클래스 (ShapeFactory 인터페이스클래스, ShapeFactoryImp) 

 

   ○ 클래스이름

      - 명사나 명사구가 적합(Account, AddressParser)

 

   ○ 메서드 이름

      - 동사나 동사구가 적합(postPayment, deletePage)

3장 : 함수

   ○ 작게 만들어라

      - if/else, while 문에 들어가는 줄은 되도록이면 한줄로 표현해라

 

   ○ 함수당 추상화 수준은 하나로

      - 위에서 아래로 코드 읽기 : 내려가기 규칙

 

   ○ Switch문 (객체지향적으로 리펙토리 할수있음)

      - 코드의 중복으로 다형성이 떨어진다(간단한 것은 상관 없음) 48 페이지 참조

 

   ○ 서술적인 이름을 사용해라

 

   ○ 함수인수

      - 인수개수는 0개가 제일 좋고 다음 1개...3개 이상은 안좋다.

      - 플래그 인수 안좋다

 

   ○ 오류 코드보다는 예외를 사용하라

 

   ○ Try/Catch 블록 뽑아내기

      - try/catch 블록은 추하다... 별도로 함수로 뽑아내라

 

정리를 해두는것이 머리에 잘 남는것 같네욤.

모두 고생하세요.