떼닝로그

창발적 설계로 깔끔한 코드를 구현하자 - 대다수는 켄트 벡이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. - 위 목록은 중요도 순이다. 단순한 설계 규칙 1 : 모든 테스트를 실행하라 - 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. - 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면, 문서 작성을 위해 투자한 노력에 대한 가치는 인정받기 힘들다. - 테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 '테스트가 가능한 시스템'이다. - 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어지는 등 설계 품질이 더불어 높..

" 복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다. " 도시를 세운다면? - 도시가 돌아가는 이유는 적절한 추상화와 모듈화 때문이다. 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 '구성요소'는 효율적으로 돌아간다. - 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. - 이 장에서는 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다. 시스템 제작과 시스템 사용을 분리하라 - 제작(construction)은 사용(use)과 아주 다르다. - 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다. - 시..

코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 이 장에서는 깨끗한 클래스를 다룬다. 클래스 체계 - 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다. - 정적(static) 공개(public) 상수가 있다면 맨 처음에 나오고, 다음으로 정적 비공개(private) 변수가 나오며, 이어서 비공개 인스턴스 변수가 나온다. 공개 변수가 필요한 경우는 거의 없다. - 변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣음으로, 추상화 단계가 순차적으로 내려간다. 캡슐화 - 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도..

애자일과 TDD(Test Driven Development) 덕택에 단위 테스트를 자동화하는 프로그래머들이 많아졌고 더 늘어나는 추세지만, 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한 사실을 놓치고 있다. TDD 법칙 세 가지 - TDD는 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다. 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. - 위 세 가지 규칙을 따르면 테스트 코드와 실제 코드가 함께 나올뿐더러, 테스트 코드가 실제 코..

외부 코드 사용하기 - 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려고 하지만, 사용자는 자신의 요구에 집중하는 인터페이스를 만듦 - 이러한 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 많다. - 위 이미지의 Map(java.util.Map)은 굉장히 다양한 인터페이스로 수많은 기능을 제공한다. - Map은 굉장히 다양한 인터페이스로, 수많은 기능을 제공하기 때문에 Map이 제공하는 기능성과 유연성은 유용하지만 위험도 크다. - 예를 들어, Map 사용자라면 누구나 clear()로 Map 내용을 지울 권한이 있고, Map의 객체 유형을 제한하지 않음으로써 사용자는 어떤 객체 유형도 추가할 수 있게 된다. # Sensor라는 객체를 담는 Map을 만드려면 다음과 같이 Map 생성 sens..

오류 처리는 중요하다. 하지만 오류 처리로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. 오류 코드보다 예외를 사용하라 - 예외를 지원하지 않는 언어는 오류를 처리하고 보고하는 방법이 제한적이었다. 아래의 코드를 보자. class DeviceController(): ... def sendShutDown(self): self.handle = self.getHandle(self.DEV1) # 디바이스 상태 점검 if self.handle != DeviceHandle.INVALID: # 레코드 필드에 디바이스 상태를 저장한다. self.retrieveDeviceRecord(self.handle) # 디바이스가 일시정지 상태가 아니라면 종료한다. if self.record.getSta..

- 남들이 변수에 의존하지 않게 만들기 위해 변수를 비공개로 정의한다. 자료 추상화 - 아래 첫 번째와 두 번째 코드 모두 2차원 점을 표현하지만, 한 클래스는 구현을 외부로 노출하고 다른 클래스는 구현을 완전히 숨긴다. # 6-1 class Point(): def __init__(self): self.x = 0.0 self.y = 0.0 # 6-2 class Point(): def __init__(self): pass def getX(self): pass def getY(self): pass def setCartesian(self, x:double, y:double): pass def getR(self): pass def getTheta(self): pass def setPolar(r:double, t..

- 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. - 코드 형식을 맞추기 위한 간단한 규칙을 정하고, 그 규칙을 착실히 따라야 한다. - 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. - 필요하다면 규칙을 자동으로 적용하는 도구를 활용한다. 형식을 맞추는 목적 - 코드 형식은 중요하다! - 융통성 없이 맹목적으로 따르면 안 된다... - 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. - 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 적절한 행 길이를 유지하라 - 위 이미지는 JUnit, FitNesse,..