바위타는 두루미

TDD 법칙 세가지 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다. 3. 현재 실패하는 테스트를 통과할 정도만 실제 코드를 작성한다. => 이렇게 일하면 테스트케이스가 너무많아지고, 많은 테스트케이스는 관리 문제를 유발하기도 한다. 깨끗한 테스트 코드 유지하기. - 지저분한 테스트 코드일수록 실제 코드가 변경할때 함께 변화하기 어렵다. 테스트는 유연성, 유지보수성, 재사용성을 제공한다. - 이를위해서는 단위테스트가 필요하다. 단위테스트가 없다면 수정이 두렵다. 깨끗한 테스트코드란 ? - "가독성" - 테스트는 명확히 세부분으로 나뉨 : 테스트자료를 만들기 -> 테스트자료 조작하기 -> 결과가 올바른지..

단순히 get, set함수를 만들어 변수를 다룬다고 class가 아니다. 그보다는 추상 인터페이스를 이용해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 class이다. 객체 vs 자료구조 - 자료구조를 사용코드 : 자료구조 변경없이 새 함수를 추가하기 쉽다. | 함수 변경없이 새로운 자료구조 추가하기 어렵다. - 객체지향 코드 : 함수 변경없이 class 추가하기 쉽다. | class변경없이 새로운 함수 추가하기 어렵다. - 분별있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다. 때로는 단순한 자료구조와 절차적인 코드가 적합한 상황이 있다. 디미터 법칙 -> 모듈은 자신이 조작하는 객체의 속사정을 몰라야한다. 클레스 C의 메서드 f는 다음과 같은 객체의 메서드만 호..

형식을 맞추는 일은 매우 중요하다 기능은 바뀌더라도, 맨 처음 잡아둔 구현 스타일과 가독성수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 좋은 형식은 무엇일까? 1. 적절한 행길이를 유지하라 - 큰 파일보다 작은 파일이 이해하기 쉽다. - 신문기사처럼 작성하라 : 상단은 고차원 , 하단으로 갈수록 저차원 (세부구현) - 개념은 빈 행으로 분리하라 - 수직거리 : 밀접한개념은 세로로 가까이 두어야한다. - 변수는 사용하는 위치에 최대한 가까이 선언한다. - 인스턴스 변수는 모아라 : 자바는 상단에, c++는 하단에 선언하는 편 - 종속함수 : 함수가 다른함수를 호출한다면 두 함수는 세로로 가까이, 가능하다면 호출하는 함수가 먼저! - 개념적 유사성이 높으면 가까이 2. 가로형식 맞추기 - 짧은 행이..

주석은 코드로 의도를 표현하지 못해서 사용하므로 실패이다. 주석은 거짓말을 하는 경우가 많다. 진실은 오직 code! 그럼 좋은 주석은? 1. 법적인 주석 : file 첫머리에 저작권정보와 소유권정보 ->Good 2. 의미를 명로하게 밝히는 주석 : 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 의미를 명료하게 밝히는 주석이 유용하다. 3. 경고하는 주석 4. todo주석 느낀점 - 이 책에서 말하는 나쁜 주석들은 이제는 형상관리툴로 커버가 가능한 부분들이고, 책 앞부분에 언급된 대로 함수를 쪼개고 이름을 잘 짓는 것 만으로도 없앨수 있는 부분들이 매우 큰 것 같다. 가능하다면 최대한 작성하지 않도록 하는것, 이전에 주석들은 이제는 다른 적절한 방법들로 개선하는 부분이 필요해 보인다.

좋은 함수를 만드는 법 1. 작게만들기 - if/else문 , while문 등에 들어가는 블록은 한줄이여야한다. - 장점 : 바깥을 감싸는 함수가 작아지고, 함수명이 적절하다면 코드 이해도 쉽다. 2. 한가지만 하기 - 함수가 한가지만 하는지 확인하는 방법 - 추상화 수준이 1개인지 - 의미있는 이름으로 다른함수를 추출할 수 있다면 그것은 여러작업을 하고있다! - 섹션으로 나뉘어지는지 확인 3. 함수의 추상화 수준은 하나로! - 이유 : 근본개념인지 세부사항인지 알기 어렵고, 사람들이 세부사항을 점점 더 추가한다. - 코드는 위에서 아래로 읽히도록, 아래로 갈수록 추상화 수준을 낮추기 4. Switch문 - switch문은 길고, 본질적으로 여러작업을함 - 꼭 써야한다면 추상 factory에 꽁꽁숨겨서 ..

기억하고 싶은 내용 Naming 이름지을때 생각해보아야 할 규칙 - 의도를 분명히 하기. thelist ( X) , gameBoard (O) -그릇된 정보를 피하기 - 개발시 이용하는 용어 주의하기 List가 아닌데 List사용 X - 흡사한 이름 사용하지 않기 - 한눈에 보기 어려운 이름 - 의미있게 구분하기 : 컴파일러만 통과하는 코드는 x - 연속적인 숫자를 추가하는경우 : 의미없는 이름 - 두 변수가 구분이 안되는 경우 ~Data, ~Info => 구분하기 어렵다 - 발음하기 쉬운 이름 사용하기 - 검색하기 쉬운 이름 - 이름길이는 범위크기에 비례해야한다. -인코딩을 피하라 - 타입표기할 필요없다. - 접두어 붙일 필요없다. -> 클래스, 함수는 작아져야하고, 멤버변수를 다른 색상으로 표시하는 I..