기록이 힘이다.

동기화하는 부분을 작게 만들어라 자바에서 synchronized 키워드를 사용하면 락을 설정한다. 같은 락으로 감싼 모든 코드 영역은 한 번에 한 스레드만 실행이 가능하다. 락은 스레드를 지연시키고 부하를 가중시킨다. 반면, 임계영역은 반드시 보호해야 한다. 따라서, 코드를 짤 때는 임계영역 수를 최대한 줄여야 한다. 올바른 종료 코드는 구현하기 어렵다 깔끔하게 종료하는 코드는 올바로 구현하기 어렵다. 가장 흔히 발생하는 문제가 데드락이다. 즉, 스레드가 절대 오지 않을 시그널을 기다린다. 깔끔하게 종료하는 다중 스레드 코드를 짜야 한다면 시간을 투자해 올바로 구현하기 바란다. 스레드 코드 테스트하기 코드가 올바르다고 증명하기는 현실적으로 불가능하다. 테스트가 정확성을 보장하지 않는다. 그럼에도 충분한 ..

클래스 체계 (자바의 경우) 가장 먼저 변수 목록을 작성 정적(static), 공개(public) 상수가 있다면 맨 처음에 나온다. 다음으로 정적 비공개(private)변수가 나오며, 비공개 인스턴스 변수가 나온다. 변수 목록 다음에는 함수가 나온다. 공개 함수를 먼저 쓴다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. ⇒ 추상화 단계가 순차적으로 내려간다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 좋다. (반드시는 아니다) 때로는 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. → 하지만 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. 클래스는 작아야한다 클래스를 만들 때 제일 중요한 것은 **“크기가 작아야 한다”**이다. → 여기서 작아야하는 것은 물..

TDD 법칙 세 가지 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세 가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다. 테스트 코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다. 이렇게 일하면 매일 수십 개, 매달 수백 개, 매년 수천 개에 달하는 테스트 케이스가 나온다. 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다. 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다. 깨끗한 테스트 코드 유지하기..

형식을 맞추는 목적 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다. 오늘 구현한 코드의 가독성은 앞으로바뀔 코드의 품질에 지대한 영향을 미친다. 원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. 적절한 행 길이를 유지하라 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다. -신문 기사처럼 작성하라 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다. 신문 기사는 아주 짧다. 한 면을 채우는 기사는 거의 없다. 신문이 읽을 만한 이유는 여기에 있다. -개념은 빈 행으로 분리하..

1장 깨끗한 코드 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. ‘코드 감각’을 확실히 얻는다는 보장도 없다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다. 2장 의미있는 이름 의도를 분명히 밝혀라 그릇된 정보를 피하라 int a =l; if(O == l) a = O1; else L = 01; 위와 같은 0(영)이나 O(영어 오) 등의 경우 의미있게 구분하라 customerInfo는 customer과 accountData는 account와 theMessage는 message와 구분이 안 된다. 읽는 사람이 차이를 알도록 이름을 지어라. 발음하기 쉬운 이름을 사용하라 검색하기 쉬운 이름을 사용하라 인코딩을 피하라 -헝가리식 표기법 -인터페이스 클..