[노개북챌린지] CleanCode TIL 1장 깨끗한 코드

DAY 2

범위 : ~ 1장. 깨끗한 코드

▶ 책에서 기억하고 싶은 내용

◎ 코드는 요구 사항을 표현하는 언어

◎ 르블랑의 법칙 ( Leblanc's Law, 나중은 절대 돌아오지 않는다는 법칙 )

◎ 나쁜 코드가 쌓일수록 팀 생산성은 떨어짐

◎ 깨끗한 코드란 세세한 사항까지 꼼꼼하게 처리하는 코드

◎ 깨끗한 코드는 단순하고 직접적 ( 가독성 )

◎ 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉬움 ( 유지보수용이 )

◎ 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 주는 것

◎ 단순한 코드규칙 

    →모든 테스트를 통과

    →중복x

    →시스템 내 모든 설계 아이디어를 표현

    →클래스, 메서드, 함수등을 최대한 적게 작성

◎ 보이스카우트 규칙 ( 모듈을 체크인할 때는 항상 체크아웃했을 때보다 깨끗해야 한다. )

◎ 프리퀼과 원칙

    →SRP(Single Responsibility Principle) : 클래스에는 단 한가지 변경이유만 존재해야 한다.

    →OCP(Open Closed Principle) : 클래스는 확장에 열려있어야하며 변경에 닫혀있어야 한다.

    →LSP(Liskou Subsitution Principle) : 상속 받은 클래스는 기초 클래스를 대체할 수 있어야한다.

    →DIP(Depending Inversion Principle) : 추상화에 의존하되 구체화에는 의존하지말아야한다.

    →ISP(Interface Seregation Principle) : 클라이언트는 자신이 이용하지 않는 메서드에 의존하면 안된다. ( 기능을 쪼개고 쪼개서 SRP를 지니게 하는 것         을 도와줌)

 

 

---

 

▶ 오늘 읽은 소감은? 떠오르는 생각

이전 프로젝트도 투입당시 프레임워크에 대한 지식이 없었고, 개발 중간에 들어간것이었기 때문에 

빠른 시간내에 개발을 했어야했다. 그래서 복붙도 서슴치 않았으며, 엉망으로 코드를 짰다.

기한내에 완료는 했지만 가독성이 떨어지는 코드를 리팩토링하고 싶었다. 

하지만 오늘 책에 나온 르블랑의 법칙처럼 이미 만들어놓은 코드를 다시 보기 싫었고 그대로 뒀다.

책에서는 내가 하고 겪은 그대로를 마치 서술한것같았고 다음부턴 그러지말아야지 하지만.. 또 촉박하게 개발을 하게된다면 난 또 앞뒤가리지않고 기능구현만 하겠지..? 라는 생각을 했다.



그러지 않으려면 꾸준히 공부하고 많은 코드를 보고, 잘 짜여진 코드를 많이 분석해봐야할것같다.