코드는 한 번 작성되고 수백 번 읽힙니다. 함수를 작성한 개발자가 6개월 후에 해당 함수를 디버깅하거나, 새로운 요구사항에 맞춰 기능을 확장하거나, 운영 환경에서 문제가 발생했을 때 예외 상황을 이해해야 하는 경우는 드뭅니다. 코드를 작성하는 동안 내리는 모든 결정, 변수 이름, 함수의 길이, 클래스 구조 등은 다음에 코드를 읽는 사람의 작업을 더 쉽게 만들 수도 있고 더 어렵게 만들 수도 있습니다. 클린 코드는 이러한 과정을 체계적으로 만들어가는 규율입니다.
클린 코드 라는 개념은 로버트 C. 마틴(일명 "엉클 밥")이 그의 저서 『 클린 코드: 애자일 소프트웨어 장인정신 핸드북』 (2008)에서 정립했으며, 이 책은 현재까지도 클린 코드 분야의 대표적인 참고서로 남아 있습니다. 마틴 파울러의 『리팩토링: 기존 코드 설계 개선』은 기존 코드가 클린하지 않고 개선이 필요한 경우 어떻게 해야 하는지에 대한 보완적인 문제를 다룹니다. 이 두 저서는 클린 코드 실천의 지적 토대를 마련했습니다. 이 가이드는 기업 레거시 시스템을 유지 관리하는 개발자를 위해 RPG 및 PL/I를 포함한 가장 널리 사용되는 언어의 예제를 통해 핵심 원칙을 설명합니다.
눈에 보이지 않는 코드 위반 사항을 깔끔하게 정리하세요
SMART TS XL COBOL, Java, Python, RPG 등 다양한 언어에서 복잡성, 중복 및 사용되지 않는 코드를 찾아냅니다.
더 많은 정보클린 코드란 무엇인가요?
클린 코드란 읽기 쉽고, 이해하기 쉽고, 테스트하기 쉽고, 변경하기 쉬운 소스 코드입니다. 여기서 "쉽다"라는 표현은 매우 중요한 의미를 지닙니다. 컴파일러가 허용하는 코드라고 해서 반드시 클린 코드인 것은 아닙니다. 모든 테스트를 통과한 코드라고 해서 반드시 클린 코드인 것도 아닙니다. 코드가 클린 코드라는 것은, 해당 코드를 작성하지 않은 다른 개발자가, 작성 당시 예상하지 못했던 상황에서도 코드의 의도를 빠르게 이해하고, 자신 있게 수정하고, 예상치 못한 결과 없이 확장할 수 있을 때를 의미합니다.
마틴 파울러의 정의가 가장 많이 인용되는데, "어떤 바보라도 컴퓨터가 이해할 수 있는 코드를 작성할 수 있다. 훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 작성한다."라는 것이다. 깔끔한 코드의 기준은 기계의 실행 능력이 아니라 사람의 이해력이다.
클린 코드는 미적인 측면이나 특정 스타일 가이드를 단순히 따르는 것에 관한 것이 아닙니다. 클린 코드는 향후 변경 사항에 필요한 노력의 양을 결정하는 코드의 구조적 속성에 관한 것입니다. 클린 코드 원칙을 지속적으로 위반하는 코드베이스는 과거의 편법으로 인해 누적되는 비용인 기술 부채를 축적하게 되며, 결국 새로운 기능을 추가할 때마다 기존의 복잡성을 이해하고 신중하게 해결해야 하는 상황에 이르게 됩니다.
클린 코드 원칙: 빠른 참조
로버트 C. 마틴의 클린 코드 원칙은 실행 가능한 지침들의 집합으로 요약할 수 있습니다. 아래 표는 각 원칙을 핵심 규칙 및 해당 규칙이 방지하는 문제와 연결합니다.
| 과학원리 | 핵심 규칙 | 이 문제가 예방하는 바는 무엇일까요? |
|---|---|---|
| 의미있는 이름 | 이름은 의도, 변수, 함수, 클래스를 드러내야 합니다. | 인지적 오버헤드 디코딩이란 무엇인가 x, tmp및 obj 실제로 나타내는 |
| 소규모 함수 | 함수는 한 가지 일을 합니다. 화면에 맞도록 하는 것입니다. | 테스트 불가능하고, 읽기 어렵고, 책임이 뒤섞인 모놀리식 구조 |
| 단일 책임 | 각 수업/모듈에는 변경해야 할 이유가 하나씩 있습니다. | 서로 관련 없는 여러 가지 요소 중 하나라도 바뀌면 무너지는 신급 클래스 |
| DRY(반복하지 마세요) | 모든 지식에는 하나의 표현 방식이 있다. | 버그 수정 사항이 일부 버전에는 적용되었지만 다른 버전에는 적용되지 않았습니다. 논리적 오류가 발생했습니다. |
| KISS (Keep It Simple) | 효과가 있는 가장 간단한 해결책을 선호하세요. | 아무도 겪지 않는 문제를 해결하는 과도하게 복잡한 코드 |
| YAGNI (당신은 그것을 필요로 하지 않을 것입니다) | 필요할 때까지는 기능을 만들지 마세요. | 아무런 이점 없이 복잡성만 추가하는 쓸모없는 투기적 코드 |
| 개방/폐쇄 원칙 | 연장 신청은 가능하지만, 수정은 불가능합니다. | 새로운 동작을 추가할 때 기존 동작을 깨뜨리는 코드 |
| 우려 사항 분리 | 각 장소마다 다른 책임이 있습니다. | 코드를 복잡하게 얽히면 하나를 바꾸면 관련 없는 다른 부분까지 망가지게 됩니다. |
| 댓글을 '무엇을' 묻지 말고 '왜' 묻도록 사용하세요. | 코드는 무엇을 하는지 설명하고, 주석은 왜 그런지 설명합니다. | 시대에 뒤떨어진 댓글들은 유익한 정보보다는 오해를 불러일으키는 경우가 많습니다. |
| 보이스카우트 규칙 | 코드를 처음 발견했을 때보다 더 깔끔하게 정리해 놓고 떠나세요. | 점진적인 방치로 인한 품질 저하 |
클린 코드의 핵심 원칙 설명
건조하게, 반복하지 마세요
DRY 원칙은 시스템 내의 모든 지식 요소가 명확하고 모호하지 않으며 권위 있는 단일 표현 방식을 가져야 한다는 것입니다. 동일한 논리가 여러 곳에 나타나면 표현 방식이 필연적으로 달라지게 됩니다. 비즈니스 규칙 변경은 여러 파일에 걸쳐 검색 및 바꾸기 작업을 필요로 하며, 한 부분이라도 누락되면 버그가 발생합니다.
DRY 원칙은 단순히 코드를 복사해서 붙여넣는 것 이상의 의미를 가집니다. 설정, 문서, 데이터 스키마에도 적용됩니다. 동일한 정보를 두 곳에 저장해야 한다면, 코드를 실제로 복사했는지 여부와 관계없이 DRY 원칙을 위반하는 것입니다.
KISS, Keep It Simple
KISS 원칙은 시스템이 단순할 때 가장 잘 작동하며, 단순성이 설계의 주요 목표가 되어야 한다고 주장합니다. 복잡성은 정교함의 척도가 아니라, 무언가를 더 명확하게 표현할 수 있었음을 보여주는 신호입니다.
실질적인 의미는 다음과 같습니다. 두 가지 해결책이 동일한 문제를 해결할 수 있다면 더 간단한 해결책을 선택하는 것이 좋습니다. 더 복잡한 해결책은 아직 접하지 못한 예외 상황을 처리할 수 있을지도 모릅니다. 하지만 복잡한 코드는 다른 사람들이 이해하기 훨씬 어려워질 것입니다.
YAGNI, 당신은 그것이 필요하지 않을 겁니다
YAGNI 원칙은 필요할 때까지 기능을 추가하는 것을 지양합니다. 이는 미래에 발생할 것으로 예상되는 요구사항을 위해 유연하고 확장 가능한 시스템을 구축하려는 일반적인 경향에 대한 대응책입니다. 가상의 미래 사용 사례를 위해 존재하는 모든 추상화, 인터페이스 및 구성 옵션은 현재 코드를 읽는 모든 개발자에게 인지적 부담을 가중시킵니다.
의미있는 이름
이름은 소스 코드에서 주요한 의사소통 수단입니다. 함수의 이름은 다음과 같습니다. process() 함수 이름은 무엇을 처리하는지, 언제 처리하는지, 무엇을 반환하는지에 대해 아무것도 알려주지 않습니다. calculateMonthlyInterest() 정확하게 전달합니다.
좋은 이름을 고르는 핵심 기준은 다음과 같습니다. 구현 코드를 읽지 않고도 그 이름이 무엇을 나타내는지 알 수 있는가? 이름만으로 목적, 매개변수, 반환 값을 알 수 있는가? 무슨 일을 하는지 설명하기 위해 주석이 필요한가?
소규모 함수
로버트 C. 마틴의 경험 법칙은 다음과 같습니다. 함수는 작아야 합니다. 필요하다고 생각하는 것보다 훨씬 작아야 합니다. 한 가지 기능만 수행하는 함수는 이름을 명확하게 지정하고, 독립적으로 테스트하고, 구현부를 읽지 않고도 이해할 수 있습니다. 하지만 여러 가지 기능을 수행하는 함수는 모든 기능을 동시에 이해해야 합니다.
함수에 적용되는 단일 책임 원칙: 함수는 한 가지 일만 해야 하고, 그 일을 잘해야 하며, 그 외에는 아무것도 하지 않아야 합니다. 만약 함수의 기능을 설명하는 데 "그리고"라는 단어가 필요하다면, 그 함수는 아마도 너무 많은 일을 하고 있는 것일 겁니다.
Java로 깨끗한 코드 만들기
자바의 장황한 표현 방식 때문에 깔끔한 코드 작성 습관이 특히 중요합니다. 언어 자체에서 요구되는 상용구 코드는 제대로 관리하지 않으면 코드의 의도를 가릴 수 있습니다.
자바
// Before: unclear names, mixed responsibilities, magic numbers
public double calc(int x, int y) {
double r = 0;
if (y > 1000) {
r = x * y * 0.1;
} else {
r = x * y * 0.05;
}
return r;
}
// After: meaningful names, single responsibility, named constants
private static final double PREMIUM_DISCOUNT_RATE = 0.10;
private static final double STANDARD_DISCOUNT_RATE = 0.05;
private static final int PREMIUM_THRESHOLD = 1000;
public double calculateDiscount(int quantity, int unitPrice) {
double subtotal = quantity * unitPrice;
return isPremiumOrder(unitPrice)
? subtotal * PREMIUM_DISCOUNT_RATE
: subtotal * STANDARD_DISCOUNT_RATE;
}
private boolean isPremiumOrder(int unitPrice) {
return unitPrice > PREMIUM_THRESHOLD;
}
자바 클린 코드 작성의 핵심 원칙은 다음과 같습니다. 상속보다는 컴포지션을 선호하고, 장황한 반복문 대신 스트림을 사용하여 데이터를 처리하며, 매직 넘버를 명명된 상수로 추출하고, 클래스가 단일 책임에 집중하도록 합니다. 로버트 C. 마틴의 자바 클린 코드 원칙에는 클래스의 크기를 코드 줄 수가 아닌 책임의 크기로 측정해야 한다는 규칙이 포함되어 있습니다.
자바
// Clean Java: streams over imperative loops
List<String> activeUserEmails = users.stream()
.filter(User::isActive)
.map(User::getEmail)
.collect(Collectors.toList());
파이썬으로 깨끗한 코드 만들기
파이썬의 설계 철학인 명시적 표현이 암시적 표현보다 낫고, 단순함이 복잡함보다 낫다는 점은 클린 코드 원칙과 자연스럽게 부합합니다. PEP 8은 파이썬의 공식 스타일 가이드이자 클린 파이썬 코드의 기준입니다.
파이썬
# Before: vague names, long function, no separation
def do_stuff(d):
res = []
for i in d:
if i['a'] > 18:
res.append(i['n'].upper())
return res
# After: meaningful names, separated concerns, Pythonic style
def get_adult_names_uppercase(users: list[dict]) -> list[str]:
return [
user["name"].upper()
for user in users
if user["age"] > 18
]
파이썬
# Clean Python: context managers for resource handling
# Before: manual, error-prone
f = open("data.txt")
data = f.read()
f.close()
# After: guaranteed cleanup, self-documenting intent
with open("data.txt") as f:
data = f.read()
파이썬스러운 깔끔한 코드는 간단한 변환을 위해 수동 루프 대신 리스트 컴프리헨션을 사용하고, 함수 시그니처를 명확하게 설명하기 위해 타입 힌트를 사용하며, 리소스 관리를 위해 컨텍스트 관리자를 사용하고, 구조화된 데이터를 위해 일반 딕셔너리 대신 데이터 클래스 또는 명명된 튜플을 사용합니다.
자바스크립트와 타입스크립트에서 클린 코드를 작성하세요.
자바스크립트의 유연성은 강점인 동시에 클린 코드 작성에 있어 가장 큰 어려움이기도 합니다. 규율이 없다면 자바스크립트 코드베이스는 일관성 없는 패턴, 암묵적인 타입 강제 변환, 복잡하게 얽힌 콜백 체인으로 가득 차게 됩니다.
자바 스크립트
// Before: var, callback hell, no error handling
function getUser(id, cb) {
db.query('SELECT * FROM users WHERE id = ' + id, function(err, rows) {
if (err) cb(err);
cb(null, rows[0]);
});
}
// After: async/await, parameterized query, proper error handling
async function getUserById(userId: number): Promise<User | null> {
const [rows] = await db.execute(
'SELECT * FROM users WHERE id = ?',
[userId]
);
return rows[0] ?? null;
}
타이프 스크립트
// Clean TypeScript: explicit types replace implicit any
// Before
function process(data) {
return data.map(x => x.v * 2);
}
// After
interface DataPoint {
value: number;
label: string;
}
function doubleValues(dataPoints: DataPoint[]): number[] {
return dataPoints.map(point => point.value * 2);
}
Clean JavaScript 사용 const 기본적으로, let 재제본이 필요할 때만, 그리고 절대 안 됩니다. var순수 함수는 동일한 입력이 항상 동일한 출력을 생성하고 부작용이 없으므로 자바스크립트 로직을 구성하는 가장 깔끔한 요소입니다.
C#로 만든 깔끔한 코드
C#은 깔끔하고 표현력 있는 코드를 작성할 수 있는 강력한 기능을 제공합니다. LINQ, 레코드, 패턴 매칭, 널 허용 참조 형식 등 언어의 발전은 지속적으로 더욱 선언적이고 읽기 쉬운 구문을 향해 나아가고 있습니다.
날카로운
// Before: magic numbers, verbose loop, mutable state
public double CalculateTotal(List<OrderItem> items)
{
double total = 0;
foreach (var item in items)
{
if (item.Quantity > 10)
total += item.UnitPrice * item.Quantity * 0.9;
else
total += item.UnitPrice * item.Quantity;
}
return total;
}
// After: named constant, LINQ, single expression
private const double BulkDiscountRate = 0.9;
private const int BulkDiscountThreshold = 10;
public double CalculateTotal(IEnumerable<OrderItem> items) =>
items.Sum(item => item.Quantity > BulkDiscountThreshold
? item.UnitPrice * item.Quantity * BulkDiscountRate
: item.UnitPrice * item.Quantity);
C# 클린 코드 원칙: 캡슐화를 위해 공개 필드 대신 속성을 사용하고, 선언적 데이터 연산을 위해 LINQ를 활용하고, 불변 데이터 구조에는 레코드를 사용하고, 메서드 시그니처에서는 구체적인 형식보다 인터페이스를 선호하고, null 허용 참조 형식을 사용합니다.string? vs string) 널 안전성을 명시적으로 나타내기 위해.
Kotlin으로 클린 코드를 작성하세요
Kotlin은 Java에서 깔끔한 코드를 유지하기 어렵게 만드는 상용구 코드를 줄이는 동시에, 깔끔한 코드를 자연스럽게 지원하는 기능, 데이터 클래스, 확장 함수, null 안전성 등을 추가하도록 설계되었습니다.
코 틀린
// Before: verbose Java-style Kotlin
class User {
var name: String = ""
var email: String = ""
var age: Int = 0
}
fun processUsers(users: List<User>): List<String> {
val result = mutableListOf<String>()
for (user in users) {
if (user.age >= 18) {
result.add(user.email)
}
}
return result
}
// After: idiomatic clean Kotlin
data class User(val name: String, val email: String, val age: Int)
fun getAdultEmails(users: List<User>): List<String> =
users.filter { it.age >= 18 }.map { it.email }
코틀린의 data class equals, hashCode, copy, toString 등의 메서드를 자동으로 제공하여 Java 데이터 클래스를 장황하고 오류 발생 가능성이 높은 코드로 만드는 상용구 코드를 제거합니다. 확장 함수를 사용하면 상속 없이 기존 클래스에 깔끔한 유틸리티 메서드를 추가할 수 있습니다.
RPG 및 PL/I에서의 클린 코드: 레거시 언어, 현대적 원칙
클린 코드 원칙은 전 세계 금융 시스템, 보험 플랫폼, 정부 애플리케이션에서 사용되는 엔터프라이즈 언어를 포함한 모든 언어에 적용됩니다. RPG(Report Program Generator)와 PL/I는 여전히 많은 조직에서 활발하게 유지 관리되고 있으며, 자바나 파이썬을 클린 코드로 만드는 것과 같은 원칙이 RPG와 PL/I의 지속 가능성을 보장합니다.
RPG(ILE RPG)에서 깔끔한 코드 작성하기 :
RPG
// Before: cryptic two-character names, magic numbers
C EVAL D = Q * P * 1.05
C IF Q > 100
C EVAL D = Q * P * 0.95
C ENDIF
// After: meaningful names, named constants, clear intent
/free
dcl-c BULK_DISCOUNT_THRESHOLD 100;
dcl-c BULK_DISCOUNT_RATE 0.95;
dcl-c STANDARD_RATE 1.05;
dcl-proc CalculateOrderTotal;
dcl-pi *N packed(15:2);
quantity packed(7:0) value;
unitPrice packed(9:2) value;
end-pi;
if quantity > BULK_DISCOUNT_THRESHOLD;
return quantity * unitPrice * BULK_DISCOUNT_RATE;
else;
return quantity * unitPrice * STANDARD_RATE;
endif;
end-proc;
/end-free
깔끔한 RPG 플레이를 위한 핵심 원칙: ILE RPG의 자유 형식 사용 (/free가독성을 위해 고정 형식이 아닌 구문을 사용하고, 프로시저 이름을 설명적으로 지정하고, 하드코딩된 값을 명명된 상수로 대체합니다. dcl-c그리고 긴 프로그램을 집중적인 절차로 분해합니다. dcl-proc.
PL/I로 작성된 깔끔한 코드 :
굽히다
/* Before: single-letter names, no structure */
CALC: PROC(X, Y) RETURNS(FLOAT);
DCL (X, Y, R) FLOAT;
IF Y > 1000 THEN R = X * Y * 0.1;
ELSE R = X * Y * 0.05;
RETURN(R);
END CALC;
/* After: meaningful names, named constants, clear intent */
DCL PREMIUM_THRESHOLD FIXED DECIMAL(7) INIT(1000);
DCL PREMIUM_RATE FLOAT INIT(0.10);
DCL STANDARD_RATE FLOAT INIT(0.05);
CALCULATE_DISCOUNT: PROC(QUANTITY, UNIT_PRICE) RETURNS(FLOAT);
DCL (QUANTITY, UNIT_PRICE) FLOAT;
DCL SUBTOTAL FLOAT;
SUBTOTAL = QUANTITY * UNIT_PRICE;
IF UNIT_PRICE > PREMIUM_THRESHOLD
THEN RETURN(SUBTOTAL * PREMIUM_RATE);
ELSE RETURN(SUBTOTAL * STANDARD_RATE);
END CALCULATE_DISCOUNT;
PL/I의 클린 코드 원칙은 현대 언어의 원칙을 반영합니다. 즉, 의미 있는 식별자(PL/I의 31자 제한은 설명적인 이름을 지정하기에 충분합니다), 매직 넘버 대신 명명된 상수, 단일 작업에 집중하는 프로시저, 그리고 ON 조건 시스템을 사용한 명시적인 오류 처리가 그것입니다.
클린 코드 도구 및 정적 분석
코드 리뷰를 통해 클린 코드 원칙을 수동으로 적용하는 것은 필요하지만, 대규모 환경에서는 충분하지 않습니다. 정적 분석 도구는 클린 코드 지표를 자동으로 적용하여 병합 전에 위반 사항을 표시합니다.
| 수단 | 언어 | 이것이 강제하는 것 |
|---|---|---|
| 소나큐브 / 소나클라우드 | 30 개 이상의 언어 | 복잡성, 중복, 코드 스멜, 보안 |
| 체크 스타일 | 자바 | 명명 규칙, 형식, 구조 |
| PMD | 자바, 에이펙스 | 중복 코드, 사용되지 않는 변수, 복잡성 |
| ESLint + typescript-eslint | 자바 스크립트, TypeScript | 스타일, 복잡성, 사용되지 않는 코드, 비동기 패턴 |
| 파일린트 + 라돈 | Python | PEP 8, 복잡성, 유지보수성 지수 |
| 리샤퍼 | C# | 코드 스타일, 중복 코드, 리팩토링 제안 |
| 클리 피 | 녹 | 관용적 표현, 흔히 저지르는 실수 |
| SMART TS XL | COBOL, RPG, PL/I, Java, Python 등 | 언어 간 복잡성, 중복, 사용되지 않는 코드 |
도구에서 측정하는 가장 일반적인 클린 코드 지표는 다음과 같습니다. 순환 복잡도(결정 분기 수, 10 이상이면 경고, 20 이상이면 심각한 문제), 인지 복잡도(코드를 이해하기 어려운 정도, SonarQube에서 사용하는 지표로 가독성 측정에 있어 순환 복잡도를 개선한 것), 중복률(중복된 코드의 비율, 3% 이상이면 주의가 필요함).
방법 SMART TS XL 기업 전체 코드베이스에 걸쳐 클린 코드 준수를 강제합니다.
위에 나열된 클린 코드 도구들은 단일 언어 내에서만 작동합니다. 하지만 자바 서비스, 파이썬 파이프라인, COBOL 배치 프로그램, RPG 모듈, JCL 작업 스트림 등이 공존하는 엔터프라이즈 환경에서는 각 언어의 클린 코드 위반 사항을 동시에 측정해야 하며, 언어 간 구성 요소 간의 관계는 개별 파일 내의 코드 품질만큼이나 중요합니다.
SMART TS XL의 정적 코드 분석 이 도구는 환경 내 모든 언어에 걸쳐 클린 코드 메트릭을 동시에 적용합니다. 순환 복잡도, 중복률, 데드 코드 식별 및 구조적 결합도 메트릭은 Java 클래스와 동일한 방법론을 사용하여 COBOL 프로그램에 대해 계산되므로 전체 애플리케이션 포트폴리오에 걸쳐 비교 가능하고 통합된 품질 측정값을 제공합니다.
영향 분석 기능을 통해 아키텍처 규모에서 클린 코드 위반 사항을 즉시 조치할 수 있습니다. 예를 들어, COBOL 단락이 다른 수십 개의 프로그램과 높은 결합도를 가질 경우, 영향 분석을 통해 리팩토링을 시작하기 전에 어떤 구성 요소가 영향을 받는지 정확하게 파악할 수 있습니다. 이는 대규모 코드베이스에서 팀이 겪는 리팩토링 마비 현상을 명확한 범위가 정의된 구조화된 개선 프로그램으로 전환시켜 줍니다.
애플리케이션 종속성 매핑은 시스템 수준에서 클린 코드의 아키텍처 위반 사항을 식별합니다. 즉, 엔터프라이즈 규모에서 어떤 구성 요소가 '갓 클래스(God Class)'가 되었는지, 순환 종속성이 언어 경계를 넘어 관심사 분리 원칙을 위반하는지, 그리고 동일한 비즈니스 로직이 서로의 존재를 알지 못한 채 여러 시스템에서 독립적으로 구현되었는지 등을 파악합니다. 이러한 언어 간 DRY(Don't Repeat Yourself) 원칙 위반, 즉 동일한 비즈니스 규칙이 COBOL 프로그램, Java 서비스, Python 파이프라인에서 각각 별도로 유지되는 경우는 엔터프라이즈 시스템에서 클린 코드 위반 중 가장 비용이 많이 드는 유형이며, 단일 언어 도구로는 감지할 수 없습니다.
클린 코드 원칙을 적용하는 팀을 위해 레거시 현대화 프로그램 SMART TS XL 리팩토링 전 분석을 제공하여 작업의 효율성을 높여줍니다. 변환 시작 전에 사용되지 않는 코드를 범위에서 제외하고, 가장 복잡한 구성 요소를 식별하여 우선적으로 처리하며, 변경 작업이 시작되기 전에 전체 종속성 그래프를 확인할 수 있습니다.
클린 코드는 개인의 노력이 아니라 팀의 책임입니다.
이 가이드의 원칙들은 설명하기는 쉽지만 유지하기는 어렵습니다. 개별 개발자는 혼자서는 깔끔한 함수를 작성할 수 있습니다. 하지만 진정한 과제는 팀 전체, 시간의 흐름, 그리고 기여자가 바뀌면서 계속 커지는 코드베이스 전체에 걸쳐 깔끔한 코드를 유지하는 것입니다. 이를 위해서는 세 가지가 필요합니다. 모든 구성원이 알고 동의한 공유된 표준, 이러한 표준을 자동으로 적용하는 도구, 그리고 점진적 개선 문화, 즉 보이 스카우트의 법칙을 꾸준히 적용하여 코드의 모든 부분을 처음보다 조금씩 더 깔끔하게 만드는 문화입니다.
로버트 C. 마틴의 표현이 여전히 가장 유용합니다. "깔끔한 코드는 항상 누군가 진심으로 신경 써서 작성한 것처럼 보인다." 누군가 진심으로 신경 써서 작성했다는 증거는 버그가 없다는 것이 아니라, 읽기 쉬운 이름, 명확한 기능, 분명한 구조, 그리고 예상치 못한 문제가 없다는 것입니다. 이러한 요소들이 바로 그 코드베이스를 작업할 가치가 있고, 기여할 가치가 있으며, 성공적인 시스템이 수년간 겪게 될 팀 변경 속에서도 유지 관리할 가치가 있게 만드는 것입니다.


