#clean-code
노트 20개
Frontend › Architecture
가독성을 높이는 전략읽기 좋은 코드는 한 번에 고려할 맥락이 적고, 위에서 아래로 읽히고, 시각적 배치와 의미적 묶음이 일치한다. 같이 실행되지 않는 코드 분리, 구현 상세 추상화, 로직 종류별 함수 쪼개기로 맥락을 줄이고, 복잡한 조건·매직 넘버에 이름을 붙이고, 시점 이동과 중첩 삼항을 줄이고, 게슈탈트 법칙(근접성·공통 영역·유사성·연속성·폐쇄성)으로 빈 줄·주석·배치·이름을 점검한다.
Frontend › Architecture
결합도를 낮추는 전략결합도는 코드를 고쳤을 때 영향이 미치는 범위다. 모듈 결합도의 고전적 6단계 분류(자료~내용)와 높은 결합의 신호를 정리하고, 페이지 전체 쿼리 파라미터를 한 훅에 몰지 않고 책임별로 쪼개고, 앞으로 갈라질 수 있는 코드는 중복을 허용하고, Props Drilling은 조합(children) 패턴으로 먼저 풀고 마지막에 Context를 쓴다. 앱 규모에서는 기능 모듈이 서로를 부르지 않고 퍼사드(샌드박스)와 중재자(앱 코어)를 거치게 한다.
Frontend › Architecture
변경하기 쉬운 코드의 네 가지 기준좋은 프론트엔드 코드는 변경하기 쉬운 코드다. 가독성·예측 가능성·응집도·결합도 네 기준으로 판단하고, 네 기준은 서로 부딪히므로 상황에 따라 무엇을 우선할지 고른다. 기준별 개선 전략과 자주 논쟁되는 컨벤션, 코드 품질을 챙기는 이유·타이밍·감각 기르는 법을 함께 정리한다.
Frontend › Architecture
예측 가능성을 높이는 전략예측 가능한 코드는 이름·파라미터·반환 값만 보고 동작을 알 수 있다. 라이브러리와 같은 이름으로 다른 동작을 하지 않고, 같은 종류의 함수는 반환 타입을 통일하고(Discriminated Union), 이름에 드러나지 않는 로깅 같은 숨은 로직은 호출부로 꺼낸다.
Frontend › Architecture
응집도를 높이는 전략응집도는 함께 수정돼야 할 코드가 항상 함께 수정되는지다. 모듈 응집도의 고전적 7단계 분류(기능적~우연적)와 낮은 응집의 신호를 정리하고, 함께 바뀌는 파일을 도메인 디렉토리에 모으고, 매직 넘버를 상수로 묶어 한쪽만 바뀌는 일을 막고, 폼은 변경 단위에 따라 필드 단위 검증과 스키마 기반 폼 전체 검증 중 하나를 고른다.
Computer Science
프로그래밍 언어와 객체 지향 설계언어 일반(계보·패러다임·실행 방식·의미론·타입 시스템), C++의 문법·템플릿·STL·예외·가상 함수·스마트 포인터·메모리 풀, Java·Kotlin·Python·Go의 언어 동작과 관용구, 추상 클래스·인터페이스·위임·DTO/VO·클린 코드·GoF 패턴·책임 주도 설계와 객체 지향 설계 사례 모음.
Computer Science › Programming Languages
좋은 코드를 위한 열 가지 원칙코드 규약 준수, 이유를 남기는 주석, 견고함, SOLID, 테스트하기 쉬운 구조, 적당한 추상화, 과설계 없는 패턴 사용, 전역 의존 줄이기, 지속적인 리팩터링, 보안 우선이라는 열 가지 코딩 원칙을 각각 왜 필요한지와 함께 정리하고, 원칙끼리 부딪칠 때의 판단 기준을 덧붙인다.
Computer Science › Programming Languages
클린 코드: 함수와 이름『클린 코드』의 함수와 이름 규칙을 정리한다. 나쁜 코드가 비싼 이유와 보이스카우트 규칙, 피해야 할 습관도 다룬다. 함수는 작게, 한 가지만, 한 추상화 수준으로 쓰고 위에서 아래로 이야기처럼 읽히게 배치한다. 값을 돌려주는 질의와 상태를 바꾸는 명령은 나눈다(명령-질의 분리). 타입 분기는 팩터리 한 곳에 가두고 나머지는 다형성에 맡기며, 이름은 의도를 드러내고 한 개념에 한 단어만 쓴다.
Computer Science › Programming Languages
C++ 코딩 표준과 clang-formatC++ 프로젝트의 코딩 표준이 무엇을 정하는지(사전·사후 조건, 유지보수, 서식, 이름, 클래스 배치, 문서화, 최적화 힌트)를 한 프로젝트 표준을 예로 정리하고, 서식은 사람이 지키지 말고 clang-format으로 자동화하는 방법을 다룬다.
Computer Science › Programming Languages
GoF 디자인 패턴객체 지향 설계에서 반복되는 문제의 검증된 해법인 GoF 디자인 패턴을 생성·구조·행위 세 갈래로 나눠, 패턴마다 푸는 문제와 한 줄 비유로 정리한다. 패턴은 어휘이자 도구이며, 필요 없는 곳에 쓰면 오히려 복잡도를 늘린다.
Computer Science › Programming Languages
Java 코딩 컨벤션: Google 스타일과 캠퍼스 핵데이 규칙Java 코드 스타일의 대표 기준인 Google Java Style Guide와 네이버 캠퍼스 핵데이 Java 컨벤션을 항목별로 비교하고, 이름 규칙·import·중괄호·줄 길이·Javadoc 같은 공통 원칙과 Checkstyle·EditorConfig·포매터로 규칙을 자동 적용하는 방법을 정리한다.
Computer Science
소프트웨어 복잡성: 본질적 복잡성과 우발적 복잡성큰 소프트웨어를 만들기 어려운 근본 원인은 이해하기 어렵다는 것, 곧 복잡성이다. 문제 자체에 있는 본질적 복잡성과 도구·설계가 덧붙인 우발적 복잡성을 나누고, 복잡성의 주원인인 상태·제어 흐름·코드 양, 「단순함(simple)」과 「쉬움(easy)」의 차이와 얽힘(complect), 피하고(avoid) 분리하라(separate)는 처방을 정리한다.
Computer Science
소프트웨어 비대화하드웨어가 빨라진 만큼 소프트웨어가 느려지고 커져서 사용자가 체감하는 속도는 그대로인 현상. 「개발자 시간이 더 비싸다」는 논리로 쌓인 의존성·계층·임시방편이 원인이다. 효율을 기본값으로 두고, 의존성을 아끼고, 증상이 아니라 원인을 고치고, 재현 가능하게 만든다.
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와의 관계까지 정리한다.
Career › Product
기술 부채기술 부채는 지금 빠른 길을 택한 대가로 나중에 치르는 추가 작업이다. 원금(고치는 비용)과 이자(고치지 않아 매번 더 드는 비용)로 생각하고, 파울러의 사분면으로 원인을 나누며, 백로그 항목으로 보이게 만든 뒤 이자가 큰 곳부터 갚는다.