— 소프트웨어 설계의 역설
가장 좋은
설계는
설계를
안하는
것이다
The best design is no design — until it has to be.
// THESIS
우리는 종종 설계에 과잉 투자한다. 아직 존재하지 않는 문제를 위해 추상화를 쌓고, 사용되지 않을 유연성을 위해 복잡도를 감수한다. 진짜 설계의 미덕은 필요한 순간까지 결정을 미루는 용기에 있다. 코드는 오늘의 요구사항에 충실해야 한다. 내일의 상상에 복종해서는 안 된다.
01
YAGNI
필요하면 그때 해라
"You Aren't Gonna Need It." 미래를 위한 코드는 대부분 미래에 쓸모없어진다. 요구사항은 바뀌고, 예측은 빗나간다. 지금 당장 필요한 것만 작성하라.
02
WET → DRY
그러나 순서가 있다
추상화는 반복이 세 번 이상 보인 후에 만들어라. 첫 번째 중복은 용인하고, 두 번째는 주목하고, 세 번째에 정리하라. (Rule of Three)
03
SIMPLICITY
단순함은 기본값이 아니다
단순한 코드는 의도적인 선택의 결과다. 복잡한 설계보다 단순한 설계가 더 많은 사고를 요구한다. 삭제할 용기가 추가할 용기보다 크다.
04
NO PREMATURE
조기 설계는 조기 최적화다
"Premature optimization is the root of all evil." — Knuth. 설계도 마찬가지다. 문제가 실재하기 전에 해결책을 설계하지 마라.
"
완성이란 더 추가할 것이 없을 때가 아니라,
더 이상 뺄 것이 없을 때 이루어진다.
— ANTOINE DE SAINT-EXUPÉRY
// 실전 원칙
→FLAT BEFORE NESTED계층 구조는 복잡도다. 폴더, 클래스, 모듈 — 하나씩 늘릴 때마다 이유를 대라.
→DELETE FIRST, ASK LATER사용되지 않는 코드는 부채다. 주석 처리 말고 삭제하라. Git은 기억한다.
→MAKE IT WORK, THEN RIGHT동작하는 못생긴 코드가 동작하지 않는 아름다운 설계보다 낫다. 순서를 지켜라.
→INTERFACES REVEAL INTENT함수 시그니처와 API 경계만 잘 설계해도 내부 구현의 혼돈은 통제된다.
→BORING IS A FEATURE새로운 패턴, 새로운 라이브러리, 새로운 아키텍처. 팀이 이미 아는 것이 최선일 때가 많다.
// CLOSING
설계는 문제를 이해한 후에 한다. 코드를 먼저 쓰고, 패턴을 발견하고, 그제서야 구조를 만들어라. 설계도를 먼저 그리는 건 건물을 짓기 전에 인테리어를 고르는 것과 같다.
NO
DESIGN
IS THE BEST DESIGN