클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다. 14장. 점진적인 개선1. 점진적인 개선의 중요성지속적 개선- 소프트웨어는 한 번에 완벽해질 수 없다.- 꾸준한 점진적 개선이 필요하다.- 작은 변경을 자주 적용하는 방식이 대규모 변경을 한 번에 적용하는 것보다 효과적이다.유지보수성 향상- 코드는 시간이 지남에 따라 변경되고 개선되어야 유지보수성이 높아진다.- 점진적인 개선은 코드를 최신 상태로 유지하는 데 중요하다.2. 개선 방법2-1. 리팩토링정의- 리팩토링은 소프트웨어의 기능을 변경하지 않으면서 코드를 재구성하는 것을 의미한다.목표- 코드를 더 읽기 쉽고 이해하기 쉽게 만들며, 중복을 제거하고, 구조를 개선한다.방법- 작은 단위로 점진적으로 리팩토링한다.- 하나의 작업을 끝내고 테스트를..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다.13장. 동시성1. 동시성이 필요한 이유?- 동시성은 결합을 없애는 전략이다.(= 무엇(what)과 언제(when)를 분리하는 전략)- 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접한데 이로 인해 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다.응답 시간 단축: 동시성은 시스템의 응답 시간을 줄여 사용자 경험을 향상시키는 데 중요한 역할을 한다.자원 활용 극대화: 프로세서와 같은 시스템 자원을 효율적으로 활용할 수 있게 한다.설계 단순화: 큰 문제를 작은 문제로 나누어 병렬로 처리할 수 있다.2. 난관// Code 1-1public class X { private int lastIdUsed; public int getNext..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다.7장. 오류처리1. 오류 코드보다 예외를 사용하라- 오류 코드를 반환하는 방식보다 예외를 사용하는 것이 더 바람직하다.- 오류 코드는 코드의 흐름을 복잡하게 만들고, 정상 코드와 오류 처리 코드를 섞어 놓는다.- 반면에 예외는 오류 처리 코드와 정상 코드를 명확히 구분해준다.// Bad Example - 오류 코드를 사용하는 경우public int divide(int a, int b) { if (b == 0) { return -1; // 오류 코드 } return a / b;}// Good Example - 예외를 사용하는 경우public int divide(int a, int b) { if (b == 0) {..

클린코드(CleanCode)를 읽고 간략하게 정리한 글입니다.12장. 창발성1. 단순한 설계 규칙 1-1. 모든 테스트를 실행하라- 테스트가 불가능한 시스템은 검증도 불가능하다.- 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다.- SRP 를 준수하는 클래스는 테스트가 훨씬 더 쉽고 이런 테스트 케이스가 많을수록 쉽게 코드를 작성할 수 있다.- 테스트 케이스를 작성하면 설계 품질이 높아진다.1-2~4 : 리팩토링- 테스트 케이스를 모두 작성했다면 코드를 점진적으로 리팩터링 해나간다.- 코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있으니까!- 리팩터링 단계에서 소프트웨어 설계 품질을 높이는 기법이라면 무엇이든 적용해도 좋다.응집도를 높이기결합도를 낮추기관심사..

클린코드(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 이 제공하는 기능성과 유연성은 ..

클린코드(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줄을 ..