본문 바로가기
반응형

독서/클린코드_노개북36

[노개북] 클린코드 25일차 - 노마드 코더 😀 책에서 기억하고 싶은 내용을 써보세요. 켄트 벡이 제시한 단순한 설계 규칙 네 가지(중요도 순) 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 테스트를 철저히 거쳐 모든 테스트 케이스를 통과하는 시스템은 '테스트가 가능한 시스템'이다. TEMPLATE METHOD 패턴은 고차원 중복을 제거할 목적으로 자주 사용하는 기법이다. 자신이 이해하는 코드를 짜기는 쉽다. => 하지만 나중에 유지보수할 사람이 코드를 짜는 사람만큼이나 문제를 깊이 이해할 가능성은 희박하다. 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요. 켄트 벡이 제시한 설계는 결국 지금까지 읽은 클린코드 내용을 지키는 것 테스트 코드의 중요성 => 테스트가 불가능한 시스템.. 2022. 2. 18.
[노개북] 클린코드 24일차 - 노마드 코더 😀 책에서 기억하고 싶은 내용을 써보세요. 순수 자바 AOP 프레임워크 순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 여러 자바 프레임워크는 내부적으로 프록시를 사용한다. * '순수 자바' 란 AspectJ를 사용하지 않는다는 뜻이다. 스프링은 비즈니스 논리를 POJO로 구현한다. POJO는 순수하게 도메인에 초점이 맞춘다. POJO는 엔터프라이즈 프레임워크에 (그리고 다른 도메인에도) 의존하지 않는다. 따라서 테스트가 개념적으로 더 쉽고 간단하다. 상대적으로 단순하기 때문에 사용자 스토리를 올바로 구현하기 쉬우며 미래 스토리에 맞춰 코드를 보수하고 개선하기 편하다. 애플리케이션 도메인 논리를 POJO로 작성할 수 있다면, 즉 코드 수준에서 아키텍처 관심사를 분리할 수 있다면, .. 2022. 2. 17.
[노개북] 클린코드 23일차 - 노마드 코더 😀 책에서 기억하고 싶은 내용을 써보세요. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 시스템 제작과 시스템 사용을 분리하라. 우선 제작(construction)은 사용(use)과 아주 다르다는 사실을 명심한다. 시작 단계는 모든 애플리케이션이 풀어야 할 관심사(concern)다. => 관심사 분리는 우리 분야에서 가장 오래되고 가장 중요한 설계 기법 중 하나다. 의존성 주입(Dependency Injection, DI) 사용과 제작을 분리하는 강력한 메커니즘 하나가 의존성 주입이다. 의존성 주입은 제어 역전(IoC)기법을 의존성 관리에 적용한 메커니즘이다. => 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다. => 새로운 객체는 넘겨받은 책임만 맡으므로 단일.. 2022. 2. 16.
[노개북] 클린코드 22일차 - 노마드 코더 🤢 리팩터링 전 코드 문제 라인 -> 7번째 클린코드 140p. [null을 전달하지마라]를 바탕으로 리팩터링 했습니다. null을 전달하면 NullPointerException이 발생한다. => null 처리를 if문으로 하기는 했지만 Optional로 처리를 하면 더 클린 하게 할 수 있다. 😄 [1차 리팩토링 후] 진리 1. null을 전달하지마라 여전히 코드가 더럽기는 하지만 우선 null을 그냥 넘겨주는 것을 Optional이라는 함수로 처리했습니다. => 만약에 찾는 레스토랑이 null이면 Exception 강제 발생 => 아니라면 찾은 레스토랑의 정보를 바탕으로 다른 Exception 처리 하지만 여기서 28번째 라인을 보면 레스토랑 내 음식 중복검사까지 하는 걸 볼 수 있습니다. => 하나.. 2022. 2. 12.
[노개북] 클린코드 21일차 - 노마드 코더 😀 책에서 기억하고 싶은 내용을 써보세요. 변경하기 쉬운 클래스 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다. OCP(Open-Closed Principle) 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 객체 지향 설계에서 핵심 원칙 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다. 변경으로부터 격리 요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다. 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다. 상세한 구현에 의존하는 코드는 테스트가 어렵다. 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다. 결합.. 2022. 2. 10.
[노개북] 클린코드 20일차 - 노마드 코더 😀 책에서 기억하고 싶은 내용을 써보세요. 클래스는 작아야 한다! 함수는 물리적인 행 수로 크기를 측정했다. 클래스는 다른 척도로 사용한다. 클래스가 맡은 책임을 센다. 클래스 이름은 해당 클래스 책임을 기술해야 한다. 실제로 작명은 클래스 크기를 줄이는 첫 번째 관문이다. 클래스 설명은 만일("if"), 그리고("and"), -(하)며("or"), 하지만("but")을 사용하지 않고서 25 단어 내외로 가능해야 한다. 단일 책임 원칙(Single Responsibility Principle, SRP) 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. SRP는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. => 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다.. 2022. 2. 10.

티스토리툴바