개발자의 공부 이야기 개발자의 공부 이야기

TDD(Test Driven Development)란? 테스트-주도 개발의 기본 흐름은 실패하는 테스트를 작성하고, 테스트를 통과하는 가장 간단한 코드를 작성한 후, 리팩터링을 통해 중복을 제거하는 것이다. 테스트-주도 개발은 객체가 이미 존재한다고 가정하고 객체에게 어떤 메시지를 전송할 것인지에 관해 먼저 생각하라고 충고한다. 그러나 이 같은 종류의 충고는 역할, 책임, 협력의 관점에서 객체를 바라보지 않을 경우 무의미하다. 테스트-주도 개발은 테스트를 작성하는 것이 아니라 책임을 수행할 객체 또는 클라이언트가 기대하는 객체의 역할이 메시지를 수신할 때 어떤 결과를 반환하고 그 과정에서 어떤 객체와 협력할 것인지에 대한 기대를 코드의 형태로 작성하는 것이다. 테스트를 작성하기 위해 객체의 메서드를 호출..

디미터의 법칙은? 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다. 객체는 자료를 숨기고 함수만 공개한다. 객체는 조회함수로 내부구조를 공개하면 안된다. 위의 말이 한마디로 말하면 '메소드만 호출만 하면 내가 원하는 기능을 해줘'다. 즉 하나의 기능에 해당되는 객체에 모든 권한을 주고, 실행만 하는 것이다. 디미터의 법칙을 지키게된다면 많은 이점이 있는데 현재 내가 생각하는 장점은 아래와 같다.(2020-12-11일 기준) 한 곳만 수정을 하게 되면 다른 곳을 수정할 필요가 없다. 객체 지향 5대원칙 중 단일책임 원칙 준수 가능 단일책임원칙 : 클래스나 메소드는 하나의 책임만 가져야 한다. 위의 내용을 바탕으로 코드로 설명을 하겠다. 코드 디미터의 법칙 적용 전 Typhoon public class ..

github.com/rlawls1991/java-ladder 위의 코드를 보게 된다면 내가 아래의 규칙을 최대한 지키면서 개발을 하였다. 코드를 보고 싶으면 현 시간 기준(2020-12-02-11:15)으로 step2를 보면 된다. 실행 결과 함수(메소드) 1. 작게 만들어라 함수를 만드는 첫째규칙은 '작게'다. 함수를 만드는 둘째 규칙은 '더 작게'다. 2. 한 가지만 해라 함수는 한가지를 해야한다. 그 한가지를 잘 해야 한다. 그 한가지만 해야한다. 3. 함수 당 추상화 수준은 하나로 함수가 확실히 '한가지' 작업만 하려만 함수 내 모든 문장이 동일한 추상화 수준에 있어야 한다. 코드는 위에서 아래로 이야기처럼 일해야 좋다. 4. side effect를 만들지 마라. side effect는 실행 중에..

좋은 이름을 갖는 방법 1. 이름으로 해당 코드가 어떤 기능을 하는지 알 수 있게 하자 전 회사에 다니면서 혼자 한 부분을 담당하는 개발이 많다보니 이름에 대해 많은 생각을 하지 못했다. 캐멀 표기법(Camel Notation : Camel Case : 낙타 표기법) 은 지켰지만 많은 부분에서 지키지 못하였다. 아래는 내가 만든 메소드명이다.(생각난 것만 작성..) 예) public interface Disaster{ int rain(); int calculate(); } 위 인터페이스를 보게된다면 재난이란 클래래스에 rain이란 메소드가 있고, 계산하는 메소드가 있다는 것을 알 수가 있다. 그렇다면 비로인해 어떤 재난이 발생했고, 어떤 계산을 하는지 알 수가 없다. 메소드명이나 클래스명이 명확하지 않다..

github.com/rlawls1991 위 주소는 박재성 - TDD 수업을 들으면서 진행되는 코드들의 저장소이다. 박재성 - TDD, Clean Code with Java 10기 참고문서 - CleanCode 책

규칙 1: 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다. 규칙 2: else 예약어를 쓰지 않는다. 규칙 3: 모든 원시값과 문자열을 포장한다. 규칙 4: 한 줄에 점을 하나만 찍는다. 규칙 5: 줄여쓰지 않는다(축약 금지). 규칙 6: 모든 엔티티를 작게 유지한다. 규칙 7: 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다. 규칙 8: 일급 콜렉션을 쓴다. 규칙 9: 게터/세터/프로퍼티를 쓰지 않는다

9월 말 회사를 퇴사하고, 이직 준비를 하고 있었다.(현 시간 기준 스타트업에 있음) 많은 회사에서 면접을 보게 되었는데 공통적으로 이야기 하는 것이 코드리뷰였다. 코드리뷰를 한 적이 없는 나는 이 것에 대해 말해줄 수 없었다. 본인은 내 코드에 자신이 있었고, 괜찮다고 생각을 하였으나, 면접을 보면서 부족한점을 알게되었고, 이 수업들 듣게 되었다. 수업은 멘토와 멘티 관계로 내 코드를 봐주는 형식이다. CleanCode책과 함께 교윽을 듣고 있는 중이다.. 이 행위를 처음부터했으면... 하는 생각이 많이 든다.. 앞으로 내가 이 강의를 정리하는 방법은 경험에 의하여 필요한 내용들을 Clean Code란 책을 보면서 작성 할 것이다.