CleanCode

챕터 1은 정리하지 않으려다가 양심을 찌르는 문구들이 너무 많아 정리...요구사항을 표시하는 언어아무리 추상화 수준이 올라간들 코드는 사리지지 않는다.따라서 좋은 코드를 작성하는 방법, 나쁜 코드를 좋은 코드로 바꾸는 실력을 배워야 한다.나쁜 코드를 짜는 이유: 급해서

이름을 잘 짓는 간단한 규칙 몇 가지 소개 1. 의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 걸리지만, 좋은 이름으로 절약하는 시간이 훨씬 더 많다. '변수, 함수, 클래스'의 이름은 '존재 이유, 수행 기능, 사용 방법' 이라는 질문에 답할 수 있어야 한다.

어떤 프로그램이든 가장 기본적인 단위는 함수 의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까? 작게 만들어라 한 가지만 해라 -> 도대체 그 한 가지가 무엇인지? 어떻게 판단? -> 의미를 유지하면서 더 이상 줄이기 힘들 때 까지 함수 당 추상화 수준은 하나

'나쁜 코드에 주석을 달지 마라. 새로 짜라' 주석이 필요한 상황에 처하면 곰곰이 생각해보고 코드로 의도를 표현할 수 있는 방법이 없을지 고민해보기 주석을 무시하는 이유 주석은 오래될수록 코드에서 멀어진다. 오래될 수록 완전히 그릇될 가능성도 커진다. 프로그래머들이

오랜 시간이 지나 우너래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다.JUnit, FitNesse 등은 500줄을넘어가는 파일이 없으며 대다수가 200줄 미만이

두 클래스 모두 2차원 점을 표현한다.하지만 한 클래스는 구현을 외부로 노출하고 한 인터페이스는 구현을 완전히 숨긴다.자료를 세세하게 공개하기보다는 인터페이스를 이용하여 추상적인 개념으로 표현하는 편이 좋다.캡슐화의 장점변경에 영향을 덜 받음(결합도가 낮아짐)불필요한

깨끗한 코드와 오류 처리는 확실히 연관성이 있다.오류처리는 중요하다. 하지만, 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.함수를 호출하는 동시에(명령) 오류를 확인(조회)를 해야 하기 때문에 복잡해진다.따라서 예외를 던지는

시스템에 들어가는 모든 SW 를 직접 개발하는 경우는 드물다.어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다.이 장에서는 SW 경계를 깔끔하게 처리하는 기법과 기교를 살펴본다.패키지 제공자/프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다.반면, 사

첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 즉, 테스트 코드 작성 후

클래스를 만들 때 첫 번째 규칙은 크기다.함수는 물리적인 행 수로 크기를 측정했다클래스는 맡은 책임을 센다아래 클래스는 메서드 수가 작음에도 책임이 너무 많다.클래스 이름은 클래스 책임을 기술해야 한다.작명은 클래스 크기를 줄이는 첫 번째 관문이다.아래 클래스를 말로

도시가 돌아가는 이유는 적절한 추상화와 모듈화 때문이다. 그래서 큰 그림을 이해하지 못하더라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다. 이 장에서는 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다. 1. 시스템 제작과 사용을

설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 문서로는 완벽하게 설계했지만 검증할 방법이 없다면 노력에 대한 가치는 인정받기 힘들다.테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다. 크기가 작고 목적 하나만 수행하는 클래스가 나온다. SRP

스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다.동시성은 바로 이 무엇과 언제를 분리하여 결합을 없애는 전략이다. 또한 응답 시간과 작업 처리량 개선을 위해서이기도 하다.이렇듯 동시성은 다양한 장점을 가지고 있지만, 이해 관한 오해도 존재한다.동시성은 항상 성능

프로그래밍은 과학보다 공예(craft)에 가깝다.깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다.책 초반에 잘 정돈된 코드가 먼저 나오는데, 처음부터 이 코드를 짠 것이 아니라 기능을 하나씩 덧붙여나가다가코드가 점점 알아보기 힘들어지자 리팩토링을 시작

조건문 캡슐화만약 저라면 (다른 곳에서 사용하는게 아니라면) 함수보다는 지역변수로 빼지 않았을까 싶습니다.명확한 변수명 부정문보다 긍정문함수 하나에는 한 가지 역할compact 라는 함수명과 달리 오류 점검이라는 부가 단계까지 포함또한 함수는 단순히 압축된 문자열이 아

주석은 코드가 변함에 따라 지속적으로 업데이트 되지 않을 확률이 높으므로 신중하게 달아야 한다.함수에서 인수의 개수는 작으면 작을 수록 좋다.appendFooter(s) 가 s 를 변경하는 함수인 경우 s.appendFooter() 가 역할 측면에서 더 적절모든 경계조