새 발의 피가 모여 개발의 피가 흐르는 그날까지

내 코드가 그렇게 이상한가요? (센바 다이야, 인사이트) 318~321p 14.5 리팩터링 시 주의 사항 1. 기능 추가, 리팩터링 동시에 하지 않기 - 동시에 진행x, 한 쪽에 집중하기 o - 리포지터리에 커밋할 때도, 기능 추가 / 리팩터링 따로 구분 2. 작은 단계로 실시하기 - 커밋 : 어떻게 리팩터링했는지 차이를 알 수 있는 단위로 e.g. 메서드 이름 변경, 로직 이동 -> 커밋 따로따로 구분 3. 불필요한 사양은 제거 고려하기 기여하지 않는 사양에 해당하는 코드 -> 리팩터링하더라도, 개발 향상에 도움 x 리팩터링 전, 불필요한 사양이 있는지, 사양 다시 확인해보기 (불필요한 사양, 코드 미리 제거)

(클린 코드 - 로버트 C. 마틴) +) 데메테르 법칙(최소 지식의 원칙) : SOLID 원칙에 포함 x, 객체 지향 설계에서 매우 중요 -> 직접적인 친구(클래스)와만 관련한다. (= 친구의 친구와는 놀지 말기) => 자기 자신, 자신이 가지는 클래스, 매개 변수로 전달한 클래스, 멤버 함수 내부에서 실체화한 클래스 1. SRP(Single Responsibility Principle, 단일 책임 원칙) : 클래스를 변경해야할 이유는 한 가지여야 한다 하나의 클래스는 하나의 책임만 가져야 한다 (클래스의 응집도와 관련) => 책임이 하나뿐인 응집도 높은 클래스 만들기! 2. OCP(Open-Closed Principle, 개방·폐쇄 원칙) : 소프트웨어의 구성 요소는 확장에 관해서는 열려있어야 하고, ..