책너두 5기 20일차 로버트 C. 마틴의 클린코드 p.180 ~ p.188 내용정리 10. 클래스 변경하기 쉬운 클래스 대다수 시스템은 지속적인 변경이 가해지고 그때마다 시스템이 의도대로 동작하지 않을 위험이 따른다. 따라서 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는다. 읽고나서 오늘 읽을 분량의 대부분은 java와 sql 관련 코드들로 가득했다.. 확실한건 새 기능을 추가할 때, 기존의 것이 변경되지 않도록 시스템을 구성하는 것이 중요하다는 것! ...
책너두 5기 19일차 로버트 C. 마틴의 클린코드 p.170 ~ p.179 내용 정리 10. 클래스 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 클래스 체계 자바에선 일반적으로 추상화 단계가 순차적으로 내려간다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 하지만 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. 클래스는 작아야 한다! 클래스는 우선적으로 작아야 한다. 함수는 물리적인 행 수로 크기를 측정했지만, 클래스는 맡은 책임(RDD)을 기준으로 한다. 메서드 수가 작더라도 책임이 많읗 수 있다. 클래스 이름이 해당 클래스 책임을 기술해야 하는데, 작명이 간결하지 않다는 것은 보통 크기가 너무 크기 때문이다. ...
책너두 5기 18일차 로버트 C. 마틴의 클린코드 p.161 ~ p.169 내용정리 9. 단위 테스트 깨끗한 코드 도메인에 특화된 테스트 언어 숙련된 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리패터링해야 마땅하다. 이중 표준 테스트 API 코드에 적용하는 표준은 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다. 실제 환경이 아니라 테스트 환경에서 돌아가는 코드이기 때문이다. 임베디드 시스템에선 컴퓨터 자원과 메모리가 제한적일 가능성이 높지만 테스트 환경은 그럴 가능성이 낮다. 이것이 이중 표준의 본질이다. 코드의 깨끗함과는 철저히 무관하다. ...
책너두 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. 형식 맞추기 처음 코드를 봤을 때 깔끔하고 일관적이며 꼼꼼한 코드로 보여야 한다. 그러기 위해선 규칙을 따라야 한다. 형식을 맞추는 목적 분명히 코드 형식은 중요하다. 오늘 구현한 기능이 다음 버전엣 ㅓ바뀔 확률은 아주 높다. 따라서 오늘 작성한 코드의 가독성은 미래에도 영향을 끼친다. 적절한 행 길이를 유지하라 파일의 세로 길이가 조금만 차이나도 실제 파일의 크기는 크게 달라진다. 비교적 적은 줄의 파일로도 커다란 시스템을 구축할 수 있다. 반드시는 아니지만 바람직한 규칙이다. ...