Cleancode

책너두 5기 27일차 로버트 C. 마틴의 클린코드 p. 237~ p.244 내용정리 13.동시성 스레드 코드 테스트하기 지금까지 공부한 것은 스레드가 하나인 프로그램은 지금까지 한 말이 모두 옳다. 하지만 같은 코드와 같은 자원을 사용하는 스레드가 둘 이상으로 늘어나면 다르다. 권장사항: 문제를 노출하는 테스트 케이스를 작성하라. 프로그램 설정과 시스템 설정과 부하를 바꿔가며 자주 돌려라. 실패하면 원인을 추적하라. 스레드가 둘 이상일 때 지침은 다음과 같다. 말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라. 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자. 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있도록 스레드 코드를 구현하라. 다중 스레드를 쓰는 코드 부분을 상황에 맞춰 조정할 수 있게 작성하라. 프로세서 수보다 많은 스레드를 돌려보라. 다른 플랫폼에서 돌려보라. 코드에 보조 코드(instrument)를 넣어 돌려라. 강제로 실패를 일으키게 해보라. 말이 안되는 실패는 잠정적인 스레드 문제로 취급하라 다중 스레드 코드는 아주 드물게 한번씩 나타나서 실패를 재현하기 아주 어렵고 그로 인해 일회성 문제로 치부한다. 그렇게 되면 잘못된 코드위에 코드가 계속 쌓인다. ...

책너두 5기 26일차 로버트 C. 마틴의 클린코드 p. 230~ p.237 내용정리 13.동시성 난관 동시성을 구현하기 어려운 이유? 예시 1 2 3 4 5 6 7 public class X { private int lastIdUsed; public int getNextId() { return ++lastIdUsed; } } 인스턴스 X를 생성하고, lastIdUsed 필드를 42로 설정한 다음, 두 스레드가 해당 인스턴스를 공유한다. 두 스레드가 getNextId();를 호출한다고 가정헀을때 결과는? ...

책너두 5기 25일차 로버트 C. 마틴의 클린코드 p. 226~ p.229 내용 정리 13. 동시성 동시성과 깔끔한 코드는 양립하기 어렵다. 동시성이 필요한 이유? 동시성은 결합(coupling)을 없애는 전략이다. **무엇(what)**과 **언제(when)**을 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 밀접하다. **무엇(what)**과 **언제(when)**를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 따라서 시스템을 이해하기 쉽고 문제를 분리하기도 쉽다. 예시: 서블릿(Servlet) 서블릿은 웹 혹은 EJB 컨테이너 아래서 돌아가는데 컨테이너는 동시성을 부분적으로 관리한다. 웹 요청이 들어올 때마다 웹 서버는 비동기식으로 서블릿을 실행한다. 원칙적으로 각 서블릿 스레드는 다른 서블릿 스레드와 무관하게 자신만의 세상에서 돌아간다. 서블릿 프로그래머는 동시성을 정확히 구현하도록 각별한 주의와 노력을 기울여야 한다. 그럼에도 서블릿 모델이 제공하는 구조적 이점은 아주 크다. ...

책너두 5기 24일차 로버트 C. 마틴의 클린코드 p. 216~ p.223 내용 정리 12. 창발성 창발적 설계로 깔끔한 코드를 구현하자 켄트 백이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다. 다음은 중요도 순이다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 테스트가 불가능한 시스템은 검증도 불가능하고, 출시되어선 안된다. 테스트 케이스가 많을수록 개발자는 테스트가 쉽게 코드를 작성한다. 따라서 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어진다. ...

책너두 5기 23일차 로버트 C. 마틴의 클린코드 p. 206 ~ p.215 내용 정리 11. 시스템 순수 자바 AOP 프레임워크 순수자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 여러 자바 프레임워크는 내부적으로 프록시를 사용한다. 스프링은 비즈니스 논리를 POJO(Plain Old Java Object)로 구현한다. POJO는 도메인에 초점을 맞춰서 테스트가 쉽고 간단하며, 상대적으로 단순하기 때문에 사용자 스토리를 올바로 구현하기 쉽고 미래 스토리에 맞춰 코드를 보수하고 개선하기 편하다. AspectJ 관점 관심사를 관점으로 분리하는 가장 강력한 도구는 AspectJ 언어이다. 이것은 언어 차원에서 과넞ㅁ을 모듈화 구성으로 지원하는 자바 언어 확장이다. 관점을 분리하기 좋지만 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야 하는 단점이 있다. 하지만 ‘애너테이션 폼’은 이 부담을 어느정도 완화한다. ...

책너두 5기 22일차 로버트 C. 마틴의 클린코드 p.198 ~ p.205 내용 정리 11. 시스템 시스템 제작과 시스템 사용을 분리하라 Main 분리 시스템 생성과 시스템 사용을 분리하는 방법 중 하나는, 생성과 관련한 코드는 모두 main이나 main이 호출하는ㄴ 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정하는 것이다. 팩토리 때로는 객체가 생성되는 시점을 애플리케이션이 결정할 필요도 생긴다. 의존성 주입 의존성 주입(Dependency Injection)은 제어 역전(Inversion of Control, IoC) 기법을 의존성 관리에 적용한 메커니즘이다. 제어 역전에서는 한 객체가 맡은 보조 책임을 새로운 객체에레 전적으로 떠넘긴다. 새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임의 원칙을 지키게 된다. 초기 설정은 시스템전체에서 필요하므로 대개 ‘책임질’ 메커니즘으로 ‘main’ 루틴이나 특수 컨테이너를 사용한다. ...

책너두 5기 21일차 로버트 C. 마틴의 클린코드 p.189 ~ p.197 내용 정리 10. 클래스 변경하기 쉬운 클래스 변경으로부터 격리 객체 지향 프로그래밍에는 구체적인(concrete) 클래스와 추상(abstract) 클래스가 있다. 상세한 구현(코드)을 포함하는 것과 개념만 포함하는 것의 차이이다. 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험하므로 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다. 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다. 이는 각 시스템 요소가 다른 요소로부터, 변경으로부터 잘 격리되어 있다는 의미다. 11. 시스템 도시를 세운다면? 도시에는 큰 그림을 그리는 사람들도 있으며 작은 사항에 집중하는 사람들도 있다. 한 사람의 힘으로는 직접 관리할 수 없다. 도시가 돌아가는 이유는 적절한 추상화와 모듈화 때문이다. 시스템도 마찬가지다. ...

책너두 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 코드에 적용하는 표준은 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다. 실제 환경이 아니라 테스트 환경에서 돌아가는 코드이기 때문이다. 임베디드 시스템에선 컴퓨터 자원과 메모리가 제한적일 가능성이 높지만 테스트 환경은 그럴 가능성이 낮다. 이것이 이중 표준의 본질이다. 코드의 깨끗함과는 철저히 무관하다. ...