책너두 5기 17일차 로버트 C. 마틴의 클린코드 p.151 ~ p.160 내용 정리 8. 경계 깨끗한 경계 통제하지 못하는 코드를 사용할 때는 과투자나 향후 변경 비용의 과대화를 주의해야 한다. 통제 불가능한 외부 패키지보다 통제 가능한 우리 코드에 의존하는 것이 좋다. 9.단위 테스트 과거의 단위 테스트는 자기 프로그램이 ‘돌아간다’는 사실만 확인하는 일회성 코드였다. TDD 법칙 세가지 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. ...
책너두 5기 16일차 로버트 C. 마틴의 클린코드 p.142 ~ p.150 내용 정리 8. 경계 패키지나 오픈 소스를 사용할 때, 외부 코드를 우리 코드에 깔끔하게 통합해야 한다. 이를 위해 소프트웨어 경계를 깔끔하게 처리해야 한다. 외부 코드 사용하기 인터페이스 제공자는 많은 고객이 사용하길 바라기 때문에 적용성을 넓히지만, 사용자는 자신의 니즈에 집중하는 인터페이스를 바란다. 이 사이에서 문제가 발생한다. 예시 : java.util.Map 사용자는 마음만 먹으면 어떤 객체 유형도 추가할 수 있다. 아래처럼 Sensor라는 객체를 담는 Map을 만든다. ...
책너두 5기 15일차 로버트 C. 마틴의 클린코드 p.132 ~ p.141 내용 정리 7. 오류 처리 Try-Catch-Finally 문부터 작성하라 예시 : 파일이 없으면 예외를 던지는지 알아보는 단위 테스트. 1 2 3 4 @Test(expeccted = StroageException.class) public void retrieveSectionShouldThrowOnInvalidFileName() { sectionStore.retrieveSection("invalid - file"); } 위 단위 테스트에 맞춰 다음 코드를 구현 1 2 3 4 public List<RecordedGrip> retrieveSection(String sectionName) { // 실제로 구현할 때까지 비어 있는 더미를 반환한다. return new ArrayList<RecordedGrip>(); } 위 코드는 예외를 던지지 않으므로 테스트는 실패. 코드를 변경한다. ...
책너두 5기 14일차 로버트 C. 마틴의 클린코드 p.123 ~ p.131 내용 정리 6. 객체와 자료 구조 디미터 법칙 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙. 즉, 객체는 조회 함수로 내부 구조를 공개하면 안된다. final String outputDir = ctxt.getoptions().getScratchDir().getAbsolutePath(); 위 코드는 디미터 법칙을 어겼다. 각 함수가 반환하는 객체의 함수를 호출하기 때문이다. 기차 충돌 위와 같은 코드를 기차 충돌(train wreck)으로 부른다. 길게 이어진 기차같은 이 코드는 다음과 같이 수정할 수 있다. ...
책너두 5기 13일차 로버트 C. 마틴의 클린코드 p.111 ~ p.122 내용 정리 5. 형식 맞추기 들여쓰기 계층에서 각 수준은 이름을 선언하는 범위이자 선언문과 실행문을 해석하는 범위이다. 들여쓰는 정도는 계층에서 코드가 자리잡은 수준에 비례한다. 들여쓰기한 파일은 구조가 한눈에 들어온다. 변수, 생성자 함수, 접근자 함수, 메서드가 금방 보인다. 들여쓰기 무시하기 한 행에 범위를 뭉뜽그린 코드를 피해야 한다. 간단한 if 문, 짧은 while 문 등에서도 마찬가지. 가짜 범위 빈 while문이나 for문은 피해야 한다. 필요하다면 빈 블록을 올바로 들여쓰고 괄호로 감싸야 한다. ...
책너두 5기 12일차 로버트 C. 마틴의 클린코드 p.103 ~ p.110 내용 정리 5. 형식 맞추기 종속 함수 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다. 가능하면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. 상수를 알아야 마땅한 함수에서 실제로 사용하는 함수로 상수를 넘겨주는 방법은 좋다. 개념적 유사성 개념적인 친화도가 높은 함수는 가까이 배치한다. 한 함수가 다른 함수를 호출해 생기는 직접적인 종속성, 변수와 그 변수를 사용하는 함수, 비슷한 동작을 수행하는 일군의 함수 등. ...
책너두 5기 11일차 로버트 C. 마틴의 클린코드 p.95 ~ p.102 내용 정리 5. 형식 맞추기 처음 코드를 봤을 때 깔끔하고 일관적이며 꼼꼼한 코드로 보여야 한다. 그러기 위해선 규칙을 따라야 한다. 형식을 맞추는 목적 분명히 코드 형식은 중요하다. 오늘 구현한 기능이 다음 버전엣 ㅓ바뀔 확률은 아주 높다. 따라서 오늘 작성한 코드의 가독성은 미래에도 영향을 끼친다. 적절한 행 길이를 유지하라 파일의 세로 길이가 조금만 차이나도 실제 파일의 크기는 크게 달라진다. 비교적 적은 줄의 파일로도 커다란 시스템을 구축할 수 있다. 반드시는 아니지만 바람직한 규칙이다. ...
책너두 5기 10일차 로버트 C. 마틴의 클린코드 p.84 ~ p.94 내용 정리 함수나 변수로 표현할 수 있다면 주석을 달지 마라 명명법을 올바르게 사용하여 주석의 필요성을 없애자. 위치를 표시하는 주석 // Actions //////////// 같은 배너 아래에 모아두는 것은 필요할 때도 있지만 극히 드물게 사용해야 한다. 닫는 괄호에 다는 주석 차라리 함수를 줄이는데 시간을 쓰자 저자를 표시하는 주석 준수가 작성함은 소스 코드 관리 시스템이 있는 한 무의미한 주석이다. 주석으로 처리한 코드 내가 주석으로 처리하면, 다른 사람은 지우기를 주저 한다. 이전의 기록은 소스 코드 관리 시스템이 한다. 지금 필요없으면 지우자. 기록은 존재한다. ...
책너두 5기 9일차 로버트 C. 마틴의 클린코드 p.74 ~ p.83 내용정리 나쁜 주석 대부분은 나쁜 주석이다. 주절거리는 주석 특별한 목적이나 이유가 없는 주석. 달아야 한다면 제대로 명확하게 달자 같은 이야기를 중복하는 주석 코드 내용을 그대로 중복하는, 쓸데없는 주석 오해할 여지가 있는 주석 값이 반환되는 곳, 조건 등이 불확실하게 전달되선 안된다. 의무적으로 다는 주석 모든 코드에 주석을 달아야 한다는 등의 규칙은 불필요하다. 이력을 기록하는 주석 이젠 깃과 같은 관리 시스템이 존재하니 필요 없어졌다. ...
책너두 5기 8일차 로버트 C. 마틴의 클린코드 p.67 ~ p.73 내용정리 4. 주석 나쁜 코드에 주석을 달지 마라. 새로 짜라. 브라이언 W. 커니핸, P. J. 플라우거 주석은 실패를 만회하기 위해 사용된다. 주석 없이는 자신을 표현할 방법을 찾지 못해 할 수 없이 사용하기 때문이다. 주석은 거짓말을 한다. 코드는 유지 보수 되지만 주석은 그렇지 않기 때문이다. 코드가 수정되고 변화하고 진화하지만 주석은 그대로면서 거짓이 되고 잘못된 정보를 퍼뜨린다. 엄격하게 관리된 주석이 필요할 수도 있지만, 결국 최선은 주석이 필요없는 코드이다. ...