JIGGAG

6월 한달동안 로그

2025년 7월 29일

코드 품질 개선 기법 15편: 문법은 이름을 나타낸다

  • 특징을 앞에 명시하여 이름을 읽을때 빠르게 의도를 알 수 있도록 한다
  • 여러 수식어를 붙여야하는 상황에서 수식어가 의도와 다르게 전달될 수 있다
    • 전치사까지 활용하여 의미 전달
    • 전 잘 모르는겠는데 🙈
  • 사용하는 입장에서 잘 이해할 수 있는지

좋은 사이드 프로젝트가 주는 행복한 선

  • 게임 컨트롤러를 5분 이상 잡고 있으면 시간을 낭비하는 것 같음
    • 무언가 새로운 것을 만들고 싶지만 두려움이나 자신감 부족 때문에 미루고 있었음
  • 어떤 기술 스택이든 상관없이 중요한 건
    • 무언가를 시작했다는 사실
  • 사이드 프로젝트가 주는 자유
    • 외부의 소음 없이 내면의 목소리에 귀 기울일 수 있음
    • 반드시 완성되거나 누군가에게 보여줘야 할 필요 없음
  • 사이드 프로젝트와 취미 프로젝트에서 즐거움을 찾음
  • 이러한 글에 감명을 받지만 아직도 미루고 있는 것은
    • 나는 이미 행복한걸지도 👍

(번역) 한 번의 왕복 요청으로 이루어지는 내비게이션

  • 다른 페이지로 이동하려면 몇 번의 요청이 필요할까요?
  • 페이지를 그리기 전에 필요로 하는
    • 스크립트 로드 + 이미지 요청 등
    • 여러번의 요청이 필요할 수 있다
    • 이러한 페이지를 구성하는데 필요한 요청이 모두 응답 완료되기 까지 페이지는 딜레이 된다
  • 먼저 그려두고 요청하는 방법은?
    • 페이지로 먼저 이동 하고
    • 데이터 패치 한다
    • 그리고 데이터 로딩 과정에서 필요한 UI를 노출한다
  • 요청해야할 것들이 많다면?
    • 모든 요청에 대한 처리를 기다려야하는데
    • 이걸 병렬로 처리하여 마치 한번을 기다리는 것처럼 할 수 있다
    • 요청과 응답 속도가 아무리 빨라지더라도
    • 요청 자체의 횟수가 줄어드는 것은 아니다
  • gql 에서 여러 요청을 조합한 한번의 쿼리 요청을 하여
    • 단 한번의 요청으로 줄일 수 있다
    • REST, 쿼리 캐시 등
    • 속도를 빠르게 하기 위한 방법이 있는데
    • gql처럼 rest 에서도 한번에 조합해주는 요청을 만들면 되지 않나 싶은데
    • rest 의도에 어긋나버리니
    • 의도와 요구 사항을 모두 생각하면 gql 인가보다
  • 최종적으로는 서버 컴포넌트를 사용하여
    • 페이지가 작성됨과 동시에 데이터 요청도 진행하여
    • 요청을 한번에 처리하는 것을 이야기 하고 있다
  • 리액네에선 서버 컴포넌트가 어떻게 될까 싶은데

[번역] 클린 코드의 심리학: 우리가 지저분한 리액트 컴포넌트를 작성하는 이유

  • 처음에는 항상 깔끔하다
    • 단순하게 작은 역할을 하고 있다
  • 시간이 흐른다
    • 마감일정이 다가왔을지도 모르겠다
    • 점점 추가되는 기능에 복잡도는 올라가며
    • 단순했던 컴포넌트는 점점 다양한 일을 하고 있다
  • 리뷰를 한다
    • 분명 이건 좀 더 개선하면 좋겠지 싶은 것들은
    • 핑퐁 하며 흘러가는 시간에
    • 어쩔 수 없지 하며 넘어가는 것들이 하나둘 생기기 마련이다
  • 아차 누락된 것을 발견했다
    • 이미 어느정도 자리 잡은 것들을 바꾸기엔 너무 위험하다
    • 개선할 여지가 있는 것들은 투두로 남겨두고 아쉬운대로 추가한다
  • 이것들은 부채가 되리라는 것을 알면서도 살아남는다
  • 심리적 편향이라고 표현한 것
    • 머리로는 안된다는 것을 알고 있지만 마음으로 어쩔 수 없다며 다독여본다