이전

Java/Spring 주니어 개발자를 위한 오답노트

순차 지향 프로그래밍과 절차 지향 프로그래밍의 차으를 설명하실 수 있나요?

  • 순차 지향 프로그래밍 Sequential oriented programming
  • 절차 지향 프로그래밍 Procedure oriented programming

Procedure “In different programming languages, a subroutine may be called a routine, subprogram, function, method oor procedure”

실천 할 수 있는 컨벤션 교정

  1. 이름
    • 메소드 이름은 동사로 시작한다
    • 축약어를 대문자로 표현하지 않는다
      • private String userId
      • private String restApi
      • public class ApiClient {}
    • Simple / Light / Base
      • 유의미한 단어를 사용하세요. 어디에 왜 필요한지를 고민하고 이름을 지으세요
    • Util
      • Util 이라는 이름하에 모든 static 메소드가 모일겁니다.
  2. 동사
    • get vs find
      • get return type이 T 인 경우 (일반적으로 데이터가 없을 시 exception 을 throw 합니다.)
      • find return type이 Optional 인 경우
    • isExist vs exist
      • exist를 쓰세요. 동사를 반복하는 거라서 없는 단어입니다.
    • get
      • get 접두어는 갖고 있는 속성 정보를 제공한다는 의미입니다. 찾아오라는 지시가 아닙니다.
  3. 롬복
    • getter setter 를 남발하지 마세요
      • 캡슐화를 망치는 주범이다
      • 사실상 public 멤버변수 입니다
      • 객체를 수동적이게 만듭니다.
      • 객체를 능동적이게 만드세요. (TDA 원칙 - Tell don`t ask. 디미터 법칙)
  4. 가독성
    • Collection.Map 을 남발하지마세요.
      • 가급적이면 일급 클래스로 만들고 사용하더라도 지정된 { scope } 빡을 넘다들지 마세요.
  5. 관습
    • start end
      • range 는 [start,end] 시작은 포함해주고, 끝은 제외한다. 
         for (int i = 0; i < temp.length; i++){
 }

더 알아볼 만한 주제

  1. 검증이 필요할때
    • verify vs validate
    • check vs is
  2. 코드스타일
  3. 단어 조합은 3개 이하로

객체 지향적인 코드 짜기 (1) : 객체의 종류, 행동

객체의 정류

  1. VO
    • 번역 : VO는 불변해야 하며, 이는 동일하게 생성된 두 VO는 영원히 동일한 상태임을 유지되어야 한다는 것을 의미합니다. 또한 VO는 잘못된 상태로는 만들어 질 수 없습니다. 따라서 인스턴스화 된 VO는 항상 유효하므로 버그를 줄이는데에도 유용합니다.
    • 번외. 생성자는 가급적 두개의 역할만 해야합니다
      • 값을 검증합니다.
      • 값을 할당합니다. ~~~java class UserInfo { private final long id; private final long username; private final long email;

    public UserInfo(long id, String userName, String email){ assert id > 0; assert StringUtils.isNotEmpty(userName); assert EmailValidator.isValid(email);

    this.id = id; … } ~~~

  2. DTO
    • an object that carries data between processes
    • DTO는 상태를 보호하지 않으며 모든 속성을 노출하므로 획득자와 설정자가 필요 없다. 이는 public 속성으로 충분하다는 뜩이다.
  3. Entity
    • 유일한 식별자가 있고,
    • 수명 주기가 있으며,
    • 쓰기 모델 저장소에 저장함으로써 지속성을 가지며 나중에 저장소에 불러올 수 있고,
    • 명명한 생성자와 명령 메서드를 사용해 인스턴스를 만들거나 그 상태를 조작하는 방법을 사용자에게 제공하며,
    • 인스턴스를 만들거나 변경할 때 도메인 이벤트를 만들어 낸다.
  4. PO(Persistent Object)
    • Entity 와 DB Entity 는 다르다는 말을 합니다. JPA 의 Entity 는 흔히 말하는 DB Entity 에 해당한다 보시면 되십니다. 그리고 개인적으로 DB Entity 라는 용어보다는 PO 라고 부르는게 더 맞다고 생각합니다.

객체를 만들 때의 고민 객체의 종류에는 3종류만 있는 것이 아니며, 완벽한 분류는 어렵습니다. VO 이면서 Entity 일 수 있으며, DTO 이면서 PO 일 수 도 있고 셋 다 아닐 수도 있다. 사실 분류보다 어딴 갑을 불변으로 만들 것인가? 어떤 인터페이스를 노출할 것인가?

번외로 DAO(Data Access Object), BO(Business Object), SO(Service Object)

디미터 법칙

  • 최소 지식의 법칙

행동

데이터 위주 사고

class Car{
    private Frame frame;
    private Engine engine;
    private List<Wheel> wheels;
    private Direction direction;
    private Speed speed;
}

행동 위주의 사고

class Car{
    public void drive(){}
    public void changeDirection(){}
    public void accelerate(Speed speed){}
    public void decelerate(Speed speed){}
}

struct 와 class 는 다릅니다.

duck typing 행동이 같다면 같은 클래스로 부르겠다. 덕타이핑 이라는 용어는 다음과 같이 표현될 수 있는 덕 테스트에서 유래했댜. 만약 어떤 새가 오리처럼 걷고, 헤엄치고, 꽥꽥거리는 소리를 낸다면 나는 그 새를 오리라고 부를 것이다.

순환 참조

순환 참조, 양방향 참조를 만들지 마세요.

  • 순환참조를 넘어 순환 의존성 자체가 결합도를 높이는 원인이 됩니다.
  • 순환참조 떄문에 Serialize가 불가해집니다.
  • 간접 참조로 해결하자. 차라리 Id로 필요할 때마다 찾아오는게 낫습니다.

설계 (1) : 의존성이란 무엇인지? (DI vs DIP)

SOLID

  • 단일 책임 원칙
  • 계방-폐쇄 원칙
  • 리스코프 치환 원칙
  • 인터페이스 분리 원칙
  • 의존성 역전 원칙

의존성

  • 의존성이란 무엇인가?
    • Dependency (computer science) or coupling, a state in which one object uses a function of another object
  • 의존성 주입이란 무엇인가?
    • 필요한 값을 외부에서 의존성을 넣어주면 의존성 주입이다 (파라미터 주입, 필드 주입, 생성자 주입)
  • 의존성 주입(DI)과 오해
    • 의존성이 사라진게 아니라 약해진거다.
  • 의존성 역전 (DIP)
    • Dependency Injection과 Dependency Inversion은 다르다.
  • 의존성 역전 원칙
    • 첫째, 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.
    • 둘째, 추상화는 세분 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다.
    • 화살표의 방향을 반대로 바꾸는 테크닉
  • 의존성 주입 != 의존성 역전
  • 의존성 주입의 대표 도구 = 스프링
  • Dependency Injection 이 dependency inversion 을 만들 수 없다.
  • 무조건 추상화하라는 의미는 아님, 추상화는 좋은 방법론이긴 하지만 개발하는 데 비용을 증가시키는 경향이 있다.
  • 생성자 의존성 주입이 7개 이상 넘어거가너 파라미너 의존성 주입이 4개 이상 넘어간다면 클래스 문할이나 메소드 분할을 고려해야 한다는 신호이다.
  • 스프링이 Inversion of Control Container 라는 말을 많이합니다. 그래서 Dependency Inversion 를 제공한다 생각 하는 사람도 있습니다. 아닙니다.

설계 (2) : 의존성을 추상화 시키는 방식

  • 의존성을 드러내라
  • 변하는 값은 주입받아라. (로그인 시간값)

  • 변하는 값을 추상화 시켜라 “결론적으로 변하는 값에대한 가장 괜찮은 접근법은 런타임 의존성과 컴파일 타임 의존성을 다르게 하는 것”

  • CQRS (Command and Query Responsibility Segregation)
    • 명령과 질의의 책임 분리
    • 메소드를 명령과 질의로 나누자. (더 넓게는 클래스까지도)
    • 하나의 메소드는 명령이나 쿼리여야하며, 두 가지 기능을 모두 가져서는 안된다. 명령은 객체의 상태를 변경할 수 있지만, 값을 반환하지 않는다. 쿼리는 값을 반환하지만 객체를 변경하지 않는다.

설계에는 정답이 없다.

  • Shotgun surgery : 기능 산재 - 모아둬야 할 것을 분할해서 발생
  • Divergent change : 수정 산발 - 분할해야 할 것을 모아놔서 발생

기타

  • TDD, DDD, FP 모두 가르키는 것은 잘 설계된 OOP. 그렇다고 DDD TDD FP 등을 공부하지 말라는 것은 아니다. 잘 설계된 OOP를 얻기 위해 공부할 가치가 있다.

  • DDD Domain 이라는 객체 모델을 어떻게 하면 잘 정의할 수 있는가? 에 대한 이야기. * 맨 마지막 Development 가 아니라 Design 이라는 점은 다시 한번 상기 해볼 만하다.

  • vs 절차지향
    • 절차지향이라고 나쁜건 아니다 객체지향이 없던 시절에도 훌륭한 프로그램이 많이 만들어졌다. 객체지향이 빠르게 이해되는 코드를 보장하지는 않는다. 객체지향의 가장 큰 장점은 확장에는 열려있고 수정에는 닫혀 있게 만드는 점.
  • 객체지향 생활 체조 9가지 원칙 (오늘날 더 나은 소프트웨어를 향한 9단계)
    • 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다.
    • else 예약어를 쓰지 않는다.
    • 모든 원시값과 문자열을 포함한다.
    • 한 줄에 점을 하나만 찍는다.
    • 줄여쓰지 않는다.(축약금지)
    • 모든 엔티티를 작게 유지한다.
    • 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
    • 일급 컬렉션을 쓴다.
    • getter/setter/property 를 쓰지 않는다.
  • CollectionUtils / StringUtils / ObjectUtils 적극 사용 권장
    • 보안패치, 라이센스 확인하기
  • 상속
    • 상속을 지양하고 Composition을 지향할 것
  • 테스트
    • 테스트를 먼저 생각해라. 테스트 하기 쉬운 코드가 좋은 설계일 확률이 높다.
  • 블락
    • 블락이 생긴다면 메소드를 분할을 고려하세요.

스프링에서 OOP와 안티 패턴 : Transaction script

  • Smart UI (스마트 컨트롤러를 피하세요)
    • 백엔드에서 UI란 Controller
    • 절대 똑똑한 Controller 가 아님
    • Controller 는 어떤 서비를 실행할지 선택하는 정도의 역할
  • Relaxed layerd system
    • 한 계층의 구성요소가 바로 아래 있는 계층만 접근할 수 있는게 아니라 하위 모든 계층에 접근을 허용한다. (안티패턴)
  • Layerd system at DDD
    • 계층화의 가치는 각 계층에서 컴퓨터 프로그램의 특정 측면만을 전문적으로 다룬다는 데 있다.
    • 소프트웨어가 수행할 작업을 정의하고 표현력있는 도메인 객체가 문제를 해결하게 하는 레이어, 다른 시스템의 응용 계층과 상호작용하는 데 필요한 것들. 이 계층은 최대한 얇게 유지되어야한다. 업무 규칙이나 지식이 포함되지 않아야한다. 오직 작업을 조정하고 아래에 위치한 계층에 도메인 객체의 협력자에게 작업을 위임한다.
  • Transaction script
    • 서비스 컴포넌트에 모든 업무규칙과 지식들이 들어가 있으면 수동적인 도메인, 뚱뚱한 계층, 전혀 객체 지향적이지 않음.
    • 사실상 서비스는 트랜잭션을 실행하는 스크립트 역할을 하게 될 뿐임
    • 비즈니스 로직을 제발 도메인이 들고있게 해주세요asd
    • 비즈니스 로직과 Repository가 결합되어 있기 때문에 테스트코드 작성에 대한 불편함
    • 도메인의 개념 가운데 객체로는 모델에 어울리지 않는 것이 있다. 필요한 도메인 기능을 ENTITY나 VALUE에서 억지로 맡게 하면 모델에 기반을 둔 객체의 정의가 왜곡되거나 또는 무의미하고 인위적으로 객체가 추가 될 것이다.
      • 새로운 객체를 만들면 그만이다.
      • ‘가격계산’ 같이 객체로 표현하기 애매하고, 논리 로직 자체가 목적인 행위자를 도메인 서비스라고 합니다.

어디까지 추상화 해야 하는가?

  • 추상화(abstraction)는 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것을 말한다.
  • ‘모듈을 격리하고 인터페이스로 만드는 과정’
    • 책임을 선별하는 과정
  • Controller, Service, Entity, VO는 구현체로 구현되어도 상관없다.
    • 제어기는 구체다, 응용 프로그램 서비스는 구체다, 개체와 값 객체는 구체다. 저장소(쓰기와 읽기 모델은)는 추상과 최소 한 개 이상의 구체 구현으로 구성된다.
    • 전제로 서비스와 컨트롤러는 한번 생성으로 영원히 같은 일을 할 수 있는 객체이어야한다.
  • 확실한 건 테스트하기 좋은 코드는 좋은 설계일 확률이 높다

서비스란 무엇인가?

  • @Component 구성요소, @Controller 제어부, @Service 서비스 @Repository 저장소
  • 서비스는 DDD에서 가져온 개념이고, 비즈니스 서비스의 Facade 이다
  • DDD 에서 정의된 서비스를 지칭하는 어노테이션, “캡슐화된 상태 없이 모델에서 독립적으로 제공되는 인터페이스로 제공되는 작업”
  • 자신의 본거지를 ENTITY나 VALUE OBJECT에서 찾지 못하는 중요한 도메인 연산이 있다. 이들 중 일부는 본질적으로 사물이 아닌 활동(activity)이나 행동(action) 인데, 우리의 모델링 패러다임이 객체이므로 그러한 연산도 객체와 잘 어울리게끔 노력해야한다.
  • 이따금 서비스는 특정 연산을 수행하는 것 이상의 의미는 모델 객체로 가장해서 나타나기도 한다. 이같은 행위자(doer)는 이름 끝에 “Manager”와 같은 것이 붙는다.(중략) 서비스라는 이름은 다른 객체와의 관계를 강조한다.. SERVICE는 주로 활동으로 이름을 짓는다.
  • 오늘날 흔히 하는 실수는 행위를 적절한 객체로 다듬는 것을 너무나도 쉽게 포기해서 점점 절차적으로 프로그래밍에 빠지는 것이다.
  • 애플리케이션 서비스와 도메인 서비스
    • 애플리케이션 서비스 : 스프링한정) 스프링의 서비스 컴포넌트에 종속되는 서비스
    • 도메인 서비스 : 스프링한정) 스프링의 서비스 컴포넌트에 종속되지 않는 서비스
  • 중요한 건 풍부한 도메인을 만들라는 것.
  • 서비스는 가능한 적게 만들고 얇게 만들라는 것
  • 첫 번째 객체는 한번 생성하면 여러 번 사용하지만 그 자신은 바꿀수 없다. 생명 주기도 매우 단순하다. 한번 생성하면 특정 작업을 하는 작은 기계처럼 영원히 실행할 수 있다. 이러한 객체를 서비스라 한다.
  • 생성자 주입만 사용한다(중략) 서비스는 불변이어야 한다. 즉 인스턴스 생성을 마친 후에는 바꿀 수 없어야 한다.
    • 생성자 주입을 해야하는 이유 : 한번 생성으로 영원히 일을 하는 일관된 객체를 만들어야하기 때문.
    • 미관상 생성자 자체를 넣는게 예쁘지 않다 느껴진다면 @RequiredArgsConstructor + private final 을 이용해라.
  • 서비스에 setter 가 존재한다면 지워야한다. 서비스의 동작이 멤버 변수의 상태에 의해서 다르게 동작해선 안 되기 때문이다.

기타

  • JPA는 기술 명세이고 Hibernate는 구현체 입니다.
  • 연관 관계의 주인, 관계를 표현하는데 있어서 가장 중요한 것 = 연관 관계의 핵심 = 외래키
  • 왜 기본키는 관계의 주인이 아닌가?
    • 기본키만으로는 연결된 엔티티가 무엇인지 알 수 없기 때문.
    • 기본키가 없다면, 연관 관계를 이야기하기 전에 그냥 잘못된 엔티티이기 때문.
  • 외래키 = 연관관계의 주인 = Owner of the relation
  • 외래키를 들고있다 = Owner 를 들고 있다 = Owing side

  • Optimistic lock vs Pessimistic lock

  • Controller, Service, Repository 가 무조건 postfix 로 들어가는 것을 싫어하는 사람도 존재한다.
  • Repository 대신 Reader / Writer (CQRS)
  • 스프링 컴포넌트에 있는 AOP annotation은 스프링 프록시를 거칠 수 있을 때만 가능 합니다. (self-invocation)
  • List를 의존성 주입 받으면 빈으로 만들어진 서브 클래스들이 모두 주입됩니다.
  • LocalRepository (FAKE)
    • 어떤 조직이나 회사에선 아예 로컬,테스트 환경에서 사용하기 위한 Repository 레이어의 Concreate class를 전부 In memory 로직으로 구현해두기도 함.

테스트를 해야 하는 이유와 테스트의 분류

Q. 레거시 코드란 무엇일까요?

  • 내게 레거시 코드란, 단순히 테스트 루틴이 없는 코드다. 다만 이정의는 다소 불완전하다.
  • 회귀 버그 : 서비스를 제공하지 못하던 상황으로 회귀 하는 상황
  • 회귀 테스트 : 서비스에 회귀 버그가 있는지 확인하는 테스트

“10년을 개발했는데 깊이가 깊어진 전문가가 아니라, 3년짜리 개발 경험을 3번 한것이 아닌가?”

테스트의 종류

  • 인수 테스트
    • 인수검사(acceptance testing)는 정보시스템 검사 중 하나로, 시스템이 실제 운영 환경에서 사용될 준비가 되었는지 최종적으로 확인하는 단계이다. 시스템 거사는 사용자가 평가하고 관리자가 점검한다.
  • 자동테스트
    • 소프트웨어를 이용하여 자동하된 테스트를 의미한다.

테스트의 3분류

  1. E2E (5%) - API 테스트
  2. INTEGRATION (15%) - 통합 테스트
  3. UNIT (80%) - 단위 테스트

구글 엔지니어는 이렇게 일한다에서 정의하는 3분류

  1. E2E (5%) - API 테스트 -> large 테스트
  2. INTEGRATION (15%) - 통합 테스트 -> medium 테스트
  3. UNIT (80%) - 단위 테스트 -> small 테스트

small(소형테스트)

  • 단일서버
  • 단일 프로세스
  • 단일 스레드
  • 디스크 I/O 사용해선 안됨
  • Blocking call 허용 안됨

medium(중형테스트)

  • 단일서버
  • 멀티 프로세스
  • 멀티 스레드
  • 테스트용 DB를 사용할 수 있다. (H2)

large(대형테스트)

  • 멀티서버
  • End to end 테스트

안티패턴

  • 아이스크림 패턴
    • E2E 테스트만 늘어나는 경우
  • 모래 시계 패턴
    • 중형 테스트를 신경 안쓴다면 발생하는 패턴

테스트에 필요한 개념

개념

  1. SUT (System under test)
    • 테스트 하려는 대상
  2. TDD 태스트 주도 개발
    • 깨지는 테스트를 먼저 작성한다. RED
    • 깨지는 테스트를 성공 시킨다. GREEN
    • 리팩토링한다. BLUE
  3. BDD (Behaviour driven development) (given-when-then)
    • 테스트 코드를 작성하다보면 모든 메소드를 테스트하고 싶은 욕구가 생김. 메소드 위주의 테스트 코드보다 시나리오에 기반한 테스트를 하는 방식.
    • 시나리오.1 어떤 상황이 주어지고 어떤 행동을 할 때 이렇게 되더라
    • 시나리오.2 어떤 상황이 주어지고 어떤 행동을 할 때 이렇게 되더라
  4. 불규칙한 테스트 (flaky)
    • 대상 코드에 아무런 변경이 없음에도 불구하고 실패하는 테스트
    • non-deterministic 한 테스트
  5. 깨지기 쉬운 테스트 (brittle)
    • 실제로는 버그가 없음에도, 심지어 검증 대상 코드와 관련조차 없는 변경 때문에 실패하는 테스트를 말한다.
    • 테스트에 필요한 가정들이 명시적으로 작성되지 않을 경우 발생
  6. 상호 작용 테스트 (Interaction test)
    • 대상 함수의 구현을 호출하지 않으면서 그 함수가 어떻게 호출되는지를 검증하는 기법
    • 상호 작용 테스트보다는 상태를 테스트하는게 좋다.
  7. 테스트 더블
    • 테스트 대역

대역

  1. Dummy
    • 아무런 동작도 하지 않고, 그저 코드가 정상적으로 돌아가기 위해 전달하는 객체
  2. Fake
    • Local 에서 사용하거나 테스트를 사용하기 위해 만들어진 객체, 자체적인 로직이 있다는게 특징
  3. Stub
    • 미리 준비된 값을 출력하는 객체
    • 특정 이메일(admin@mail.com)이 입력되면 준비된 객체(User)를 반환
  4. Mock
    • 메소드 호출을 확인하기 위한 객체, 자가 검증 능력을 갖춤 사실상 테스트 더블과 동일한 의미로 사용됨
  5. Spy
    • 메소드 호출을 전부 기록했다가 나중에 확인하기 위한 객체

도구

  1. Mock 프레임워크
    • Mockito vs BDDMockito
    • Mock 프레임워크를 지양해야하는 이유
      • UserRepository 가 굳이 인터페이스 이어야 할 이유가 있나? 그냥 class로 만들고 mock 프레임워크를 사용해서 필요할 때 마다 stub 하면 되지 않나??
  2. 다른 언어의 테스트 도구들
    • Jest 페이스북 에서 개발한 자바스크립트 테스트 라이브러리
    • Chai nodejs 에서 assert 문을 가독성있게 쓰기 위해 만든 라이브러리
    • kotest

테스트 기법 소개

조언

  1. private 메소드는 테스트 해야 할까요?
    • No.
    • 사실 private 메소드가 아니였어야 한다는 의미일 수 있다.
    • 다른 클래스로 분리하고, 책임을 위해서 public 으로 만들라는 의미일수도 있음.
    • 메소드 지향의 테스트를 하려해서 생기는 문제, 행위에 집중해서 테스트해야함.
  2. final 메소드
    • final 메소드를 sub 해야하는 상황이 생긴다면, 무언가 설계가 잘못된 것이다.
    • final 메소드에 걸린 의존성을 약하게 하는 방법을 생각해봐야 한다.
  3. DRY < DAMP
    • DRY(건조한) Don`t Repeat Yourself (반복하지 않기)
    • DAMP (습한) Descriptive And Meaningful Phrase (서술적이고 의미 있는 문구)
  4. 논리
    • 테스트에 논리를 넣지 말자

기법

  1. 의존성 추상화
    • 테스트하기 어려운 의존성이 있을 때 사용할 수 있는 기법
      • 다루기 까다로운 경우 : Random / Time
      • 테스트에 필요한 인스턴스를 생성하기 힘든 경우 : HttpRequest …
      • 재정의가 까다로운 경우 : final / 전역 참조
  2. 이벤트 기록
    • 테스트 위한 getter 생성이 남발된다 싶을 때 적용할 수 있는 기법

네트워크 용어 정리 (1) : DNS, LB, FQDN 등

  • 도메인
    • 네트워크상에서 컴퓨터를 식별하는 호스트명
  • DNS
    • 호스트의 도메인 이름을 호스트와 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다.
    • 요즘 같이 클라우드 서버에서 아이피가 많은 경우 DNS 설정하기가 어려움 그래서 VIP 방식 이용
  • VIP (대표아이피)
    • A virtual IP address (VIP or VIPA) is an IP address that does not correspond to a physical network interface
    • VIP 는 로드밸런싱 역활도 한다
  • LB
    • 로드 밸런싱은 컴퓨터 네트워크 기술의 징종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다.
    • LB-라운드 로빈 ; 서버에 들어온 순서대로 부하를 분배하는 방식
      • from. Round-robin “The term dates from the 17th-century French Rond ruban (사발통문)
    • LB-알고리즘
  • SLB
    • Server
  • GSLB
    • Global
    • DNS 기반의 LB라서 IP가 아닌 도메인을 갖는다. 헬스체크 및 LB시 서버의 위치를 고려
  • L4 로드밸런싱
    • IP/Port 기반 로드밸런싱
    • 위 내용 까지 로드밸런싱들을 모두 L4 로드밸런싱이라고 한다
  • L7 로드밸런싱
    • URI, Paylaod, Http Header, Cookie 기반으로 로드 밸런싱
  • FQDN
    • A fully qualified domain name

네트워크 용어 정리 (2) : CDN, ACL, Proxy, SSL 등

  • CDN
    • 콘텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템을 말한다.
  • ACL
    • 접근 제어 목록(access control list) 또는 액세스 제어 목록은 개체나 개체 속성에 적용되어 있는 허가 목록을 말한다.
  • Proxy
    • 프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가르킨다.
    • cache
    • access control
    • 보안
    • 사용률 파악
  • Proxy-forward == Proxy
  • Proxy-reverse

인프라 용어 정리 : XaaS, 컨테이너 등

XaaS (X as a Service)

  • IaaS (아마존 EC2, 구글 컴퓨트 엔진, 마이크로소프트 애저o)
  • PaaS (구글 colab, 구글 앱엔진)
  • Saas (온라인으로 액세스 가능한 소프트웨어, 구글드라이브, 슬랙, 온디맨드 소프트 웨어)

온프레미스

  • 자체 전산실 서버에 직접 설치해 운영하여 서비스를 전달하는 방식(전통적)
  • On premises (idiom) : inside a building or on the area of land that it is on

온디멘드

  • 수요가 필요한 즉시 바로 서비스를 전달할 수 있는 방식
  • On demand : at any time that someone wants or needs something

운영 용어 정리 : MSA, 오픈소스, CI/CD 등

관리자 입장의 선택

  • Scale-out 장비 갯수를 늘린다.
  • Scale-up 장비 스펙을 높인다.

아키텍처 입장의 선택

  • x축 확장 : 복제해서 확장한다. (백엔드 인스턴스 수를 늘리는 것)
  • y축 확장 : 기능을 분할한다. (Monolithic -> MSA)
  • z축 확장 : 데이터 파티셔닝 (Monolithic MSA 둘 다 적용 가능)

MSA

  • 마이크로서비스는 애플리케이션을 느슨하게 결합된 서비스의 모임
  • 마이크로서비스의 속성과 관련하여 아직 산업적인 합의는 없으며 공식적인 정의도 없다.
  • 통념적으로 하나의 큰 서비스를 여러 작은 단위의 서비스로 나눠서 배포하는 방

HA (High Availability)

  • 고가용성이란 ‘가용성이 높다’는 뜻으로서, “절대 고장 나지 않음”을 의미한다
  • 99.999% five nines 5.26분(365일 중 다운타임) > 매우 높은 수준, 고품질 데이터센터에서 목표로함

이중화

  • 다중화(redundancy)는 시스템의 일부에 어떠한 장ㅇ가 발생했을 경우에 대비하여, 장애 발생 다음에도 시스템 전체의 기능을 계속 유지하도록 예비 장치를 평상시부터 백업으로서 배치해 운영하는 일이다.
  • Active-Standby 같은 시스템을 띄우되 하나는 사용하지 않고 예비로 남겨두는 방식
  • Active-Active 시스템 둘다 사용하는 방식이다. 큰 맥락에서는 Master-Slave(Primary-Secondary) 방식이 여기에 해당되긴 한다.

Provisioning

  • 프로비저닝은 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다.

DR

  • 재난 복구 계획(disaster recover plan, DRP)는 자연재해나 인위적인 쟇가 일어나면 특정 단체에 중요한 기술 인프라를 복구하거나 지속할 목적으로 준비하는데 대 대한 과정, 정챋, 절차를 가리킨다.

Failover

  • 장애 극복 기능은 컴퓨터 서버, 시스템, 네트워크 등에서 이상이 생겼을 때 예비 시스템으로 자동전환되는 기능이다. 시스템 대체 작동 또는 장애 조치라고도 한다.

Switchover

  • 반면 사람이 수동으로 전환을 실시하는 것을 스위치 오버라고 한다.

Failback

  • 한편 페일백은 페일오버에 따라 전환된 서버/시스템/네트워크 장애가 발생하기 전의 상태로 되돌리는 처리를 말한다.

Log

  • 첫 시작은 선원들이 배의 속도를 측정하기 위해, 매듭이 묶인 통나무 더미를 선미에 던져 확인하던 것을 시작으로 하였습니다. 항해사들은 이 정보를 어딘가에 기록해 관찰하기 시작했고, 처음에는 몇장 안되던 정보들이 곧 하나의 책의 형태가 되기도 하였습니다. 책의 형태가 되자 이 책에는 항해에 필요한 다양한 정보들과 항해 이력같은 정보도 추가로 기록되기 시작했습니다. 예를들어 선박이 어떤 보안 구역을 통과할 때, 상호간의 서명이 필요했는데, 이때 이 책이 사용되기도 하였습니다. 그러자 보안 구역을 통과하기 위해 sign in - out 한다는 의미는 logged in - out 한다는 의미와 동일하게 사용되기 시작했습니다.

오픈소스 라이센스

  • Apache license 2.0 / MIT 이거 두 개는 문제 없이 사용 가능하다고 외우자

애자일

애자일 소프트웨어 개발(Agile software development) 혹은 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다.

예를 들면 폭포수 모델 또는 나선 모형과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를 통한 개발 방법이 아니라, code-oriented, 실질적인 코딩을 통한 방법론이라는 점이다.

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

소프트웨어 개발 자체가 복잡계이므로, 표준화된 절차와 규칙, 도구를 통한 해결보다는 팀 자체를 어떤 상황에서도 대처 가능한 팀으로 만들어야한다는 정신무장

Devops

데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다. 위키백과 기여자, “데브옵스,” 위키백과, , https://ko.wikipedia.org/w/index.php?title=데브옵스&oldid=32867353 (2022년 6월 25일에 접근).

데브옵스 툴체인

  1. 계획 - 목적을 수행하기 앞서 방법이나 절차 등을 미리 생각하여 계획.
  2. 코드 - 코드 개발 및 검토, 버전 관리 도구, 코드 병합
  3. 빌드 - 지속적 통합(CI) 도구, 빌드 상태
  4. 테스트 - 테스트 및 결과가 성능을 결정
  5. 패키지 - 애플리케이션 디플로이 이전 단계
  6. 릴리스 - 변경사항 관리, 릴리스 승인, 릴리스 자동화
  7. 구성 - 인프라스트럭처 구성 및 관리, laC(Infrastructure as Code) 도구
  8. 모니터링 - 애플리케이션 성능 모니터링, 최종 사용자 경험. 위키백과 기여자, “데브옵스,” 위키백과, , https://ko.wikipedia.org/w/index.php?title=데브옵스&oldid=32867353 (2022년 6월 25일에 접근).

기타

  • Webhook 이벤트가 발생했을 시 API 를 호출하는 Callback API
  • CS 고객문의(Customer Service)
  • 유불 유저불량 서비스의 문제가 아니라 사용자가 잘못 사용하여 생긴 문제일 경우
  • TL;DR too long; didn`t read
  • 마일스톤 프로젝트 진행 과정에서 특정할 만한 건이나 표를 말한다
  • ROI 원래는 투자ㄷ비 수익률 (Return on investment) 이지만, 사실상 가성비
  • R&R 역활과 책임 Role and Responsibility

Rest API

로이 필딩이 만든 API 를 어떻게 설계할 것인가? 에 대한 논문

1) Uniformb (일관성) 2) Stateless (무상태성) 3) Cacheable (캐시 가능) 4) Self-descriptiveness (인터페이스만 봐도 이해 가능) 5) Client - Server 구성 6) 계층형 구조

인증 vs 인가

  • Authentication (인증) vs Authorization (인가)
  • 이 토큰은 유효한 토큰인가? vs 이 토큰은 이 리소스에 접근 가능한가?
  • 401 (Unauthorized) vs 403 (Forbbiden)

함수형 프로그래밍

  • 자료 처리를 수학적 함수의 계산으로 취급하고, 상태와 가변 데이터를 멀리하는 프로그래밍 패러다임의 하나이다.
  • 부수효과(side-effect)이 없는 Immutable, pure function 을 지향하는 프로그래밍 방식

부수효과

  • 함수를 수행할 때 발생할 수 있는 명시적 입출력 값 외 모든 암묵적 입출력
    • 명시적 입력 매개변수
    • 명시적 출력 리턴값
    • 암묵적 입력 매개 변수 외 다른 입력 (전역 변수 조회)
    • 암묵적 출력 리턴값 외 다른 출력 (전역 변수 수정, API 호출)

CORS

  • 교차 출처 리소스 공유(Cross-origin resource sharing, CORS), 교차 출처 자원 공유는 웹 페이지 상의 제한된 리소스를 최초 자원이 서비스된 도메인 밖의 다른 도메인으로부터 요청할 수 있게 허용하는 구조이다.
  • 아무 도메인에서나 우리 서비스를 호출하는 것을 막기 위한 정책. 브라우저단에서 동작하는 정책이라 curl 이나 포스트맨을 이용하여 요청을 보내면 CORS 검증을 하지 않습니다.

기타

  • 멱등성(Idempotence) 여러번 실행해도 실행 결과가 동일하다.
    • int result = Math.add(2, 3);
  • 공변성(Covariant)
    • 공변성 서브 타입이 슈퍼 타입 대신 사용될 수 있다.
    • 반공변성 슈퍼 타입이 서브 타입 대신 사용될 수 있다.
    • 무공변성 슈퍼 타입과 서브 타입이 아무런 관계도 없다.
  • 리눅스 기본 커맨드 – 일반적으로 커맨드에 옵션을 적을 때
    • 한글자 인 경우 -v, -f, -h
    • 두글자 이상인 경우 –version, -file, –human-readable

메서드는 왜 메서드인가?

  • 메시지
    • 요약하면 메시지는 객체들이 서로 협력하기 위해 사용할 수 있는 유일한 의사소통 수단이다
    • 메시지 전송은 수신자, 메시지 이름, 인자의 순서대로 나열하면 메시지 전송이 된다.
  • 인터페이스
    • 객체의 인터페이스는 객체가 수신할 수 있는 메세지의 목록으로 구성되며 객체가 어떤 메시지를 수신할 수 있는지가 ㄱㄱ체가 제공하는 인터페이스 모양을 빚는다.
    • 인터페이스는 객체가 다른 객체와 협력하기 위한 접점이다.