You Lead!!

리팩토링은 루빅 큐브 맞추기와 비슷하다. 리팩토링을 하다 보면 코드를 넣었다 뺐다 하는 사례가 아주 흔하다. 좀전에 넣은 예외코드를 다른 로직을 수정하면서 바로 빼 버리기도 한다. 큰 목표 하나를 이루기 위해 자잘한 단계를 수없이 거친다. 각 단계를 거쳐야 다음 단계가 가능하다. https://github.com/seaking7/cleancode-args GitHub - seaking7/cleancode-args Contribute to seaking7/cleancode-args development by creating an account on GitHub. github.com 결론 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다. 나쁜 코드보다 더 오랫동안 더심각하게 개발 프로젝트..

테스트를 위해 외부 연동부분을 Stup이나 Mock으로 대체할 수 있다. public class AddressRetriever { private Http http; public AddressRetriever(Http http) { this.http = http; } public Address retrieve(double latitude, double longitude) throws IOException, ParseException { String parms = String.format("lat=%.6flon=%.6f", latitude, longitude); String response = http.get( "http://open.mapquestapi.com/nominatim/v1/reverse?form..

동시성과 깔끔한 코드는 양립하기 어렵다. 이런 어려움을 대처하고 깨끗한 코드를 작성하는 방법을 알아보자. 동시성이 필요한 이유? 쓰레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 동시성은 무엇과 언제를 분리하는 전략이다. 웹애플리케이션에서 서블릿 모델을 보면, 웹 요청이 올때마다 각 서블릿 스레드가 각각 자신만의 세상에서 돌아감에 따라 많은 구조적 이점을 가진다. 또한, 많은 배치프로그램에서 하나의 쓰레드가 수행할 때보다 많은 일을 동시성을 이용해서 해결하고 있다. 하지만, 동시성은 각별히 주의하지 않으면 난감한 상황에 처하게 되며, 동시성과 관련된 일반적인 미신과 오해가 있다. 1) 동시성은 항상 성능을 높여준다 : 동시성은 때로 성능을 높여준다. 대기시간이 길거나, 독립적인 계산이 충분히 많은..

좋은 테스트의 FIRST 속성 Fast : 테스트가 오래 걸리면 자주 돌리기 어렵다. 느린 로직이 있으면 의존성을 줄여야 한다. 예를 들어, DB처리하는 로직이 포함되어 있으면, 해당 부분을 별도로 떼어내서 따로 테스트를 짜도록 구조개선한다. Isolated : 어떤 순서나 시간에 관계없이 실행할 수 있도록. 하나의 테스트가 여러 이유로 실패할 수 있다면, 독립적으로 분리해 내야 한다. Repeatable : 실행할 때마다 결과가 같아야 한다. 시간값이나 외부 값에 따라 결과가 다르다면 Mock객체 활용 등으로 동일한 결과가 나오도록 구현한다. Self-validating : 출력값을 확인하기보다는 성공/실패가 명확히 나오도록 한다. Timely : 테스트코드를 미루는 것은 양치를 미루는 것과 같다. 큰..

창발성 : 불시에 솟아나는 특성 창발적 설계로 깔끔한 코드를 구현하자. 우수한 설계를 유지하는 단순한 설계 규칙은 아래 네가지로 요약된다. 1. 모든 테스트를 실행하라 테스트가 가능한 시스템을 만들려고 하면, 크기가 작고 목적 하나만 수행하는(SRP) 클래스가 나온다. 결합도가 높으면 테스트 코드를 작성하기 어려워지므로, 테스트 코드를 만들려면 DIP와 같은 원칙을 적용하고, 의존성주입, 인터페이스, 추상화와 같은 도구를 통해 결합도를 낮추게 된다. 테스트 케이스를 만들고 계속 돌리려고 하면 시스템은 낮은 결합도와 높은 응집력을 유지할 수 밖에 없다. 2. 중복을 없애라. 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻한다. 비슷한 코드는 더 비슷하게 고쳐서 별도 메서드 등으로 빼내라. 비슷한 업무..

도시를 설계할때에도 수도관리팀, 전력관리팀, 교통관리팀, 치안관리팀, 건축물관리팀 등 각 분야의 담당자들이 적절한 추상화와 모듈화로 일을 하기 때문에 잘 돌아갈 수 있다. 소프트웨어도 추상화와 관심사 분리를 통해 깨끗한 시스템을 유지해야 한다. 생성(Configuration) 과 사용(애플리케이션, Service) 분리 아래와 같이 서비스 사용부에서 생성까지 책임지는 소스는 아래와 같은 문제가 있다. 1. getService()에서 MyServiceImpl이라는 구체적인 객체에 의존한다. 2. 단위테스트 구현시 MyServiceImpl이 복잡한 로직이라면, Test Double 을 service에 할당해야 하는데 불가능하다. 3. service가 null일 경우와 아닐 경우 등 객체 생성에 대한 테스트도..

로버트C 마틴(Uncle Bob) 클린코드 책의 저자이며, SOLID라는 객체지향의 원칙에 대해 정리 조슈아 블로크 Effective Java 책의 저자이며, Java 주요 API의 개발자 마틴 파울러(https://martinfowler.com/architecture/) 리팩토링 책의 저자 캔트백 TDD(테스트주도개발) 책의 저자. TDD, 익스트림 프로그래밍 등 객체지향 개발의 선구자 에릭감마와 함께 스위스 - 아틀란타 행 비행기 안(1997)에서 JUNIT을 처음 만들었다는 일화가 있다. 에릭 감마 이클립스의 창시자 로드존슨 스프링의 창시자

@ComponentScan 디폴트가 현재 클래스의 하위 패키지 검색하여 의존관계 자동 주입 (stereotype의 annotation 붙어 있는 Bean을 검색) Component 사용시 주의점 기본적으로 스프링의 Component는 싱글톤으로 생성되므로, Stateless하게 설계해야 한다. 즉, 컴포넌트로 들어갈 @Service, @Controller, @Repository 에는 클래스 변수 대신에 쓰레드에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 함. 필드 변수값을 변경해서 사용하면 멀티쓰레드 환경에서 다른 쓰레드 값이 보여질 수 있음. @Autowired 컴포넌트 스캔하면서 자동으로 주입. 생성자가 하나이면 @Autowired 생략가능 테스트시 빈 주입방법1 : A..

클래스 체계 클래스는 public static 변수 → private static 변수 → private 변수 순으로 배치. public 변수가 필요한 경우는 거의 없다. 변수 목록 다음에는 public 함수를 배치하며, private 함수는 자신을 호출하는 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려가서, 신문 기사처럼 읽혀야 한다. 캡슐화 테스트 코드에서 private 변수나 함수에 접근하려고 하면 protected로 선언하는 방법도 있으나, 테스트 코드에서 private 변수나 함수에 접근해야 하는 경우는 별도 클래스로 빼는게 맞다. 클래스는 작아야 한다. 하나의 함수가 하나의 행동만을 해야 했다면, 하나의 클래스는 하나의 책임만을 맡아야 한다. 간결한 클래스 이름이 떠오르지 않는다면 ..

애자일과 TDD덕택에 단위테스트를 자동화하는 프로그래머들이 많아졌으며 점점 늘어나는 추세다. 하지만, 테스트를 추가하려고 급하게 서두르는 와중에 제대로 된 테스트 케이스를 작성해야 한다는 더 중요하고 미묘한 사실을 놓치고 있다. TDD법칙 세 가지 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 실패하는 테스트 추가 → 최소한의 코딩을 통한 테스트 통과 → 테스트 통과를 유지하면서 구조/설계 개선 깨끗한 테스트 코드 유지하기 테스트 코드는 구현에 신경쓰지 않고 조금 지저분해도 빨리 개발하는게 좋다고 생각하..