본문 바로가기

클린코드

클린 코드 - 부록 A 동시성 2 본 챕터에서는 동시성을 좀 더 자세히 설명하고 보완한다. 클라이언트/서버 예제 서버와 클라이언트의 단순한 소켓 프로그래밍 코드를 책에서는 보여주고 있다. 또한, 해당 테스트가 10초 내에 처리가 되는지를 확인하는 테스트코드를 구현하였다. 만약 테스트가 실패한다면? 이벤트 폴링 루프를 구현하면 모를까, 단일 스레드 환경에서 속도를 끌어올릴 방법은 거의 없다. 다중 스레드를 사용하면 성능이 높아질까? 그럴지도 모르지만, 먼저 애플리케이션이 어디서 시간을 보내는지 알아야 한다. 가능성은 크게 아래의 2가지다. I/O - 소켓 사용, 데이터베이스 연결, 가상 메모리 스와핑 기다리기 등에 시간을 보낸다. 프로세서 - 수치 계산, 정규 표현식 처리, 가비지 컬렉션 등에 시간을 보낸다. 대게 시스템은 둘 다 하느라 .. 더보기
클린 코드 13장 - 동시성 객체는 처리의 추상화다. 스레드는 일정의 추상화다. 동시성과 깔끔한 코드는 양립하기 어렵다. 아주 어렵다. 스레드를 하나만 실행하는 코드는 짜기가 쉽다. 겉으로 보기에는 멀쩡하나 깊숙한 곳에 문제가 있는 다중 스레드 코드도 짜기 쉽다. 이런 코드는 시스템이 부하를 받기 전까지 멀쩡하게 돌아간다. 이 장에서는 여러 스레드를 동시에 돌리는 이유를 논하고, 여러 스레드를 동시에 돌리는 어려움도 논한다. 이런 어려움에 대처하고 깨끗한 코드를 작성하는 방법도 몇 가지 제안한다. 마지막으로, 동시성을 테스트하는 방법과 문제점을 논한다. 좀 더 자세한 내용은 부록A의 동시성2에서 다룬다. 꼭 읽어보라. 동시성이 필요한 이유? 동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 스레드가 하나인 프.. 더보기
클린코드 12장 - 창발성 창발성이란? - 하위 체계로부터 생겨나지만, 그 하위 체계로 환원되지 않는 속성을 말한다. - 네이버 지식백과 - 이전에는 보이지 않았던 것이 어느 순간에 갑작스럽게 나타나는 것 창발적 설계로 깔끔한 코드를 구현하자 착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 네 가지가 있다면? 그래서 SRP나 DIP와 같은 원칙을 적용하기 쉬워진다면? 네 가지 규칙이 우수한 설계의 창발성을 촉진한다면? 우리들 대다수는 켄트 벡이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위 목록은 중요도 순이다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 설계는 의도한 대.. 더보기
클린코드 11장 - 시스템 "복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다." 도시를 세운다면? 이미 세워진 도시라도 한 사람의 힘으로는 관리할 수 없다. 그럼에도 불구하고 도시는 잘 돌아간다. 각 분야를 관리하는 팀이 있기 때문이다. 또한, 적절한 추상화와 모듈화가 이루어져있다. 그래서 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 '구성요소'는 효율적으로 돌아간다. 그런데 막상 팀이 제작하는 시스템은 비슷한 수준으로 관심사를 분리하거나 추상화를 이뤄내지 못한다. 이 장에서는 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다. 시스템 제작과 시스템 사용을 분리하라 제작과 사용은 아주 다르다는 사실을 명심한다. 소프트웨어 시스템은 (애플리케이션 .. 더보기
클린코드 10장 - 클래스 ( 가장 감명깊었던 10장.. ) 지금까지는 코드 행과 코드 블록을 올바로 작성하는 방법에 초점을 맞췄다. 함수를 올바로 구현하는 방법과 함수가 서로 관련을 맺는 방식도 공부했다. 하지만 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 이 장에서는 깨끗한 클래스를 다룬다. 클래스 체계 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다. 정적 공개 상수가 있다면 맨 처음에 나온다. 다음으로 정적 비공개 변수가 나오며, 이어서 비공개 인스턴스 변수가 나온다. 공개 변수가 필요한 경우는 거의 없다. 변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내.. 더보기
클린코드 9장 - 단위 테스트 1997년만 해도 TDD(test driven development)라는 개념을 아무도 몰랐다. 우리들 대다수에게 단위 테스트란 자기 프로그램이 '돌아간다'는 사실만 확인하는 일회성 코드에 불과했다. 돌아간다는 사실을 확인하고 동료들에게도 보여줬다. 그리고 나서는 테스트 코드를 버렸다. 애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 더 늘어나는 추세다. 하지만, 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한 ( 그리고 더욱 중요한 ) 사실을 놓쳐버렸다. TDD 법칙 세 가지 TDD가 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다는 사실을 모르는 사람은 없으리라. 하지만 이 규칙은 빙산의.. 더보기
클린 코드 8장 - 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴본다. 외부 코드 사용하기 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다. 반면, 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 이런 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 많다. 책의 예시처럼, 프로그램에서 Map 인스턴스를 여기저기로 넘긴다면, Map 인터페이스가 변할 경우, 수정할 코드가 상당히 많아진다. 자바5가 제네릭스를 지원하면서 Map 인터페이스가 변했다는 사실을 명심해야 한다. 실제로 제네릭스 사용을 금지하는 시스템도 보았다. 기존 시스템에서 Map을 너.. 더보기
클린 코드 7장 - 오류 처리 오류 처리는 프로그램에 반드시 필요한 요소 중 하나일 뿐이다. 뭔가 잘못될 가능성은 늘 존재한다. 뭔가 잘못되면 바로 잡을 책임은 바로 우리 프로그래머에게 있다. 오류 처리는 중요하다. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. 우아하고 고상하게 오류를 처리하는 기법과 고려 사항 몇 가지를 소개한다. 오류 코드보다 예외를 사용하라 예외를 지원하지 않는 언어는 오류를 처리하고 보고하는 방법이 제한적이었다. 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법이 전부였다. 이러한 방법은 호출자 코드가 복잡해진다. 함수를 호출한 즉시 오류를 확인해야 하기 때문이다. 잊어버리기 쉽다. 그래서 오류가 발생하면 예외를 던지는 편이 낫다. 개념(로직)과.. 더보기

티스토리툴바