클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 11장. 시스템 "복잡성은 죽음이다. 개발에게서 생기를 앗아가며, 제품을 계획하고 기획하고 제작하고 테스트하기 어렵게 만든다." - 레이오지, 마이크로소프트 최고 기술 책임자 1. 도시를 세운다면? - 한 사람의 힘으로는 무리다. 도시에 큰 그림을 그리는 사람이 있으면 작은 사항에 집중하는 사람들도 있다. - 도시가 돌아가는 이유는 적절한 추상화와 모듈화 때문이다. - 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다. - 소프트웨어도 도시처럼 구성한다. 그러나 막상 팀이 제작하는 시스템은 비슷한 수준으로 추상호를 이뤄내지 못한다. - 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. ..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 10장. 클래스 1. 클래스 체계 - 자바 표준 관례에 따른 순서 - 변수 목록 정적 공개 상수(public static) 정적 비공개(private static) 비공개 인스턴스 변수(private) 공개 변수(public, 공개 변수가 필요한 경우는 거의 없다.) - 공개 함수 공개 함수(public) 비공개 함수(private, 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다.(추상화 단계가 순차적으로 내려간다.)) 1-1. 캡슐화 - 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙은 없다. - 때로는 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. - ..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 9장. 단위 테스트 - 우리들 대다수에게 단위 테스트란 자기 프로그램이 '돌아간다'는 사실만 확인하는 일회성 코드에 불과했다. - 에자일과 TDD 덕택에 단위 테스트를 자동화하는 개발자들이 이미 많아졌으며 점점 더 늘어나는 추세이다. - 테스트를 추가하려고 급하게 서두르는 와중에 제대로 된 테스트 케이스를 작성해야 한다는 더욱 중요한 사실을 놓치고 있다. 1. TDD 법칙 세 가지 - TDD(Test Driven Development) : 테스트 주도 개발(실제 코드를 작성하기 전에 단위 테스트부터 작성하라) 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 8장. 경계 - 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. - 때로는 패키지를 사고, 때로는 오픈 소스를 이용하고, 때로는 사내 다른 팀이 제공하는 컴포넌트를 사용한다. - 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. 1. 외부 코드 사용하기 - 인터페이스 제공자와 사용자 사이에는 특유의 긴장이 존재한다. 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 한다. 반대로, 사용자는 자신의 요구에 집중하는 인터페이스를 요구한다. - 예를 들어, java.util.Map을 확인 할 수 있다. Map 은 굉장히 다양한 인터페이스로 수많은 기능을 제공한다. Map 이 제공하는 기능성과 유연성은 ..

최근에 회사에서 스프링배치를 사용하는 배치업무를 담당하고 있습니다. 간략하게 JobParameter를 수정할 내용이 있었는데 이를 추가할 때마다 모든 배치 소스를 수정해야 하는 불편함을 알게 되었습니다.(아래 적용하려다가 괜히 일이 커지긴 했다...) 해당 글에서는 이 JobParameter 를 조금 더 활용하는 법과 별도의 클래스(Class)로 만들어 공통으로 관리하고 빈(Bean)으로 등록해서 사용하는 것을 포스팅해보려고 합니다. 해당 글에서 사용된 소스는 Git 에서 확인하실 수 있습니다. 1. 기존 방식 - 기존에서는 JobParameter 를 사용하기 위해 아래와 같은 형태로 작성하였습니다. 1-1. 샘플코드 @Slf4j @Configuration @RequiredArgsConstructor p..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 6장. 객체와 자료 구조 - 변수를 Private(비공개)로 정의하는 이유는 남들이 변수에 의존하지 않게 만들고 싶어서이다. - 충동이든 변덕이든, 변수 타입이나 구현을 맘대로 바꾸고 싶어서다. - 대부분 프로그래머들은 조회(get), 설정(set) 함수를 당연하게 Public(공개)으로 공개한다. 1. 자료 추상화 public class Point1 { public double x; public double y; } public class Point2 { double getX(); double getY(); void setCartesian(double x, double y); double getR(); double getTheta(); vo..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 5장. 형식 맞추기 - 프로그래머라면 형식을 깔끔하게 맞춰 코드를 작성해야 한다. - 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 따라야 한다. - 팀으로 일한다면 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. 1. 형식을 맞추는 목적 - "코드 형식은 중요하다!", 너무 중요해서 무시하기 어렵다. - 코드 형식은 의사소통의 일환이며, 의사소통은 전문 개발자의 일차적인 의무이다. - 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지 보수 용이성과 확장성에 계속 영향을 미친다. 2. 적절한 행 길이를 유지하라 - 파일의 길이가 500줄을 ..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 4장. 주석 나쁜 코드에 주석을 달지 마라. 새로 짜라 - 브라이언 W. 커니헨, P.J. 플라우거 - 잘 달린 주석은 유용하지만, 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만든다. - 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼뜨린다. - 코드 자체가 표현력이 풍부하다면 주석은 필요하지 않다. - 즉, 우리는 코드로 의도를 표현하지 못해 실패를 만회하기 위해 주석을 사용하는 것이다. - 주석은 오래될수록 코드에서 멀어진다. 오래될수록 완전히 그릇될 가능성도 있다. - 프로그래머들이 주석을 유지 보수하긴 현실적으로 불가능하다. - 주석을 엄격하게 관리하느니, 코드를 깔끔하게 정리하고 표현력을 강화하는 방향으로 사용해야 한다. 1...

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 3장. 함수 1. 작게 만들어라 - 함수를 만드는 첫째 규칙은 "작게" 이고, 둘째 규칙은 "더 작게" 이다. - 함수가 작을수록 좋다는 증거나 자료를 제시하기는 쉽진 않지만, 짧을수록 각 함수가 명백하고 하나의 동작을 한다는 것은 확실하다. 나쁜 예시 public void lotto() { int[] lottoNumbers = new int[6]; Random random = new Random(); // 랜덤번호 생성 for (int i = 0; i < lottoNumbers.length; i++) { lottoNumbers[i] = random.nextInt(45) + 1; // 중복번호 제거 for(int j = 0; j < i; j+..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 2장. 의미 있는 이름 - 소프트웨어에서 이름은 어디에서나 사용된다. 이름을 잘 지은다면 여러모로 편하다. 1. 의도를 분명히 밝혀라 - 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. - 이름을 주의 깊게 살펴 더 나은 이름으로 개선한다면 코드를 읽는 사람은 조금 더 편하다. - 변수, 함수, 클래스 이름은 다음과 같은 질문에 모두 답해야 한다. 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. 1-1. 변수 나쁜 예시 int a; // 사람 수(단위 : 명) - 위 변수를 살펴보면 실제 의도는 사람 수를 표현하지만 a 라는 변수를 보면 아무 의미도..