본문 바로가기

분류 전체보기

 (183)
냄새와 휴리스틱 - 자바 J1 : 긴 import 목록을 피하고 와일드카드를 사용하라 패키지에서 클래스 둘 이상을 사용한다면 와일드카드를 이용해서 전체를 가져오라. 이 항목은 Google Style Gudie 의 와일드카드를 사용하지 말라는 항목과 대치된다. 팀에 맞는 컨벤션을 지키면 될 듯 하다. 명시적인 import 문은 해당 클래스가 있어야 하기에 강한 의존성을 만든다. 하지만 와일드카드는 검색 경로에만 추가하는 것이므로 의존성이 낮아진다. J2 : 상수는 상속하지 않는다. 상수를 공통으로 사용하기 위해 인터페이스에 선언하는 것은 좋지 않다. 대신 상수를 모아놓은 클래스를 정의하고, imort static 을 사용하라. J3 : 상수 대 Enum Enum 은 생성자, 메서드, 필드의 기능을 제공한다. 상수보다 훨씬 좋은 기..
냄새와 휴리스틱 - 일반 G1 : 한 소스 파일에 여러 언어를 사용한다. 현실적으로는 힘들긴 하다. 각별한 노력을 기울여 소스파일에서 언어 수와 범위를 최대한 줄여야 한다. G2 : 당연한 동작을 구현하지 않는다 최소 놀람의 원칙에 따라, 함수나 클래스는 다른 프로그래머가 당연하게 여길만한 기능을 제공해야 한다. 요일 문자열을 Enum으로 변환하는 다음 코드를 보자. Day day = DayDate.StringToDay(String dayName); 독자는 StringToDay() 가 Day.MONDAY 로 변환해줄 것을 기대한다. 대소문자는 당연히 구분하지 않을 것이라 기대한다. 이런 당연한 기능을 구현하지 않으면 코드를 읽거나 사용하는 사람이 더 이상 함수 이름만으로 함수 기능을 예상하기 어렵다. G3 : 경계를 올바로 처리..
냄새와 휴리스틱 - 함수 F1 : 너무 많은 인수 함수에서 인수는 적을수록 좋다. 없는 것이 제일 좋다. 넷 이상은 죽기직전까지 피한다. F2 : 출력 인수 출력 인수는 직관적이지 않다. 보통 함수에서 인수는 입력으로 인식된다. 함수에서 뭔가의 상태를 변경해야 한다면, 함수가 속한 객체의 상태를 변경한다. F3 : 플래그 인수 플래그 인수는 함수가 열여러 기능을 수행한다는 증거다. if 분기에 따라 여러 일을 하기 때문. 객체지향 원칙에 어긋난다. F4 : 죽은 함수 아무도 호출하지 않는 함수는 삭제한다. 논리상 필요하다 싶어도 삭제한다. 기억은 소스 코드 관리 시스템이 하니 걱정말자.
냄새와 휴리스틱 - 환경 E1 : 여러 단계로 빌드해야 한다. 빌드는 간단히 한 단계로 끝나야 한다. 빌드를 하기 위해 컴퓨터 여기저기의 JAR, XML 등을 찾아 헤메는 일이 없어야 한다. E2 : 여러 단계로 테스트해야 한다. 모든 단위 테스트는 한 명령으로 돌릴 수 있어야 한다. IDE 에서 버튼 하나로 모든 테스트를 돌릴 수 있는 것이 이상적. 어떤 환경에서라도 한 명령으로 모든 테스트를 돌릴 수 있어야 한다.
냄새와 휴리스틱 - 주석 휴리스틱 : 불충분한 시간이나 정보로 인하여 합리적인 판단을 할 수 없거나, 체계적이면서 합리적인 판단이 굳이 필요하지 않은 상황에서 사람들이 빠르게 사용할 수 있게 보다 용이하게 구성된 간편추론의 방법이다. C1 : 부적절한 정보 소스 코드 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템, 기타 기록관리 시스템에 저장할 정보는 주석으로 넣지 않는다. 작성자, 최종 수정일, SPR 번호 등 메타 정보 이외에는 보통 불필요. 주석은 코드와 설계에 기술적인 설명을 부연하는 수단. C2 : 쓸모없는 주석 오래된 주석, 엉뚱한 주석, 잘못된 주석은 쓸모없다. C3 : 중복된 주석 코드만으로 충분한 내용을 중복해서 설명하는 주석. 서명 (signature) 만 달랑 있는 Javadoc C4 : 성의 없는 주석..
Junit 들여다보기, SerialDate 리펙터링 이 두 단원은 Junit, SerialDate 두 코드를 저자가 리펙토링하는 과정을 담는다. 그 기준은 17장 냄세와 휴라스틱에 나열된 냄새들로 리펙토링을 진행한다. 세세한 내용은 냄새와 휴라스틱 정리에서 같이 작성예정입니다. 보충 공부해야 할 개념 : 추상 팩터리 패턴 데코레이션 패턴 코드 커버리지, 코드 커버리지 도구 Jacoco
점진적인 개선 이번 장에서는 명령행 인수 구문분석기 사례를 가지고 코드를 개선해 나가는 과정을 설명한다. 깨끗한 코드를 짜려면 지저분한 코드를 짠 뒤에 정리해야 한다. 1차 초안 의미전달을 못하는 문자열, HashSet, TreeSet, try-catch-finally 구문 모두 지저분한 코드를 유발한다. Boolean 형을 제공하다가 새로운 인수 유형 Integer, String 을 제공하는 코드를 추가하니 코드가 엄청나게 지저분해졌다. 그래서 이 시점에서 멈추고 리펙토링을 진행했다고 한다. 리펙터링 새로운 인수 유형을 추가하기 위해서는 다음과 같은 부분에서 코드의 변경과 추가가 필요했다. 인수 유형에 해당하는 HashMap을 선택하기 위해 스키마 요소의 구문을 분석한다. 명령행 인수에서 인수 유형을 분석해 진짜 유..
동시성 객체는 처리의 추상화다. 스레드는 일정의 추상화다. 동시성이 필요한 이유 ? 동시성은 무엇과 언제를 분리하여 결합을 없앤다. 응답 시간, 작업 처리량 개선을 위한 동시성이 필요할 수 있다. 동시성의 미신, 오해 동시성은 항상 성능르 높여준다. -> 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유하거나, 여러 스레드가 동시에 처리할 독립적 계산이 충분히 많은 상황에만 높아진다. 동시성을 구현해도 설계는 바뀌지 않는다. -> 무엇과 언제를 분리하므로 판이하게 다르다. 웹, EJB 컨테이너를 사용하면 동시성을 이해하지 않아도 된다. -> 컨테이너가 어떻게 동작하는지 알아야 문제에 대처가 가능하다. 동시성에 대한 타당한 생각 동시성은 다소 부하를 유발한다. 동시성은 복잡하다. 일반적으로 동시성 버그는 재현..

티스토리툴바