뭘 배웠을까? - 우아한테크코스 Lv1

3 분 소요

Level 1 - 프로그래밍 기본

  • 뭘 배웠을까?

  • RacingCar
    • 생성자를 통해 값을 전달하는 것은 어떨까
    • 메서드가 한가지의 일만 하도록
    • 메소드의 분리, 단위 테스트, 자바 컨벤션, 객체를 객체답게, 테스트하기 어려운 코드, 메시지를 보내라
    • MVC Pattern
  • LadderGame
    • enum 추상 메서드
    • Value Object
    • 추상화, 로직 분리, 일급컬렉션, 디미터 법칙, 정적 팩토리 메서드
    • 클래스 명, 메서드 명, 변수 명들을 명확하게.
    • 메서드 순서
      • 생성자 - static method, 구현코드(그 다음 private), toString/equals/hashCode/getter
    • 메인 메서드의 추상화 수준이 다르다.
    • 뷰 모델과 도메인을 분리해서 구현하도록.
    • getter를 최대한 줄이도록
  • Coordinate
    • 전략 패턴, 디자인 패턴, 도메인에 출력 포맷이 정의되어있으면 뷰에 종속된다.
    • 한 줄에 100자가 넘는다.
    • View 계층의 로직과 domain 계층의 로직이 할 역할을 구분할 것
    • 패키지 위치 적절하게
  • Lotto
    • 다시 만들 필요 없는 참조에 대한 재사용(로또 넘버)
    • 도메인에 출력 포맷을 연관시키지 말자
  • Lotto - web
    • 메서드 길이가 길어졌다.
    • 클래스 분리, 메서드의 분리, 단일 책임 원칙을 생각해보자.
    • 상수 사용
    • 변수는 사용될 때 선언하자.
    • 패키지 위지 적절하게
  • Chess
    • JDBC Template 분리
    • Controller 추출

정리

객체지향 생활 체조

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

어떤 점이 바뀌었을까?

  1. TDD (Red-Green-Refactoring)
    1. 테스트하기 어려운 코드에 대한 테스트
      1. 전략 패턴으로 인터페이스 추출 후 주입해주는 형식으로 변경
      2. 테스트하기 힘든 부분을 해당 메서드에서 분리하여 구성 형태로 변경
    2. 단위 테스트
      1. 모든 프로덕션 코드에는 테스트가 필요하다.
      2. 모든 예외 상황에 대해서 테스트가 진행되어야 한다.
    3. 나중 단계이긴 하지만 ATDD
      1. 각각 단위테스트들은 인수 테스트에서 확인할 수도 있다.
        1. 인수테스트 - 클라이언트의 흐름대로 쭉 테스트 하는 것
        2. 통합테스트 - 두 개 이상의 클래스?가 연관된 테스트
        3. Mock
          1. Mock 클래스와의 의존성을 제외하기 위해서
          2. 테스트의 설정을 간편하게 하기 위해
          3. repository test의 경우엔 프로덕션의 데이터 상태를 변경시키지 않기 위해
  2. 객체지향적 설계
    1. SOLID - 구현하면서 실제로 겪었던 경험을 정리 해봅시다.
      1. 단일 책임 원칙
        1. 한 개체는 하나의 책임만을 가져야 한다.
      2. 개방 폐쇄 원칙
        1. 확장에는 열려있고, 변경에는 닫혀있다.
        2. 인터페이스 vs. 추상클래스
      3. 리스콮 치환 법칙 - 서브타입은 언제나 기반타입으로 교체 가능 해야한다.
        1. 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
        2. Vehicle car1 = new Car(), Vehicle car2 = new Truck() 에서 car1.run() 과 car2.run()이 같은 성격의 동작을 해야한다.
      4. Interface Segregation Principle - 자신이 사용하지 않는 인터페이스는 구현하지 말아야한다.
        1. 인터페이스는 최대한 작은 조각으로 쪼개라 -> 자신이 사용하는 인터페이스들만 구현해라 // TODO
      5. Dependency Inversion Principle - 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하지 않도록 해야한다.
        1. 의존관계를 맺을 때 변하기 쉬운 것보다 변하기 어려운 것에 의존관계를 맺어라
        2. 인터페이스를 끼고 의존 관계를 맺자
    2. 디미터 법칙 - 나와 직접 관련된 친구들만 참조해야 한다.
      1. get().get().get() 하지마라 -> 객체에 메세지를 보내라
    3. 추상화
      1. 공통된 부분을 추출한다.
      2. 인터페이스로 뺀다.
    4. 객체지향 생활체조
      1. 일급컬렉션?
        1. 컬렉션을 wrapping한 클래스
        2. 명시적으로 클래스의 의미를 부여한다.
        3. 컬렉션에서 원하는 기능만을 부여할 수 있다. (예를 들어 추가가 불가능한 리스트, 삭제 불가능 리스트)
        4. 상태와 행위를 한곳에서 관리
      2. 원시값, 문자열을 포장하는 wrapper class를 쓰는 이유는 무엇일까?
        1. 명시적으로 값의 의미를 부여할 수 있다.
        2. 개발자가 다르더라도 일관된 타입을 전달 할 수 있다.
        3. 타입 끼리 혼동할 수 있는 경우가 없어질 수 있다. (예를 들어 생성자에 int, int, int 받는 것보다 LottoNumber ~~ 이런식으로 받으면 컴파일에서 에러가 난다)
  3. 디자인 패턴 - 각 디자인 패턴을 무조건적으로 사용하는 것이 아니라 적절한 타이밍에 적절한 사용처에 사용하는 것이 좋다.
    1. 전략패턴
      1. 함수형 인터페이스
        1. 제네릭, 람다
    2. 정적 팩토리 - 네이밍 (of, from 등)
      1. 가독성이 올라간다.
      2. 생성자의 파라미터에 따라 각각 의미를 부여할 수 있다.
    3. 싱글턴 패턴..
      1. Spring에서의 Single Instance만 사용하는 방식과 우리가 흔히 사용하는 LazyHolder사용 Singleton pattern 차이와 장,단점
        1. 일반 객체에서 Singleton은 객체 생성 자체를 막고 단 하나의 객체만 존재하도록 하는 것
        2. Single Instance 방식은 한번만 생성하고 그걸 가지고 계속 활용하는 것
        3. 일반적인 static 방식의 singleton pattern은 생성자를 private으로 막기 때문에 객체지향적이지 않다. 상속이 불가능하다. 객체의 인스턴스가 하나임을 보장하기 위해 객체의 다른 특성을 포기한다.
        4. Spring의 single instance 방식은 객체의 특성을 그대로 사용할 수 있다. 상속구조를 사용할 수도 있다.
  4. 자바 코딩 컨벤션
  5. 변수명 정하기 - 명확하게 의미를 알아볼 수 있도록 정한다.
    1. 줄임말 쓰지말자. racingCarGame은 racingCarGame이지 rcg라고 하면 아무도 모른다.
  6. 코드를 리팩토링 할 시기
    1. 한 메서드가 많은 역할을 하고 있다.
    2. 한 클래스의 필드가 많다.
    3. 생성자에 필요한 파라미터가 많다.
    4. 다른 레이어의 참조(주입)이 많아진다.
    5. 인덴트가 여러번 들어간다면, 그 메서드가 너무 많은 역할을 하고 있는 것이 아닌가 의심해보아야 한다.
  7. MVC 구조에서 Model, View, Controller가 해야하는 역할
    1. 웹에서 MVC흐름
      1. Entity, VO, DTO
    2. Domain Driven Development
      1. presentation layer, application layer
  8. 좋은 코드란 무엇일까?
    1. IF문
      1. if, else의 연속은 변경에 취약해진다. 유지보수하기 어려워진다.
      2. 단일 책임 원칙 위반이 될 수 있다.
    2. 유지보수하기 쉬운 코드
      1. 코드를 분석하는데 어려움이 없는 읽기 쉬운 코드
      2. 변경이 일어날 가능성을 최대한 줄이고 유연하게 대처할 수 있는 코드
    3. 객체지향 설계 SOLID
    4. 객체 간의 관계를 파악한다.
      1. 연관관계
      2. 의존관계
      3. 상속관계
      4. 구현관계
  9. 상속은 왜 해야할까?
    1. 인터페이스는 구현을 강제한다.
    2. 추상클래스는 구현을 통해 확장을 할 수 있게 한다.
    3. 추상화를 할 수 있는 좋은 방법이다.

태그:

카테고리:

업데이트:

댓글남기기

참고

Github CLI 사용기

2 분 소요

9월 17일 날짜로 Github CLI 1.0 버전이 릴리즈 되었습니다. Github에 들어가보니 옆에 뭔가 거슬리는 것이 있길래 확인해보고 사용해본 후기를 정리하여 포스팅합니다.

TCP 상태(CLOSE_WAIT, TIME_WAIT)

2 분 소요

트래픽을 만들어내는 어떤 툴을 사용하다가 CLOSE_WAIT 상태로 계속 유지되는 버그를 마주쳤다. 그런 의미에서 TCP 상태에 대해서 공부하고 정리한다.