kdh93

창발적 설계로 깔끔한 코드를 구현하자 몇가지 설계 규칙으로 우수한 설계를 이끌어내자 켄트 백이 제시한 단순한 설계 규칙 4가지를 소개하고있다. 1. 모든 테스트를 실행하라 다양한 테스트 코드를 작성하는 시스템을 만드려 애쓰면 설계 품질이 높아진다. 개발자는 테스트 코드를 많이 작성하고 쉽게 테스트를 진행하려하기에 SRP , DIP와 같은 원칙을 지키려 추상화, 인터페이스, 의존성 주입등의 기술을 사용해 결합도를 낮춘다. 이에따라 자연스럽게 테스트 코드를 많이 작성하려 노력할수록 프로덕션코드의 설계 품질또한 같이 높아진다. 2. 리팩토링 테스트 케이스를 작성후 안전하게 코드와 클래스를 정리할 수 있다. ( 테스트라는 안전망이 존재하기때문에 ) 리팩토링 단계에서는 응집도를 높이고, 결합도를 낮추고, 관심사를..

클래스 체계 public static 변수 private static 변수 private instance 변수 ( 저자는 public instance 변수는 거의 필요가 없다고함..) public method private method ( 주로 자신을 호출하는 함수 직후에 자리하는게 좋다고함 이렇게 클래스는 추상화 단계가 순차적으로 내려가기때문에 프로그램이 신문기사 처럼 읽힌다고.. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는편이 낫지만 반드시 숨겨야하는 법칙도 없다고함. protected 로 접근을 제어해 테스트 코드에 접근을 허용하기도함 클래스는 작아야한다. 저자는 클래스의 크기가 함수와 마찬가지로 작아야된다고 강하게 주장함. 그렇다면 얼마나 작아야하는가? 예시로 70개의 메서드를 가지고있는 ..

8장은 외부 패키지, 라이브러리, 오픈 소스등으로 사용되는 외부코드에 관한 글이다. 경계살피고 익히기 외부에서 온 코드를 다루는 방법은 어렵다. 사용할 때 라이브러리가 예상대로 동작하는지, 라이브러리코드의 문제인지 나의 코드 문제인지 파악하기가 힘들다. 그렇기때문에 외부 코드 작성전 학습테스트를 진행하는것이 좋다. 통제된 테스트 환경에서 외부 코드를 테스트해 API를 제대로 이해했는지를 확인하는 것. 학습테스트에는 비용이 없다. 투자 대비 얻는 성과가 더 큼. 아직 존재하지 않는 코드를 사용하기 협업 과정중 다른팀이 아직 우리가 필요한 API를 완성하지 못했을때의 이야기 구현을 미루고 인터페이스를 정의 -> 우리가 작성하려는 코드의 의도가 분명해진다. 인터페이스 정의 후 다른팀의 API가 완성되었을때 인..

깨끗한 코드와 오류처리의 연관성 -> 여기저기 흩어진 오류 처리 코드때문에 실제 코드가 하는일을 파악하기가 어려워진다. 오류 코드보다 예외를 사용하라 if else문으로 코드의 오류를 처리하기보다는 try catch문을 사용해 코드와 오류 처리코드가 섞이지 않게 하자. Unchecked Exception을 사용하라 checkedException은 OCP를 위반한다, (하위단계에서 코드를 변경하면 예외를 선언한 상위단계 메서드 선언부를 전보 고쳐야하기 때문) 또한 ChekedException은 Throws로 인해 의존관계측면에서 단점이 존재함. (다른 계층에서 Catch하지못한 예외를 다른 계층으로 넘겨버린다. ex) Persistance Layer의 예외를 Business Layer까지 Throw해 Bu..

변수를 private으로 하는 이유 다른 사람들이 변수에 의존하지 않게 만들기위해 최초 개발의도에 맞지않게 변수가 다른 개발자에의해 수정될 수 있다. 그렇다면 왜 getter와 setter는 public으로 공개해 외부에 노출하는걸까? → 내부 구조를 노출하지않고, 함수를 통해 객체를 다루기위함 디미터의 법칙 모듈은 자신이 조작하는 객체의 내부 구조를 몰라야한다. “Class C의 Method F는 다음과 같은 객체의 메서드만 호출해야한다.” 클래스 C F가 생성한 객체 F 인수로 넘어온 객체 C 인스턴스 변수에 저장된 객체 쉽게말한 친구들은 가까이하고 낯선이는 경계하자는 이야기. 기차 충돌 final String outputDir = ctxt.getOption().getScratchDir().getAb..

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야한다. 형식을 맞추는 목적 코드 형식은 너무나도 중요하지만 또 너무 맹목적으로 따르면 안된다. 코드의 형식은 의사소통 의 일환. 의사소통 은 개발자의 1차적인 의무 적절한 행 길이를 유지하라 Junit , Tomcat 등… 대부분의 프로그램의 Java 파일의 평균 길이(행) 은 65줄이다. 하나의 클래스에 500줄…400줄이 넘지않아도 규모가 큰 프로그램을 작성할 수 있다. 신문기사처럼 작성하라 이름은 간단하면서도 설명이 가능하게 짓자. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명하고 아래로 내려갈수록 모듈의 의도를 자세하게 설명하자. 마지막에는 가장 저차원적인 함수와 세부 내역..

‘나쁜 코드에 주석을 달지 마라, 새로 짜라’ 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼트린다. 애초에 주석이 존재하는것 자체가 코드의 품질이 나쁘고 복잡하다. //직원에게 복지 혜택을 받을 자격이 있는지 검사한다. if((employee.flags & HOURLY_FLAG) && (employee.age > 65)){ //TODO } 이 코드보다, if(employee.isEligibleForFullBenenfits()){ //TODO } 주석이 없는 두번째 코드가 더 의도를 파악하기 쉽다. 좋은주석 나쁜주석을 떠나 결국…. 주석은 확실히 코드만으로 의도를 설명하기 어려운 경우 에만 사용하자. 좋은주석 법적인 주석 저작권 정보와 소유권정보 정보를 제공하는 주석 데이터 포맷 형식 시각과 날짜 등등…..

함수는 작게 만들자 블록과 들여 쓰기 if문, else문, while문 등이 들어가는 블럭은 한 줄이어야 한다. 함수안에서 여러가지 작은함수들을 호출한다면 호출된 함수명들을 통해 함수를 이해하기 쉬워진다. 중첩 구조가 생길만큼 함수가 커져서는 안된다. 한가지만 하자 한 가지 목적을 잘 처리하는 함수를 만들자 여러 목적을 가진 함수를 읽는것은 그 함수의 의도를 파악하기 어려워진다. 함수가 한가지 로직만 처리하는지 알 수 있는 방법 함수 코드중 어떠한 의미있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 함수다. 서술적인 이름을 사용하자 함수가 맡은 일을 잘 표현하는 이름을 사용하자 이름만 읽고도 그 함수가 어떤 기능을 수행하는지 짐작할 수 있는 이름을 짓자 이름이 길어도 괜찮다. 겁..

깨끗한 코드란? 중복을 피한 코드 한 기능만을 수행하는 코드 명확하게 표현하는 코드 작게 추상화한 코드 짐작했던 기능이 그대로 수행되는 코드 의미 있는 이름 의도한 분명한 이름을 짓자. 수행기능, 사용방법 등… 만약 주석이 필요하다면 이름만으로 의도를 드러내지 못했다는 것. 예약어를 사용하지말자 ex) 여러 계정을 그룹으로 묶을때, accountList → 프로그래머에게 List는 자료구조를 의미하는 특수한 의미 accountGroup, bunchOfAccount, Accounts 등으로 명명하자. 실제 해당 자료구조 컨테이너가 List더라도 변수 이름에 List는 피하자. 서로 흡사한 이름을 사용하지 말자. 읽기에 명확한 단어로 적기 Bad ex) int a = l; if( O == l) a = o1;..