null 리턴은 왜 나쁠까

https://velog.io/@tosspayments/null-%EB%A6%AC%ED%84%B4%EC%9D%80-%EC%99%9C-%EB%82%98%EC%81%A0%EA%B9%8C

요 글은 코틀린 예시를 들고 있지만, 코틀린과 타입스크립트는 둘다 함수가 일급시민인 언어들이어서 타입스크립트에도 적용 가능한 부분이 보여서 정리한다. (사실 코틀린 예제인데 처음에는 ts인줄 알았다)

  • 함수 인자와 달리 리턴값은 하나이다. 따라서 개발자들은 여러 의미를 하나의 값에 담고싶어함. 즉 여러 의미를 하나로 축약하고자 한다.
  • 문제는 이 null 값에 담긴 의미를 모든 개발자들이 이해하기는 어렵다는 것!

개선 방안

  1. 로그에 맥락을 남긴다.

    • 만약에 함수에서 null 값이 리턴되면 해당 함수를 호출한 곳에서 null 의 이유를 볼 수 있도록 로그를 남긴다.

    • 예제를 타스로 바꿔보자면 아래와 같음

      const findByName(name:string):User {
	const result: User | null = db.getUserBy(name);

if(result === null){
	throw Error('왜 Null값이 리턴되었는지에 대한 설명');
}
return result;
}

  2. 맥락 처리를 위한 기능을 만든다.

    • 해당 함수에 인자로 Null 값일 경우 실행할 콜백 함수를 받도록 한다.
    const findByName(name:string, retryHandlerWhenMissing: Function):User {
  	const result: User | null = db.getUserBy(name);

  if(result === null){
  	retryHandlerWhenMissing();
    return;
  }
  return result;
  }

아무튼 둘 다 결론은 null 이 리턴되는 맥락에 대한 처리를 강제한다는 것이고, 이를 해당 함수 사용처에서 알게하므로써 null 이 리턴되는 맥락을 인지 할 수 있겠다.


무중단 배포 전략의 종류

모르는 말들을 정리하자! 😤

1. 롤링 배포

  • 일반적인 배포를 의미한다.
  • 단순하게 서버를 구성하여 배포하는 전략
  • 사용 중인 인스턴스 내에서 새 버전을 점진적으로 교체하는 것 (무중단 배포의 가장 기본적인 방식)
  • 서비스 중인 인스턴스 하나를 로드밸런서에서 라우팅 하지 않도록 한 뒤, 새 버전을 적용하여 다시 라우팅 하도록 함

2. 블루 그린 배포

  • 구버전은 블루/ 신버전은 그린
  • 즉, 신 버전을 배포하고 일제히 전환하여 모든 연결을 신버전을 바라보게 하는 전략
  • 구버전/신버전 서버를 동시에 나란히 구성하여 배포 시점에 트래픽이 일제히 전환된다.
  • 빠른 롤백이 가능하고, 운영환경에 영향을 주지 않고 실제 서비스 환경으로 신 버전 테스트가 가능하다.

3. 카나리 배포

  • 지정한 서버 혹은 특정 user 에만 배포했다가 정상적이면 전체 배포를 진행한다.
  • 서버 트래픽 일부를 신버전으로 분산하여 오류 여부를 확인 할 수 있다.
  • A/B 테스트가 가능하며 성능 모니터링에 유용하다.

Kent C Dodds - next.js 를 사용하지 않는 이유

  • 테스팅 도구 중 RTL 과 enzyme가 있는데 next.js는 enzyme와 비슷하다.
    • enzyme은 렌더된 요소와 상호작용하는 유틸리티가 많은 래퍼를 제공하지만, RTL은 요소 자체만을 제공한다. 즉, RTL은 플랫폼 API 를 감싸지 않고 노출시킨다.
    • next.js는 API와 상호작용하는 유틸리티들(요청,헤더,쿠키 등과 상호작용하는 유틸리티들..) 을 직접적으로 노출시켜버린다.
  • Next.js는 정적 빌드 시간에 문제가 있을 때, 웹 플랫폼의 SWR cache control 을 사용하는 것을 권장하는 대신, ISR 이라는 복잡한 기능을 개발했다. 즉 웹 플랫폼에서 통용되는 방식이 아니라 자체적인 해결 방법을 구축함으로써 타 프레임워크들과 호환이 좋지 못하게 된다.
  • Vercel 배포가 AWS 배포보다 큰 이점이 있는지 모르겠다. 비용도 비싸다.
  • Vercel 은 Next.js와 React 간의 관계를 흐리게 만들어서 사람들을 혼란스럽게 만든다.
  • 실험적인 기능을 안정적인 기능마냥 마케팅하는게 우려스럽다. Next.js가 stable version으로 배포하는 기능들은 React Canary 배포에 포함되어 있는 경우가 있음
  • ’최소 놀람의 법칙’을 어긴다.
    • 최소 놀람의 법칙은 시스템 구성요소는 대부분의 사용자가 예상하는 방식으로 작동해야한다는 법칙.
    • 예를들어 전역 fetch 함수를 오버라이드하여 자동 캐싱을 추가하는 것..

흐음 다 맞는 소리 같다..특히나 버전이 벌써 13버전이고 버전업 주기가 너무 빨라서 이게 안정적인게 맞나 하는 생각도 든다. 😇 점점 Next.js와 리액트의 경계가 모호해지는 문제도 공감한다. 특히나 이렇게 경계가 모호해지니, 개발자들이 직접 Next.js와 타프레임워크와의 호환성을 고려하고 신경써서 개발을 해야한다는 점이 아쉬울 수 밖에 없다. 실제로 복잡한 환경에서 Next.js를 쓰다보면 그게 잘 지켜지지 않는게 일쑤이기도 하고.


안정적인 동료가 되기

서프라이즈 없는 안정적인 동료가 되기

대부분의 상사들은 ‘서프라이즈’를 싫어한다. 작든 크든 조직을 책임지고 있는 사람에게 예측 불가 또는 불확실성만큼 두려운 것이 없다. 그래서 일의 진행 상황을 상사와 공유하는 것이 중요하다.

그냥 핵심은 빠르게 공유하고 물어보기! 빠른 실패와 질문들은 큰 실패를 막는다. 최근에 내가 아직 미숙하고 아키텍쳐가 복잡한 제품의 피쳐를 개발해야하는 일이 생겼는데, 이 때 불안해서 DB에 추가되는 데이터 설계랑 개발 예정인 방법을 문서로 팀내에 공유해서 리뷰를 요청한 적이 있다. 이렇게 하니 내가 몰랐던 부분이나 잘못생각했던 부분을 실제 개발 들어가기 전에 파악 할 수 있었고, 실제로 DB에 해당 데이터를 넣기 전에 고칠 수 있었어서 큰 실수들을 미연에 방지 할 수 있었다. 요런 경험들을 통해서 빠른 공유랑 질문들이 얼마나 중요한지 몸소 깨달을 수 있었다.


마무리

서버 개발 배우기 도전 중 🤔

요즘 Nest.js로 간단한 서버개발을 다시 배우기 시작했다. 한 3년전에 처음 웹프로그래밍을 시작했을 때 서버개발부터 시작했었는데..오랜만에 다시하니 재미있다. 그 때는 다들 Express를 썼는데, 지금은 Nest.js 를 사용하는 것도 감회가 새롭고.

왜 배우기 시작했느냐하면, 이게 아무리 기초적인 서버 지식이 있다고 하더라도 어느정도 깊이가 없으니 백엔드 개발자들과 소통할 때나, 기획에 대한 요구사항을 기술관점에서 파악 할 때 한계가 있는 듯한 느낌을 받았다. 그리고 프론트 개발만 알고 제품을 만드는 것은 제품의 반쪽만 이해하는 것 같았다. 그래서 공부하기로 함! 엄~청 깊이 있는 정도까지는 못나갈지언정 기본적인 DB 구조나 백엔드 아키텍쳐는 이해 할 수 있는 수준은 되고싶다.


아침 러닝 도전 중 🫡

running 날이 추워서..아침 러닝 도전 중!! 재택하는 날 혹은 주말에만 할 수 있을 것 같긴한데 이렇게라도 러닝을 꾸준히 하려고한다. 생각해보니 러닝을 시작하고나서 단 한번도 아침에 달려본 적이 없다. 아침 러닝은 또 아침 러닝만의 매력이 있는 듯! (마주치는 러너들이 뭔가 더 생기 넘치고 기운이 범상치 않음..)