#code-review
노트 15개
Frontend › Architecture
가독성을 높이는 전략읽기 좋은 코드는 한 번에 고려할 맥락이 적고, 위에서 아래로 읽히고, 시각적 배치와 의미적 묶음이 일치한다. 같이 실행되지 않는 코드 분리, 구현 상세 추상화, 로직 종류별 함수 쪼개기로 맥락을 줄이고, 복잡한 조건·매직 넘버에 이름을 붙이고, 시점 이동과 중첩 삼항을 줄이고, 게슈탈트 법칙(근접성·공통 영역·유사성·연속성·폐쇄성)으로 빈 줄·주석·배치·이름을 점검한다.
Frontend › Architecture
변경하기 쉬운 코드의 네 가지 기준좋은 프론트엔드 코드는 변경하기 쉬운 코드다. 가독성·예측 가능성·응집도·결합도 네 기준으로 판단하고, 네 기준은 서로 부딪히므로 상황에 따라 무엇을 우선할지 고른다. 기준별 개선 전략과 자주 논쟁되는 컨벤션, 코드 품질을 챙기는 이유·타이밍·감각 기르는 법을 함께 정리한다.
Frontend › Architecture
예측 가능성을 높이는 전략예측 가능한 코드는 이름·파라미터·반환 값만 보고 동작을 알 수 있다. 라이브러리와 같은 이름으로 다른 동작을 하지 않고, 같은 종류의 함수는 반환 타입을 통일하고(Discriminated Union), 이름에 드러나지 않는 로깅 같은 숨은 로직은 호출부로 꺼낸다.
Computer Science › Programming Languages
좋은 코드를 위한 열 가지 원칙코드 규약 준수, 이유를 남기는 주석, 견고함, SOLID, 테스트하기 쉬운 구조, 적당한 추상화, 과설계 없는 패턴 사용, 전역 의존 줄이기, 지속적인 리팩터링, 보안 우선이라는 열 가지 코딩 원칙을 각각 왜 필요한지와 함께 정리하고, 원칙끼리 부딪칠 때의 판단 기준을 덧붙인다.
Computer Science › Programming Languages
클린 코드: 함수와 이름『클린 코드』의 함수와 이름 규칙을 정리한다. 나쁜 코드가 비싼 이유와 보이스카우트 규칙, 피해야 할 습관도 다룬다. 함수는 작게, 한 가지만, 한 추상화 수준으로 쓰고 위에서 아래로 이야기처럼 읽히게 배치한다. 값을 돌려주는 질의와 상태를 바꾸는 명령은 나눈다(명령-질의 분리). 타입 분기는 팩터리 한 곳에 가두고 나머지는 다형성에 맡기며, 이름은 의도를 드러내고 한 개념에 한 단어만 쓴다.
Computer Science › Programming Languages
C++ 코딩 표준과 clang-formatC++ 프로젝트의 코딩 표준이 무엇을 정하는지(사전·사후 조건, 유지보수, 서식, 이름, 클래스 배치, 문서화, 최적화 힌트)를 한 프로젝트 표준을 예로 정리하고, 서식은 사람이 지키지 말고 clang-format으로 자동화하는 방법을 다룬다.
Tools › Code Review
리뷰 코멘트와 PR 소통의도가 정확히 전달되는 리뷰 코멘트 쓰는 법, PR에서 자주 쓰는 약어(LGTM·IMO·NIT·PTAL), 리뷰를 받는 쪽의 태도와 PR 템플릿.
Tools › Code Review
리팩터링 원칙마틴 파울러 『리팩터링』(2판) 1·2장에서 뽑은 원칙. 리팩터링의 정의, 기능 추가와 리팩터링을 나누는 두 개의 모자, 테스트 먼저, 3의 법칙, 성능은 다듬은 뒤에 챙긴다는 태도를 정리한다.
Tools › Code Review
불리언 변수 이름 짓기불리언 변수 이름을 영어 문법에 맞게 짓는 네 가지 형태(is, 조동사, has, 3인칭 단수 동사)와 흔한 실수(is + 동사원형)를 정리한다. Bool·mutating·nonmutating 함수 이름을 구분하는 법도 함께 다룬다.
Tools › Code Review
삭제하기 쉬운 코드코드는 쓰는 순간부터 유지 비용을 낳는다. 확장성과 재사용을 미리 설계하기보다, 바뀔 가능성을 기준으로 경계를 나눠 나중에 쉽게 버리고 바꿀 수 있게 쓴다. 쓰지 않기 → 복사 → 함수 추출 → 보일러플레이트 허용 → 래퍼 → 덩어리 → 변경 경계 분리의 단계로 정리한다.
Tools › Code Review
코드 리뷰 원칙과 체크리스트코드 리뷰를 왜 하는지(품질이 비용을 낮추는 이유, 리뷰의 다섯 가지 효과), 작성자와 리뷰어가 할 일, 자동화할 것과 사람이 볼 것을 나누는 원칙, 리뷰를 빠르게 돌리고 교착을 푸는 운영법, 가독성·부작용·경계 조건·보안·성능·테스트 체크리스트.
Tools › Code Review
코드 리뷰에서 자주 나온 지적코드 리뷰에서 자주 반복되는 JavaScript·React 코드 지적(const, else, 기본값, 불리언 이름, 빈 문자열 비교, 비동기 에러, 불변 업데이트, props 설계 등)을 고친 코드와 함께 정리.
Tools › Code Review
Simple Design코드 품질을 '가독성'·'깔끔함' 같은 느낌 대신 객관적 기준으로 다루기 위해 켄트 벡의 Simple Design을 '중복이 없으면서 최소한의 문법 요소로 구성된 코드'로 줄여 쓰는 방법. 중복 제거 시점, 비용과의 타협, 본질적 복잡성 다루기, DRY·KISS·YAGNI와의 관계까지 정리한다.
Tools › Git
GitHub 협업 저장소 설정팀 저장소를 처음 세팅할 때 할 일: 협업자·브랜치 보호 규칙·CODEOWNERS·이슈/PR 템플릿(마크다운 템플릿과 YAML 이슈 폼, config.yml)·라벨, 그리고 PR 알림 도구와 기능별 브랜치 습관.
Career › Work
친절한 엔지니어링: 정직, 심리적 안전감, 피드백친절은 예의 바름(nice)이 아니라 상대에게 관심을 쏟아 그가 있는 자리에서 돕는 것(kind)이다. 정직하되 개인적으로 신경 쓰기, 코드 리뷰 같은 비동기 소통에서 '왜'를 묻기, 비난 없는 문화와 실패에서 배우기로 심리적 안전감 만들기, 피드백을 받는 법과 주는 법(감정·신뢰·논리)을 정리했다.