CHAPTER 5. 더 좋은 액션 만들기

좋은 액션이란 무엇일까? ⇒ 하나의 일만 하면서 이해하기 쉬운 것!

  1. 원칙 : 암묵적 입력과 출력이 적을수록 좋습니다.
    • 암묵적 입력과 출력이 있는 함수는 다른 곳에 영향을 주기도 하고, 언제든 실행할 수 없기 때문에 테스트 하기도 어렵습니다. 암묵적 입출력을 줄여 다양한 환경에서 재사용하고 테스트를 쉽게 만들 수 있습니다.
  2. 원칙 : 설계는 엉켜있는 코드를 푸는 것입니다.
    • 함수를 사용하여 관심사를 자연스럽게 분리할 수 있습니다. 크고 복잡한 것이 더 잘 만들어진 것 같다고 느낄수 있습니다. 하지만 분리된 함수들은 언제든 쉽게 조합할 수 있습니다. 오히려 잘 분리하는 방법을 찾기가 어렵습니다.
    • 엉켜있는 코드를 풀어 각 함수가 하나의 일만 하도록 하면, 개념을 중심으로 쉽게 구성할 수 있습니다.
      1. 재사용하기 쉽다
        • 함수는 작으면 작을수록 재사용하기 쉽습니다.
      2. 유지보수하기 쉽다.
        • 작은 함수는 쉽게 이해할 수 있고, 유지보수하기 쉽습니다. 코드가 작기 때문에 올바른지 아닌지 명확하게 할 수 있습니다.
      3. 테스트하기 쉽다
        • 작은 함수는 한가지 일만 하기 때문에 한가지만 테스트 하면 됩니다.
  3. 의문점 : 원칙을 지키면서 코드 라인이 늘어났는데 괜찮을까요?
    • 짧은 코드도 좋은 코드라고 할 수 있지만, 가장 좋은 코드는 이해하기 쉬운 코드라고 생각합니다. 이해하기 쉬운 작은 함수를 사용하고, 암묵적인 입출력을 제거하여 읽기쉽고 독립적으로 코드를 짤 수 있다면, 코드 라인수가 중요하지 않다고 생각합니다.



CHAPTER 6. 변경 가능한 데이터 구조를 가진 언어에서 불변성 유지하기

  • 불변성을 지켜야하는 이유는 무엇일까요? (리액트 기준으로 생각해보기)
    1. 효율적인 상태 업데이트 (얇은 비교 수행)
      • 얇은 비교란 객체의 프로퍼티를 하나하나 다 비교하지 않고, 객체의 참조 주소값만 변경되었는 지 확인합니다. 얇은 비교는 계산 리소스를 줄여주기 때문에 리액트는 효율적으로 상태를 업데이트 할 수 있습니다.
    2. 사이드 이펙트 방지 및 프로그래밍 구조의 단순성 증가
      • 불변성을 특징으로 가진 원시타입과 달리 객체나 배열의 경우 값을 변경할 때 원본 데이터가 변경될 여지가 있어 불변성이 지켜지지 않을 수 있습니다. 이렇게 원본 데이터가 변경될 경우, 이 원본데이터를 참조하고 있는 다른 객체에서 예상치 못한 오류가 발생할 수 있습니다. 프로그래밍의 복잡도 또한 올라갑니다.
  • 동작을 읽기, 쓰기 또는 둘 다로 분류해봅니다.
    • 읽기 : 데이터를 바꾸지 않고 정보를 꺼내는 것, 데이터를 바꾸지 않음
    • 쓰기 : 어떻게든 데이터를 바꾸는 것
  • 아래는 카피 온 라이트 원칙을 이용하여 쓰기를 읽기로 바꾼 예시입니다. 원본 데이터인 array를 수정하지 않습니다. 작은 함수를 읽기로 수정하면 책임을 확실하게 분리할 수 있다는 장점이 있습니다.
const add_element_last(array, element) => {
	const new_array = array.slice(); //복사본 만들기
	new_array.push(element) //복사본 변경하기
	return new_array; //복사본 리턴하기
}

카피 온 라이트의 원칙

  1. 복사본 만들기
  2. 복사본 변경하기
  3. 복사본 리턴하기