Skip to content

Posting/260528 - #76

Merged
youngduck merged 3 commits into
mainfrom
posting/260528
May 28, 2026
Merged

Posting/260528#76
youngduck merged 3 commits into
mainfrom
posting/260528

Conversation

@youngduck

Copy link
Copy Markdown
Owner

PR전 코드 퀄리티 체크하기

작업내용

작업내용을 간단/상세하게 작성해주세요.

  1. 기존포스팅 오탈자 불필요한백틱 수정
  2. 알고리즘 풀이 포스팅
  3. 알고리즘 패턴 정리 포스팅

🔍 가독성 (Readability) CHECK

명명 규칙

  • 매직넘버를 명명된 상수로 교체했나요?
    • const ANIMATION_DELAY_MS = 300 형태로 의미 있는 이름 사용
  • 복잡한 조건문을 명명된 변수로 분리했나요?
    • const isValidUser = user.age >= 18 && user.isVerified
  • 변수명이 그 자체로 의미를 전달하나요?
    • userDataauthenticatedUser, listactiveUserList

구조 및 구성

  • import문이 절대경로로 정리/정렬되어 있나요?
  • 변수 선언이 컴포넌트 상단에서 이루어지고 하단에서 사용되나요?
  • 위에서 아래로 읽기 쉬운 흐름으로 구성되어 있나요?

추상화 및 분리

  • 복잡한 로직을 전용 컴포넌트/훅으로 추상화했나요?
    • 인증 체크 → AuthGuard 컴포넌트
    • 복잡한 상호작용 → 전용 버튼 컴포넌트
  • 조건부 렌더링이 복잡한 경우 별도 컴포넌트로 분리했나요?
    • ViewerSubmitButton, AdminSubmitButton로 역할별 분리
  • 복잡한 삼항 연산자를 if/else 또는 IIFE로 교체했나요?

🎯 예측 가능성 (Predictability) CHECK

반환 타입 일관성

  • 유사한 기능의 함수/훅이 일관된 반환 타입을 사용하나요?
    • API 훅: UseQueryResult<T, Error> 일관 사용
    • 검증 함수: { ok: boolean; reason?: string } 형태 일관 사용

단일 책임 원칙

  • 함수가 이름에서 암시하는 동작만 수행하나요?
    • fetchBalance()가 로깅 등 부수효과 없이 balance만 반환
  • 숨겨진 사이드 이펙트가 없나요?

명확한 명명

  • 커스텀 래퍼/함수가 고유하고 설명적인 이름을 사용하나요?
    • http.get()httpService.getWithAuth()
    • useModal()useConfirmationModal()

🔗 응집도 (Cohesion) CHECK

도메인별 구성

  • 관련된 코드가 함께 배치되어 있나요?
    • 기능별 디렉토리 구조: domains/user/, domains/product/
  • 매직넘버가 관련 로직 근처에 정의되어 있나요?

폼 응집도

  • 폼 검증 로직이 적절한 수준에서 응집되어 있나요?
    • 필드별 독립 검증 vs 폼 수준 스키마 검증
  • 관련 상태와 로직이 함께 관리되고 있나요?

⚡ 결합도 (Coupling) CHECK

상태 관리 범위

  • 상태 관리가 적절한 범위로 분리되어 있나요?
    • 전역 상태 vs 로컬 상태의 적절한 분리
  • 컴포넌트가 불필요한 상태에 의존하지 않나요?
    • useCardIdQueryParam() 같은 focused hook 사용

Props Drilling 제거

  • Props Drilling이 발생하는 경우 컴포지션 패턴을 사용했나요?
  • 중간 컴포넌트가 불필요한 props 전달을 하고 있지 않나요?

추상화 수준

  • 성급한 추상화를 피하고 적절한 중복을 허용했나요?
    • 서로 다른 유스케이스가 예상되는 경우 별도 구현 고려
  • 추상화가 과도하게 복잡하지 않나요?

📋 추가 CHECK

성능 고려사항

  • 불필요한 리렌더링을 방지했나요?
    • useCallback, useMemo 적절 사용
  • 무거운 연산을 적절히 최적화했나요?

타입 안정성

  • TypeScript 타입이 명확하고 안전하게 정의되어 있나요?
  • any 타입 사용을 최소화했나요?

테스트 가능성

  • 작성된 코드가 테스트하기 쉬운 구조인가요?
  • 순수 함수와 사이드 이펙트가 분리되어 있나요?

문서화

  • 복잡한 로직에 대한 주석이 적절히 작성되어 있나요?
  • 인터페이스나 타입에 대한 설명이 필요한 경우 추가되어 있나요?

🎨 코드 스타일 CHECK

  • 일관된 코딩 스타일을 유지하나요?
  • ESLint/Prettier 규칙을 준수하나요?
  • 불필요한 콘솔 로그나 주석이 제거되었나요?

@youngduck
youngduck merged commit f129617 into main May 28, 2026
1 of 3 checks passed

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds new markdown documentation summarizing problem-solving patterns and LeetCode 206 (Reverse Linked List) solutions in JavaScript, alongside minor formatting updates to LeetCode 98. The reviewer suggested optimizing the second solution for LeetCode 206 to perform an in-place reversal, which reduces the space complexity from O(n) to O(1), and recommended updating the complexity explanation accordingly.

Comment on lines +100 to +116
var reverseList = function (head) {
// input값 없을때 처리
if (!head) {
return head;
}

// 최적화 : 조회하자마자 바로넣으면 뒤집어짐
let current = head;
let newHead = null;

while (current) {
newHead = new ListNode(current.val, newHead);
current = current.next;
}

return newHead;
};

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

현재 작성하신 '내풀이 2차' 방식은 매번 new ListNode를 생성하여 새로운 노드를 메모리에 할당하고 있습니다. 이 방식은 공간 복잡도가 $O(N)$이 되며, 연결 리스트의 장점인 포인터 조작을 통한 제자리(In-place) 연산을 활용하지 못합니다.

기존 노드의 next 포인터만 변경하는 방식으로 구현하면 추가적인 노드 생성 없이 **공간 복잡도 $O(1)$**로 최적화할 수 있습니다. 이 방식이 전형적인 반복문 기반의 연결 리스트 뒤집기 최적화 솔루션입니다.

Suggested change
var reverseList = function (head) {
// input값 없을때 처리
if (!head) {
return head;
}
// 최적화 : 조회하자마자 바로넣으면 뒤집어짐
let current = head;
let newHead = null;
while (current) {
newHead = new ListNode(current.val, newHead);
current = current.next;
}
return newHead;
};
var reverseList = function (head) {
let prev = null;
let current = head;
while (current) {
const nextTemp = current.next;
current.next = prev;
prev = current;
current = nextTemp;
}
return prev;
};

Comment on lines +121 to +122
- 시간 복잡도: O(n) — current로 리스트를 한 번만 순회하며 prepend (1차 대비 순회 횟수·상수 계수 감소)
- 공간 복잡도: O(n) — 보조 배열은 없지만 새 ListNode를 n개 생성 (포인터 변수 current, newHead만 보면 O(1), 노드 할당까지 포함하면 O(n))

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

제자리(In-place) 포인터 역전 방식을 사용할 경우, 추가적인 노드 생성이 없으므로 공간 복잡도를 $O(1)$로 설명할 수 있습니다. 코드 변경에 맞춰 복잡도 설명도 다음과 같이 수정하는 것을 권장합니다.

Suggested change
- 시간 복잡도: O(n) — current로 리스트를 한 번만 순회하며 prepend (1차 대비 순회 횟수·상수 계수 감소)
- 공간 복잡도: O(n) — 보조 배열은 없지만 새 ListNode를 n개 생성 (포인터 변수 current, newHead만 보면 O(1), 노드 할당까지 포함하면 O(n))
- 시간 복잡도: O(n) — 리스트를 한 번만 순회하며 포인터를 변경
- 공간 복잡도: O(1) — 기존 노드의 포인터만 변경하므로 추가적인 메모리를 사용하지 않음

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant