Clean code (8) 썸네일형 리스트형 Clean Code - 13장. 동시성 개요 객체는 처리의 추상화다. 스레드는 일정의 추상화다. -제임스 O.코플리엔 동시성과 깔끔한 코드는 양립하기 어렵다. 다중 스레드 테스트해보기도 어렵다. 이 2가지 어려움을 해당 단원을 읽으면서 헤쳐나갈 수 있었다! 동시성이 필요한 이유 동시성은 Coupling을 없애는 전략이다. 동시성은 무엇(what)과 언제(when)을 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로밀접하다. 무엇,언제를 분리하면 애플리케이션 구조와 효율이 극적으로 좋아진다. 응답 시간과 작업 처리량 개선에도 도움이 된다. 데이터를 대량으로 분석하는 시스템에서 병렬로 처리 구조 개선의 좋은 예는 Servlet 모델일 것이다. 이론적으로, Servlet 개발자는 요청을 개별적으로 처리하는 데에만 신경을 쓰며 요청 .. Clean Code 3장 - 함수 클린 코드 책을 읽으면서 해당 단원이 가장 쉬운 부분 같지만 잘 지키지 않고, 그리고 지키면 가장 효과가 가장 크다 생각한다. 아래 함수를 보면 이해가 잘 되는가? 해당 함수를 깨끗하게 만들어보자. public static String renderPageWithSetupsAndTeardowns( PageData pageData, boolean isSuite) throws Exception { boolean isTestPage = pageData.hasAttribute("Test"); if (isTestPage) { WikiPage testPage = pageData.getWikiPage(); StringBuffer newPageContent = new StringBuffer(); includeSetupP.. Clean Code 4장 - 주석 개발을 하다보면 보통 주석을 잘 달지 않아, 주석 좀 많이 달아라는 얘기를 많이 들었을 것이다. 그러면 주석이 많으면 많을수록 좋은걸까? 아니다! 중요한 주석이 있지만, 자신의 나쁜 코드를 숨기기 위해서 주석을 사용하는 경우도 있다. 오히려 주석을 많이 달았다면 자신이 코드로 모든 걸 표현하지 못했다고 반성해야 한다! 예시를 살펴보자 // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다. if ((employee.flags & HOURLY_FLAG) && (employee.age > 65)) ... if (employee.isEligibleForFullBenefits()) ... 위와 같이 대부분 함수로 표현할 수 있다. 좋은 주석 1. 정보를 제공하는 주석 // 테스트 중인 Responder 인스턴스.. Clean Code 5장 - 형식 맞추기 자바 코딩을 하면서 여러가지 패턴을 적용하고, 인터페이스를 이용하는 등 멋지게 하고 싶어한다. 하지만, 그 전에 가장 기초적인게 코드의 형식을 맞추는 것이라 생각한다. IDE에서 Formatter 를 적용해 놓으면 팀내 들여쓰기 등 형식은 맞출 수 있다. 하지만 클래스의 세로 길이, 메소드의 세로 길이는 어느 정도가 적합할까? 내가 만드는 기능이 복잡해서 클래스가 크다고? JUnit과 같은 큰 프로젝트도 대부분 200줄 정도의 파일로 구성되어 있다. 즉, 방금과 같은 변명은 핑계이다. 신문 기사처럼 작성하라 아주 좋은 신문 기사를 떠올려보라 . 독자는 위에서 아래로 기사를 읽음 첫 문단은 요약된 내용이다. 세세한 내용은 밑에서 나온다. -> 소스 파일 첫부분은 고차원 개념 기사는 짧다 개념은 빈행으로 분.. 리팩토링 - 12장. 복합 리팩토링 ( 절차코드를 객체로 전환 ) 코드 리뷰를 요즘 적극적으로 진행하면서 리팩토링 공부에 대한 필요성을 느꼈다. 팀원들이 가끔 너무 바빠서 리팩토링 할 시간이 없다고 하는데, 마틴 말대로 리팩토링은 기능을 추가하거나 버그를 수정하면서 조금씩 해야 된다고 생각한다. 복합 리팩토링 파트는 함수명 재정의처럼 금방 되는건 아니지만, 아래와 같은 이유로 해당 리팩토링은 꼭 필요하다. 충분히 이해하지 못한 상태에서 설계를 결정하는 일이 누적되면 막 자란 물풀로 막힌 운하처럼 프로그램이 막혀버린다. - 마틴 파울러 절차 코드를 객체로 전환 ( Convert Procedural Design to Objects ) 코드가 절차식으로 작성되어 있을 땐, 데이터 레코드를 객체로 바꾸고, 기능을 쪼개서 각각의 객체로 옮기자. // Before - 절차지향적인.. Clean Code 9장 - 단위테스트 Clean Code - 단위테스트실제 코드를 작성하기 전에 단위 테스트를 작성하라첫번째 법칙 : 실패하는 단위 테스트를 작성하기 전에 실제 코드를 작성하지 않는다.두번째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다.세번째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 코드를 작성한다. 위의 법칙대로 작성을 하면 테스트 코드와 실제 코드가 빠른 주기로 묶인다. 이렇게 되면, 실제 코드와 맞먹는 정도의 방대한 테스트 코드가 나와 심각한 관리 문제가 생긴다. 깨끗한 테스트 코드 유지하기테스트 코드는 메인 코드와 다르게 대충 짜도 된다는 의식을 많이 가지고 있다. 테스트 코드를 대충 짜면 어떠한 문제가 생길까?메인 코드 버전업 -> 테스트 실패테스트 코드를 수정해야 하지만.. Clean Code 12장 - 우수한 설계를 위한 규칙(창발성) 우수한 설계를 위한 규칙켄트 백이 제시한 다음 규칙을 따르면 설계는 '단순하다'고 우리는 믿고 있다. 모든 테스트를 실행한다.중복을 없앤다.프로그래머의 의도를 표현한다.클래스와 메소드 수를 최소로 줄인다.이 순서는 중요도 순이다! 하나하나씩 살펴보자~우수한 설계를 위한 규칙 1 - 모든 테스트를 실행한다.모든 테스트를 실행한다가 왜 우수한 설계를 위한 규칙일까? 모든 테스트 케이스를 만들려면 결합도가 높아서는 안된다. 한 클래스 함수에서 하나 이상의 책임을 가지고 있으면 테스트 케이스를 만들기 어려워진다. 그러면 자연스럽게 단일 책임 원칙을 지키게 된다. 또한, 다른 클래스와 결합도가 높으면 테스트가 힘들어지기 때문에 자연스럽게 의존성 주입을 사용하게 된다. 결국, 테스트 케이스를 모두 실행 시키다보면 .. Clean Code - 10장. 클래스 클래스 이름은 클래스의 책임을 기술해야 한다. 만약, 클래스 이름을 짓기가 애매하다면 내가 클래스에 너무나도 많은 기능을 넣고 있다는 것이다. EX : Manager, Processor등과 같이 모호한 단어가 좋지 않은 예이다. 클래스 메서드가 클래스 인스턴스 변수를 더 많이 사용하도록 짜라. 단지, 인스턴스 변수가 많아야 한다는 소리가 아니다. 모든 인스턴스 변수를 각 클래스 메소드마다 쓰면 좋다. => 결국 이게 응집도가 높다는 말이다. 응집도를 높이려면 어떻게 해야할까?변수가 아주 많은 큰함수를 찾아보자. 큰함수를 작은함수 단위로 쪼개보자. 그러다보면, 빼내려는 작은함수에서 변수 넷을 사용해야 한다. 인수만 많아지고 더러워지자나... 인수 X, 클래스 인스턴스 변수 O 여기까지만 보면 응집도가 낮아.. 이전 1 다음