Learning Go 📚

• 1.2 GO 작업 공간

• 1.3 GO 명령어

• 1.4 린팅 그리고 베팅

• 1.5 개발 도구 소개

• 1.6 Makefiles

• 1.7 항상 최신으로 유지

• 1.8 마무리

• CHAPTER 2 기본 데이터 타입과 선언

  • 2.1 내장 타입
  • 2.2 var Versus :=
    • 제로값 초기화 할때는 var x int가 낫다
    • 마찬가지로 타입 지정안된 상수나 리터럴 할당시에도 x := byte(20) 보다는 var x byte = 20 이 낫다.
  • 2.3 CONST 사용
  • 2.4 타입 지정 상수와 타입 미지정 상수
  • 2.5 사용하지 않는 변수
  • 2.6 변수와 상수 이름 짓기
  • 2.7 마무리

• CHAPTER 3 복합 타입

  • 3.1 배열
    • 제한이 많음
    • 길이마다 다른 타입이고, 배열 크기를 지정하기위한 변수도 사용못함 (타입이라 컴파일 과정에서 반드시 해석되어야함)
    • 그리고 동일한 타입을 가진 다른 크기의 배열간에 타입변환을 할 수 없다 (함수 파라미터 사용불가)
    • 다만 이런 타입을 제공하는건 슬라이스가 배열을 기반으로 구성되어있기 때문
  • 3.2 슬라이스
    • append와 같은 함수의 반환값을 할당하지 않으면 컴파일에러다.
    • call by value로 값을 넘기고 추가된 복사본을 반환하기에 다시 할당해줘야한다.
    • 참고: go runtime은 바이너리에 포함하며, 런타임을 위해 vm등을 설치해야하는 언어가 아님, 그리고 런타임에는 gc나 메모리 할당, 동시성/네트워킹 지원, 내장타입과 함수등이 있다.
    • 슬라이스는 capacity가 있는데 len보다 길 수 있고, go runtime에 의해 관리된다.
    • 어떤 경우에 어떻게 선언하는것이 좋을까?
      • 슬라이스가 전혀 커질 일이 없다면 (함수가 반환안하는 분기) var : var data int[]
      • 시작값이 있는 경우 리터럴 : data := []int{2, 4, 6, 8}
      • 슬라이스가 얼마나 커질지 잘 알지만, 뭐가 들어갈지 모르면 make (다만 make를 이용해서 만들어놓고 append를 하는 경우라면 그게 필요한지 재검토)
    • 슬라이스 슬라이싱은 참조기반
    • 슬라이스를 취할 때 마다 하위슬라이스의 수용력은 원본 슬라이스의 수용력에서 하위슬라이스의 시작 오프셋만큼을 뺀 값이 설정됨

package main

import "fmt"

func PrintHello() {
	x := make([]int, 0, 5)
	x = append(x, 1, 2, 3, 4)
	y := x[:2]
	z := x[2:]
	fmt.Println(cap(x), cap(y), cap(z))
	x = append(x, 30, 40, 50)
	x = append(x, 60)
	z = append(z, 70)
	fmt.Println("x: ", x)
	fmt.Println("y: ", y)
	fmt.Println("z: ", z)
}

/**
  1. 5 5 3 출력:
    - cap(x) = 5: 초기 용량 5로 생성
    - cap(y) = 5: y는 x[:2]로 같은 배열을 참조하므로 용량 5
    - cap(z) = 3: z는 x[2:]로 인덱스 2부터 시작하므로 남은 용량 3
  2. 슬라이스 공유와 재할당:
    - x에 30, 40, 50, 60을 추가하면 용량 초과로 새 배열 할당
    - y와 z는 여전히 원래 배열 참조
    - z에 70 추가 시 원래 배열의 인덱스 4 위치에 저장
  3. 최종 결과:
    - x: [1 2 3 4 30 40 50 60] - 새 배열
    - y: [1 2] - 원래 배열의 처음 2개 요소
    - z: [3 4 70] - 원래 배열의 인덱스 2부터, 70이 추가됨
*/

func main() {
	PrintHello()
}

• 3.3 문자열과 룬 그리고 바이트

• 3.4 맵

• 3.5 구조체

• 3.6 마무리

• CHAPTER 4 블록, 섀도, 제어 구조

  • 4.1 블록
  • 4.2 if 문
  • 4.3 for 문
  • 4.4 switch 문
  • 4.5 공백 switch 문
  • 4.6 if 문과 switch 문 중 선택
  • 4.7 goto 문
  • 4.8 마무리

• CHAPTER 5 함수

  • 5.1 함수 선언과 호출
  • 5.2 함수는 값이다
  • 5.3 클로저
  • 5.4 defer
    • defer 키워드 이후에 함수호출은 return 이후 지연호출
    • 해당 함수는 클로저로 환경을 캡쳐하기에 named return과 함께 유용하게 쓰인다.
      • 변수처럼 named return을 하는데 대표적으로 err
      • defer 지연호출하는 시점에 마지막 err값을 보고 분기를 작성해서 동작시키거나 해당 err를 바꿀수 있다.
      • 그리고 몇몇 표준 라이브러리 함수들은 일부러 클로저를 반환해서 defer 호출을 상기시킨다
      • 마지막으로 여러 defer을 선언해두면 스택순서로 동작한다.
  • 5.5 값에 의한 호출을 사용하는 Go
    • 객체 인스턴스 값을 복사를 해서 전달한다.
    • 그래도 바꿔도 불변
    • 근데 슬라이스같은 애들은 변경이 유효한데 이건 포인터를 넘기기 때문, 정확하게는 슬라이스도 값을 전달하지만 거기에 슬라이스 헤더에 포함된 포인터가 있음
  • 5.6 마무리

• CHAPTER 6 포인터

중요한 설계 철학이 나온다, 처음에는 자꾸 불변성과 관련한 이야기를 같이해서 약간 헷갈렸는데, 기본적으로 값을(복사) 전달하는 구조이기 때문에 불변성을 굳이 지원하지 않는다는 논조로 이해하면 이해가 더 쉽다. 그리고 python, java와 같이 참조에 의한 전달도 지원하지만 그런경우 명시적인 포인터를 전달해야하고, 이러한 상황이라면 문법에 의해 명시적으로 참조를 전달하는 상황 자체가 가변성을 염두에 두고 코드를 작성하도록 만들어져 있기 때문에 마찬가지로 굳이 불필요한 불변성 지원 문법은 필요 없다는 의견이다. 마지막으로 포인터의 전달 역시 실질적으로는 ‘주소 값’을 복사하는 행위이기때문에, 아래의 파이썬 코드 예시와 같이 원본의 참조 자체를 수정하는 위험한일은 발생하지 않도록 되어있다.

class Foo:
    def __init__(self, x):
        self.x = x

def outer():
    f = Foo(10)
    inner1(f)
    print(f.x) # 20 '복사된 참조를 넘기지만 그 참조를 통해 접근하는 메모리상의 값을 바꿈'
    inner2(f)
    print(f.x) # 20 '참조 자체는 복사되어 이런 변경은 의미가 없음'
    g = None
    inner2(g)
    print(g is None) # true '마찬가지'
    


def inner1(f):
    f.x = 20

def inner2(f):
    f = Foo(30)


# Golang도 마찬가지이지만, 포인터를 넘기는 선택지를 준 것
# 그래도 마찬가지로 GC최적화 등을 이유로 값을 넘기는 방식을 먼저 생각할것

• 6.1 빠른 포인터 입문

• 6.2 포인터를 두려워 말라

• 6.3 포인터는 변경 가능한 파라미터를 가리킨다

• 6.4 포인터는 최후의 수단

• 6.5 포인터로 성능 개선

  • 10 메가 이상의 반환값에서 포인터를 사용했을때 성능 개선의 의미가 있다고 한다.

• 6.6 제로 값과 값없음의 차이

  • zero-and-nil

• 6.7 맵과 슬라이스의 차이

  • 맵은 포인터를 넘기는것과 차이가 없음, 좋은 설계는 아니겠지만 맵을 넘겨서 수정하면 의도대로는 동작함
  • 슬라이스는 경우가 다르다. 헤더를 복사하는데 헤더에 capacity, len등의 메타정보가 복사되어 넘겨지므로, append와 같은 수정은 원본을 변경하지 못하고, 원본 capacity내의 데이터의 변경은 일관성이 심각하게 없다.

• 6.8 버퍼 슬라이스

  • 힙할당을 줄이자!

• 6.9 가비지 컬렉션 작업량 줄이기

  • java의 gc는 여러가지 면에서 엄청나게 잘 튜닝되어있어, 일부만 스택에 유지하고 실제 ram(힙)접근하는 방식에 대해서도 성능유지를 잘 해준다.
  • 다만 go는 그정도가 아니고 최대한 heap사용량을 줄이고 스택내에서 치리되도록 관용구들이 유도한다.

• 6.10 마무리

• CHAPTER 7 타입, 메서드, 인터페이스

  • 7.1 Go의 타입
  • 7.2 메서드
    • 값 타입인 지역 변수를 포인터 리시버와 함께 사용하면, Go는 자동으로 지역변수를 포인터 타입으로 변환한다.
    • c.Increment() to (&c).Increment()
    • 문제는 함수로 값을 전달하기 위한 규칙에도 적용되어 주의가 필요하다. 값타입을 함수로 넘기고 넘겨진 값의 포인터 리시버 메서드를 호출하면, 복사본에서 메서드를 호출하는 것이다.
    • nil 리시버에서 메서드 호출은 가능하고, nil check이후에 동작하게 하는 것 자체는 유용하다. 하지만, 보통은 유용하지 않은데, 결국 이것도 포인터 함수 파라미터처럼 동작하기 때문에 파라미터로 전달된 nil과 같이 원본 포인터를 nil이 아닌것으로 처리는 불가능하다는 것이다.
  • 7.3 구성을 위한 임베딩 사용
  • 7.4 임베딩은 상속이 아니다
    • go-embedding
  • 7.5 인터페이스에 대한 간단한 지도
  • 7.6 인터페이스는 타입에 안정적인 덕 타이핑이다
    • go-interface
  • 7.7 임베딩과 인터페이스
  • 7.8 인터페이스를 받고 구조체 반환하기
    • 함수로 실행되는 비즈니스 로직은 인터페이스를 통해 실행되어야 하는 것이지만, 함수의 출력은 구체 타입이어야 한다.
    • 인터페이스를 반환하는 API를 만든다면 암묵적 인터페이스의 주요 장점인 디커플링을 잃게 된다.
    • 버저닝 관점에서도 문제가 많다. 인터페이스의 수정은 모든 구현을 업데이트해야한다.
    • 입력 파라미터에 기반하여 각기 다른 인터페이스의 인스턴스를 반환하는 단일 팩토리 함수보다, 각 구체에 맞는 팩토리 함수를 작성해야 한다.
  • 7.9 인터페이스와 nil
    • go 런타임에서 인터페이스는 기본 타입에 대한 포인터와 기본 값에대한 포인터 쌍으로 구현되어있다.
  • 7.10 빈 인터페이스는 어떤 것도 표현하지 않는다
  • 7.11 타입 단언 및 타입 스위치
  • 7.12 타입 단언과 타입 스위치를 아껴 사용하기
  • 7.13 함수 타입은 인터페이스로의 연결
  • 7.14 의존성 주입을 쉽게 만드는 암묵적 인터페이스
  • 7.15 Wire
  • 7.16 GoO는 특히 객체지향이 아니다
  • 7.17 마무리

• CHAPTER 8 오류

  • 8.1 오류 처리 방법: 기초
    • 굳이 err를 내려주는 이유, 장황해 보여도 명확하다.
    • 명시적 코드상의 if 분기로 처리되게한다. 비즈니스로직은 그렇게 처리되지 않기에 예외처리된다는 것을 직관적으로 인지하기 쉽다.
  • 8.2 단순 오류에 문자열 사용
  • 8.3 센티넬 오류
  • 8.4 오류는 값이다
  • 8.5 오류 래핑
  • 8.6 Is와 As
  • 8.7 defer로 오류 래핑
  • 8.8 패닉과 복구
  • 8.9 오류에서 스택 트레이스 얻기
  • 8.10 마무리

• CHAPTER 9 모듈, 패키지 그리고 임포트

  • 9.1 저장소, 모듈 그리고 패키지
  • 9.2 go.mod
  • 9.3 패키지 빌드
  • 9.4 모듈 관련 작업
  • 9.5 모듈 게시
  • 9.6 모듈 버전 관리
  • 9.7 모듈을 위한 프록시 서버
  • 9.8 마무리

• CHAPTER 10 GO의 동시성

• Goroutines-Brief

  • 10.1 동시성 사용 시점
    • 동시성은 그 자체로 병렬성을 의미하지 않으며, 동시성 코드가 병렬적으로 실행되는지 여부는 하드웨어와 알고리즘이 허용하는지 여부에 따라 다르다.
    • 넓은 의미의 모든 프로그램은 세단계의 처리를 한다.
      • 데이터를 받고,
      • 데이터를 변환하여
      • 결과를 출력한다.
    • 프로그램에서 동시성 사용의 여부는 프로그램에서 단계별 데이터 흐름에 따라 결정된다.
      • 독립적으로 수행 할 수 있는 여러 처리로부터 데이터를 결합시키길 원한다면 동시성을 사용하자
  • 10.2 고루틴
    • 고루틴은 Go 런타임에서 관리하는 가벼운 프로세스이다.
    • Go 프로그램이 실행되면, 런타임은 여러 스레드를 생성하고 프로그램을 실행하기 위해 단일 고루틴을 시작한다
    • 프로그램에서 생성된 모든 고루틴은 초기에 생성된 하나를 포함하여 운영체제에서 CPU코어에 따라 스레드를 스케줄링 하듯이, Go 런타임 스케줄러가 자동으로 스레드들을 할당한다.
    • 기본 OS 시스템이 스케줄링을 알아서 하기에 이게 부가적인 작업으로 보일 수 있지만 몇가지 이점이 있다.
      • 고루틴 생성은 운영체제 레벨 자원을 생성하지 않기에 스레드 생성보다 빠르다.
      • 고루틴의 초기 스택크리는 스레드의 스택 크기보다 작으며 필요하다면 늘릴 수 있다.
      • 프로세스 내에서 이루어지는 고루틴의 전환은 시스템콜로인한 스레드 전환보다 빠르다.
      • 위와 연관되어 스케줄러가 Go 프로세스의 일부로 동작해서 별도의 스케줄링 결정을 최적화 할 수 있다.
  • 10.3 채널
  • 10.4 select 문
  • 10.5 동시성 사례와 패턴
  • 10.6 채널 대신에 뮤텍스를 사용해야 하는 경우
  • 10.7 원자적 연산
  • 10.8 마무리

• CHAPTER 11 표준 라이브러리

  • 11.1 입출력 관련 기능
  • 11.2 시간
  • 11.3 encoding/json
  • 11.4 net/http
  • 11.5 마무리

• CHAPTER 12 컨텍스트

  • 12.1 컨텍스트 소개
  • 12.2 취소
  • 12.3 타이머
  • 12.4 코드에서 컨텍스트 취소 처리
  • 12.5 값
  • 12.6 마무리

• CHAPTER 13 테스트 작성

  • 13.1 테스팅의 기초
  • 13.2 테이블 테스트
  • 13.3 코드 커버리지 확인
  • 13.4 벤치마크
  • 13.5 Go의 스텁
  • 13.6 httptest
  • 13.7 통합 테스트 및 빌드 태그
  • 13.8 레이스 검출기로 동시성 문제 찾기
  • 13.9 마무리

• CHAPTER 14 Reflect, Unsafe, Cgo

  • 14.1 리플렉션은 런타임에 동적으로 타입 제어
  • 14.2 불안전한 Unsafe
  • 14.3 성능이 아닌 통합을 위한 Cgo
  • 14.4 마무리

• CHAPTER 15 Go의 제네릭

  • 15.1 반복 코드를 줄이고 타입 안전 증가
  • 15.2 Go의 제네릭
  • 15.3 타입 목록을 사용하여 연산자 지정
  • 15.4 제네릭 함수는 알고리즘을 추상화한다
  • 15.5 타입 목록은 상수와 구현을 제한한다
  • 15.6 소외된 것
  • 15.7 관용적 Go와 제네릭
  • 15.8 이후 해제될 것들
  • 15.9 마무리