[Clean Code] 독후감 및 정리 - 1

개발자 필독서 Clean Code

들어가기 앞서 (다시 읽기에 앞서)

며칠 전 한 면접을 보게 되면서, "좋은 코드 가독성이라는 것을 어떻게 생각하세요 ?" 라는 질문을 받았습니다.
평소에 지키는 클린 코드라고 생각한 방법들(좋은 함수 명명법, 변수명, 보기 좋은 코드...등등) 만 주욱 나열하고
"네 뭐 그런 클린코드에 나온 방법들입니다." 라는 말로 그대로 끝난 경험이 있습니다. 🥲

사실 클린 코드 책을 읽은지 오래되기도 했고, 아마 이 책을 처음 접했던 날은 2020년쯤이었던 것으로 기억합니다. 생각처럼 명쾌하지 못하게, 기억나는 대로 더듬더듬 이야기했던, 그런 유쾌하지 못한 경험을 하게 되었네요. 역시 기억보다는 기록인가 봅니다. 그래서 이젠 제대로 정리하여 명쾌하게 이야기할 수 있도록 글로 남기고자 합니다.

이 책을 통해 좋은 코드 가독성이라는 것이 무엇일까 다시 한번 심도 있는 고민을 하며, 다시 읽어보며 이전에 놓쳤던 부분도 되돌아보고자 합니다. 특히 깨끗한 코드를 쓰는 방법이라는 것에 집착해서 정작 숲을 보지 못하고 나무만 깎아내고 있었던 자신을 반성하면서요.
다음에 좋은 코드 가독성이란 무엇인지를 소신껏(밥 형님의 팀을 빗대어) 자신 있게 얘기할 수 있는 그런 사람이 되려고 합니다. 😉

 

---

이 글은 1장 깨끗한 코드, 2장 의미 있는 이름, 3장 함수의 내용을 포함하고 있습니다.
다음 장은 다음 글로 이어집니다.

 

들어가면서

이 책은 원칙만 가르치고 끝내는 책이 아닙니다. 클린 코드를 작성하는 법은 원칙과 패턴이 아니라, 연습과 실패에서 나온다고 명시하고 있습니다. 결정을 내릴 때 충분히 고민하고, 때로는 잘못된 결정을 통해 대가를 치르는 것도 클린 코드의 길이라고 설명하고 있습니다.

책은 세 부분으로 나눠 볼 수 있습니다.
첫째는 원칙과 패턴, 실기를 설명합니다.
둘째는 여러 연구 사례를 통해 문제 있는 코드를 덜 문제 있는 코드로 만드는 과정을 다룹니다.
셋째는 결말입니다. 사례 연구를 만들며 분석 정리를 통한 휴리스틱, 냄새로 정리하는 방식으로, 짜고, 읽고, 정리하는 관점에 대한 사고방식을 묘사한 지식 기반을 구축한 것을 보여준다고 합니다.

 

---

1장 깨끗한 코드

 

나쁜코드

나쁜코드에 대한 일례로 시작합니다. 앱이 망하고 결국 회사가 망하는 예로 시작하며, 나쁜 코드가 기업과 개발자에게 얼마나 큰 장애물이 되는지 경고합니다. 나쁜 코드를 작성한 이유는 무엇일까요? 급해서, 서두르느라, 제대로 작성할 시간이 없어서. "일단 다 짜두고 나중에 정리하겠다"는 안일한 마음가짐도 그 원인입니다. 여기서 "나중은 절대 오지 않는다"는 르블랑의 법칙을 떠올리게 됩니다.

나쁜 코드가 쌓이면 생산성이 0에 수렴하는 순간이 옵니다. 깨끗한 코드를 작성하려는 노력이야말로 장기적으로 비용을 절감하는 길이자, 전문가로 살아남는 법임을 책은 강조합니다.

 

태도

나쁜코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 것은 전문가 답지 못하다.

 

원초적 난제

빨리 가려고 나쁜코드를 그대로 두고 쌓아가는 것은 오히려 엉망진창인 상태로 계속되어 속도가 늦어지고, 기한을 놓치게 합니다.
빨리 가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관을 들이는 것입니다. 바르게 가는 것이 유일한 방법입니다.

 

깨끗한 코드란?

1. C++의 창시자 비야네 스트롭스트룹은 코드가 효율적이며 우아해야 한다고 말합니다. 여기서 효율은 단순히 속도만을 의미하지 않습니다. 그는 바람직하지 못한 기능을 수행하는 것을 '유혹'이라고 표현하며, 나쁜 코드가 나쁜 코드를 유발하는 유혹임을 경계해야 한다고 설명합니다. 다른 유명 프로그래머들 역시 깨진 창문 이론에 비유하며 나쁜 코드의 경계에 대해 강조합니다. 비야네는 철저한 오류 처리를 중요시하며, 메모리 누수(Leaks), 경쟁 조건(Race Condition), 일관된 네이밍과 같은 요소들을 예로 듭니다. 그는 마지막으로 깨끗한 코드는 한 가지 일을 잘한다고 단언합니다.
2. 설계자의 의도가 명확하게 드러나야 하며, 추측이 아닌 사실에 기반해 필요한 내용만을 담아 단호한 인상을 주어야 합니다.
3. 가독성이 높고, 다른 사람이 수정하기 쉬우며, 테스트 케이스가 포함된 코드여야 합니다. 테스트 케이스가 없다면 아무리 우아하고 가독성이 높더라도 클린 코드라 할 수 없음을 강조하고 있습니다.
4. 주의 깊게 작성된 코드여야 합니다.
5. 중복이 없고 표현력이 높은 코드, 한 가지 기능만 수행하는 코드, 간결하게 추상화한 코드가 깨끗한 코드의 기준입니다.
6. 우리는 새 코드를 작성할 때 기존 코드를 자주 읽습니다. 읽는 시간은 코드를 작성하는 시간 대비 10배에 육박합니다. 그만큼 읽기 쉬운 코드를 작성해야 하며, 급하거나 서둘러 끝내야 한다면 더욱 읽기 쉽게 작성해야 합니다.

 

보이스카우트 규칙

캠프장은 처음 왔을 때보다 더 깨끗하게 해 놓고 떠나라.

지속적인 개선이야말로 전문가 정신의 본질임을 강조하고 있습니다.

 

결론

예술에 대한 책을 읽는다고 해서 예술가가 되는 것은 아닙니다. 책은 다른 예술가들이 사용하는 도구와 기법, 그리고 그들의 사고방식을 소개할 뿐입니다. 이 책도 마찬가지입니다. 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없습니다. '코드 감각'을 확실히 얻는다는 보장도 없습니다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐입니다. 다양한 경험적 교훈과 체계, 절차, 기법도 열거합니다. 예제도 무수히 많이 보여줍니다. 나머지는 여러분에게 달렸습니다.

 

1장을 읽고 나서

깨끗한 코드라는 개념은 사실 어떤 누구의 관점에서 보느냐에 따라 다양하게 해석될 수 있다고 생각합니다. 책에서만 봐도 벌써 6가지의 깨끗한 코드의 조건들이 나열되어 있는 것을 보니, 그 정의가 한 가지로 고정되지 않음을 알 수 있습니다. 전부 다 일 수도 있습니다.

1장을 읽고 나서 제가 생각한 클린 코드는 한 가지에 집중하는 코드입니다. 너무 많은 일을 하려다 보면 코드의 의도가 뒤섞이고 목적이 흐려질 수 있기 때문에, 이를 경계하는 것이 중요하다고 느꼈습니다.

1장의 결론을 보며 "나머지는 여러분에게 달렸다."는 글귀를 보며, 왜 이 책이 개발자들에게 필독서로 평가받는지 다시금 깨달았습니다. 저 또한 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교, 도구를 보며 그들의 다양한 경험적 교훈과 체계, 절차, 기법을 통해 제 프로그래밍에 대한 견식이 조금 더 넓어지기를 기대합니다.

 

---

 

2장 의미 있는 이름

2장에서 말하는 네이밍 규칙은 각자 사용하시는 언어의 API 가이드라인을 같이 보시는 게 현명한 선택입니다.
예시로 Swift API Design Guidelines을 가져왔습니다. 궁금하시면 한번 봐보세요. 😊

의도를 분명히 밝혀라

2장을 관통하는 섹션입니다. 코드가 무엇을 하는지 쉽게 짐작할 수 있게 만드는 것입니다.

 

그릇된 정보를 피하라

‘l’이나 ‘o’ 같은 헷갈리는 글자는 사용하지 말고, List를 사용하지 않는데 이름에 ‘List’를 포함하지 마세요. 코드를 읽는 사람이 프로그래머임을 잊지 마세요.

 

의미 있게 구분하라

널리 쓰이는 이름이나 비슷한 이름을 피하고, 의미 있는 구분을 주어야 합니다.

 

발음하기 쉬운 이름

프로그래밍은 사회적 활동입니다. 발음하기 쉬운 이름을 사용하여 팀 내에서 자연스럽게 소통해야 합니다.

 

검색하기 쉬운 이름

검색하기 쉬운 이름을 사용하고, 상수값을 직접 사용하기보다 의미 있는 이름을 부여하는 것이 좋습니다.

 

인코딩을 피하라

헝가리안 표기법과 같은 인코딩은 피하세요. 접두어는 의미가 없습니다. 만약 인터페이스와 구현 클래스 중 하나에 인코딩을 해야 한다면, 구현 클래스 이름을 선택하는 것이 좋습니다. 예를 들어, ShapeFactoryImp가 더 적절합니다.

 

자신의 기억력을 자랑하지 마라

루프에서 반복 횟수 변수로는 i, j, k 등의 인덱스를 전통적으로 사용하지만, 그 외에는 의미 있는 이름을 사용하여 다른 사람들이 이해할 수 있는 코드를 작성해야 합니다.

 

클래스 이름

명사나 명사구를 사용하고, Manager, Processor, Data, Info 등은 피하며 동사는 사용하지 않습니다.

 

메서드 이름

동사나 동사구를 사용하여 이름을 정합니다. 예시로는 postPayment, deletePage, save가 있습니다.
Accessor, Mutator, Predicate의 경우 get, set, is를 붙입니다.

이 글에서 등장한 자바의 표준 때문에 2장 시작에 첨언을 하였습니다. Swift에서는 getter, setter을 붙이는 것을 지양하고 있습니다. 
저도 어느 정도 동감하는 편입니다. 각자의 프로그래밍 패러다임에 맞춰 코드를 작성하는 것도 요령이라고 생각합니다.
Github - amomchilov
Medium - Ranga C

 

기발한 이름은 피하라.

특정 문화에서만 사용하는 농담은 피해야 합니다.

 

한 개념에 한 단어를 사용하라

메서드 이름을 클래스마다 다르게 사용하지 않도록 합니다.
예를 들어 fetch, retrieve, get 같은 메서드를 일관되게 사용하는 것이 좋습니다.
controller, manager, driver를 혼용하는 것도 피합니다.

 

말장난을 하지 마라

add라는 단어가 +의 개념으로 갔으면, Array에 요소 추가를 add가 아닌 append 등으로 해야 합니다.

 

Solution 영역에서 가져온 이름을 사용하라 (해법 영역)

코드를 읽을 사람도 프로그래머라는 사실을 명심해야 합니다. Domain영역에서 가져오는 정책은 현명하지 못합니다.
Solution 영역에서 익숙한 용어를 사용하면 이해를 돕습니다. 
예를 들어 accountVisitor라는 이름은 Visitor 패턴에 익숙한 프로그래머라면 쉽게 이해할 수 있습니다.

 

Domain 영역에서 가져온 이름을 사용하라 (문제 영역)

적절한 프로그래밍 용어가 없다면 문제 영역에서 이름을 가져와야 합니다. 분야 전문가에게 의미를 물어 파악할 수 있고, Domain 영역 개념과 관련이 깊다면 그대로 Domain에서 가져와도 됩니다. 어차피 숙련된 프로그래머라면 Solution과 Domain의 차이 정도는 구분합니다.

 

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름을 사용해야 합니다. state를 단독으로 쓰면 무엇을 의미하는지 한 번에 파악할 수 없습니다. addrState라고 쓰면 맥락이 분명해진다. 

 

불필요한 맥락은 피해라

의미가 분명한 경우에 한해 짧은 이름이 긴 이름보다 좋습니다. 불필요한 맥락을 추가하지 않도록 주의해야 합니다.

 

결론

좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 합니다. 이것이 제일 어렵다고 합니다. 좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아닌 교육 문제입니다. 우리 분야 사람들이 이름 짓는 방법을 제대로 익히지 못하는 이유가 바로 여기에 있다고 말하고 있습니다. 이 장에서 소개한 규칙 몇 개를 적용해 코드 가독성이 높아지는지 살펴보라고 합니다. 다른 사람이 짠 코드를 손본다면 단기적인 효과는 물론 장기적인 이익도 보장한다고 책에서 이야기하고 있습니다.

 

2장을 읽고 나서

제가 느낀 2장은 생각보다 개인별, 회사별, 언어별로 달라질 수 있는 내용이 많았습니다. 결론에서 말하는 ‘교육’이란 결국 자신이 속한 도메인과 솔루션에 맞춰 통일된 매뉴얼을 정하고 이를 교육으로 습득할 수 있다는 점을 의미하는 것 같았습니다.

그럼에도, 가독성 있는 코드를 작성하는 방법을 제시해 주었다는 점에서 읽을 가치가 충분했습니다. 이 글을 읽으며 저도 저 자신을 돌아보고, 혹시라도 잘못된 방식으로 코드를 작성하고 있는 부분이 없는지 경계하고 생각해 볼 수 있었습니다. 그런 점에서 이 장은 나름의 의미가 있는 장이었습니다.

 

 

---

 

3장 함수

 

작게 만들어라

최대한 작게 만듭니다. 2,3,4 줄로 짧게 쓰는 것이 좋습니다. 한 함수에서 들여 쓰기 수준은 한 두 단계 정도로 제한하는 것이 이상적입니다.

 

한 가지 일만 해라

함수는 오직 한 가지 일만 해야 하며, 그 일을 잘해야 합니다. 여기서 ‘한 가지’란 단순히 하나의 연산이 아니라, 추상화된 한 단계를 의미합니다. 예를 들어 1 + 2 * 3 % 4는  +, *, % 연산 3가지 일을 하는 것이 아닌, ‘연산’이라는 추상화된 한 가지 개념을 담고 있는 것입니다.

 

함수 당 추상화 수준은 하나로

한 함수 내에서 서로 다른 추상화 수준을 섞지 말아야 합니다. 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈리게 됩니다. 특정 표현이 근본 개념인지 아니면 세부사항인지 구분하기 어려워지기 때문입니다. 이렇게 되면 점차 세부사항이 추가되면서 깨진 창문처럼 복잡도가 높아질 위험이 있습니다.

 

내려가기 규칙

각 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 오도록 작성합니다. 이렇게 하면 코드가 위에서 아래로 읽히면서 추상화 수준이 점진적으로 낮아지는 일관성을 유지할 수 있습니다.

 

Switch 문

switch 문은 작게 작성하기 어려운 특성이 있습니다. SRP(단일 책임 원칙)와 OCP(개방-폐쇄 원칙)를 위반할 가능성이 있으므로 주의가 필요합니다. 다형성을 이용해 필요한 경우 switch 문을 감추는 것이 좋으며, 주로 다형적 객체를 생성하는 코드나 추상 팩토리 패턴 내에만 switch 문을 사용하는 것이 바람직합니다.

 

서술적인 이름을 사용하라

코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불려도 됩니다. 이름이 길어도 괜찮습니다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋습니다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋습니다. 

이름은 코드가 수행하는 일을 정확히 나타내야 하며, 길더라도 서술적이고 의미 있는 이름을 사용하는 것이 좋습니다. 함수 이름은 여러 단어로 구성하되 일관성을 유지해, 해당 기능을 명확히 전달하는 이름을 선택하세요. 서술적인 이름을 사용하면 개발자 머릿속에서도 설계가 뚜렷해져 코드 개선이 쉬워집니다.

이름을 붙일 때는 일관성 있게, 모듈 내 함수 이름은 같은 문구, 명사, 동사를 사용합니다.

 

함수 인수

이상적인 인수 개수는 0개입니다. 인수는 최소한으로, 4개를 넘지 않도록 주의합니다. 인수가 많아질수록 함수의 개념을 이해하기 어려워지고 테스트도 복잡해집니다. 가능하면 인수가 없는 함수가 최선이며, 차선은 1개입니다.

인수는 개념을 어렵게 만듭니다. 코드를 읽는 사람이 인수를 발견할 때마다 의미를 해석해야 되기 때문입니다. 넘겨지는 인수마다 추상화 수준이 다르다면 개념은 더 어려워집니다. 게다가 코드를 읽는 사람이 현시점에서 별로 중요하지 않은 세부사항을 알아야 합니다. 테스트 관점에서 보면 인수는 더 어렵습니다. 갖가지 인수 조합으로 함수를 검증하는 테스트 케이스를 작성한다면 더 어려워집니다. 인수가 없으면 간단합니다. 

 

플래그 인수

플래그 인수는 함수가 여러 가지 일을 한다는 신호로, 코드의 가독성을 저하시킵니다. 부울 값을 인수로 넘기는 것은 피하는 것이 좋습니다.

 

단항/이항/삼항 함수

단항 함수는 대개 하나의 질문이나 변환을 수행하며, 질문은 func fileExists("MyFile") -> bool 이 좋은 예입니다. 다른 하나는 인수를 뭔가로 변환해 결과를 반환하는 경우입니다. func fileOpen("MyFile") -> Data? 정도가 되겠습니다. 

이항 함수는 이해하기 어렵기 때문에 가능하면 단항으로 바꾸는 것이 좋습니다. 삼항 함수는 더욱 신중하게 사용해야 합니다.

 

인수 객체

인수가 2~3개 이상 필요하다면 일부를 객체로 묶어 사용하는 것이 좋습니다. func makeCircle(double x, double y, double radius) 같은 경우에 func makeCircle(Point center, double radius)처럼 사용하는 것이 차선책입니다.

 

동사와 키워드

함수 이름에 인수 이름을 포함하여 인수 순서를 기억하지 않아도 되도록 할 수 있습니다.
이 항목도 언어에 따라 인수를 변수에 명시적으로 기록할 수 있는 경우가 있으니 언어를 잘 확인하면 좋습니다. 아래는 Swift의 예시입니다.

func remove(item: String, from list: inout [String]) {
    if let index = list.firstIndex(of: item) {
        list.remove(at: index)
    }
}

// 사용 예시
var shoppingList = ["Apples", "Bananas", "Oranges"]
remove(item: "Bananas", from: &shoppingList)

print(shoppingList) // ["Apples", "Oranges"]

 

부수 효과를 일으키지 마라 (No Side Effect)

함수는 약속한 일 외에 다른 작업을 수행하지 않아야 합니다. 예상치 못하게 클래스 변수나 전역 변수를 수정하는 것도 피해야 하며, 순서 종속성을 초래할 수 있는 작업을 방지해야 합니다.

 

명령과 조회를 분리하라

함수는 특정 작업을 수행하거나, 정보를 반환하거나 둘 중 하나만 해야 합니다.

 

오류 코드보다 예외 처리를 사용하라

오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 위반할 수 있습니다. 예외 처리를 사용하여 코드의 흐름을 명확히 하는 것이 좋습니다.

 

Try/Catch 블록 분리하기

Try/Catch 블록은 별도의 함수로 분리하는 것이 좋습니다. Try/Catch 블록은 코드 구조를 복잡하게 만들고, 정상 동작과 오류 처리를 섞어 혼란을 초래하기 때문입니다.

 

반복하지 마라

중복 코드는 유지보수가 어렵습니다. 중복을 최소화하는 것이 코드 품질을 높이는 데 중요합니다.
반복되는 알고리즘은 알고리즘이 변한 경우에 반복의 개수만큼 알고리즘을 수정해야 합니다. 

데이터베이스에서는 중복을 제거할 목적으로 관계형 데이터베이스에 정규 형식을 만들었으며, 객체지향 프로그래밍에서는 부모 클래스를 사용하여 중복을 없앴습니다. 구조적 프로그래밍, AOP, COP 모두 어떤 면에서 중복을 제거하기 위한 전략의 산물입니다.

 

구조적 프로그래밍

구조적 프로그래밍 원칙에 따르면 함수 내의 모든 블록은 하나의 입구와 출구만 가져야 합니다. 즉, return 문이 하나만 존재해야 합니다.

 

함수를 어떻게 짜죠?

함수 작성은 글쓰기와 비슷합니다. 처음에는 아이디어를 기록하듯이 작성한 후, 반복해서 다듬고 정리합니다. 코드는 항상 단위 테스트를 통과하도록 짜야하며, 중복을 제거하고, 메서드를 줄이며, 때로는 클래스를 쪼개는 작업을 합니다.

 

결론

모든 시스템은 도메인 특화 언어(DSL)로 작성되며, 함수는 그 언어의 동사, 클래스는 명사입니다. 프로그래밍 기술은 언어 설계의 기술이며, 프로그래밍 언어라는 수단을 사용해 풍부하고 표현력 있는 언어를 만들어갑니다. 이 장은 함수를 잘 만드는 기술을 소개하며, 설명한 규칙을 따르면 짧고 명확하며 체계가 잡힌 함수를 만들 수 있을 것입니다. 그러나 진정한 목표는 시스템이라는 이야기를 풀어나가는 데 있다는 점을 명심해야 합니다. 작성하는 함수가 시스템 내에서 의미와 목적을 뚜렷하게 드러내어야 코드의 일관성과 가독성이 높아질 것입니다.

모든 시스템은 특정 응용 분야 시스템을 기술할 목적으로 프로그래머가 설계한 도메인 특화 언어(Domain Specific Language, DSL)로 만들어집니다. 함수는 그 언어에서 동사이며, 클래스는 명사입니다. 프로그래밍의 기술은 언제나 언어 설계의 기술입니다. 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어갑니다. 이 장은 함수를 잘 만드는 기교를 소개했습니다. 여기서 설명한 규칙을 따른다면 길이가 짧고, 이름이 좋고, 체계가 잡힌 함수가 나올 것입니다. 하지만 진짜 목표는 시스템이라는 이야기를 풀어가는 데 있다는 사실을 명심하길 바랍니다. 작성하는 함수가 분명하고 정확한 언어로 깔끔하게 같이 맞아떨어져야 이야기를 풀어가기 쉬워진다는 사실을 기억하기 바랍니다.

 

3장을 읽고 나서

 3장에서 느낀 점은 추상화, 중복 제거, '작게'와 '한 가지 일만 하기' 원칙, 서술적 이름 사용, 그리고 예외 처리의 중요성이었습니다. 결국, 이러한 기교를 통해 프로그래밍 언어를 다루며 시스템의 이야기를 풀어나가야 한다는 점을 새삼 깨달았습니다. 이 장은 함수를 잘 만드는 기교들, 간결하게 표현된 코드가 의도를 분명히 드러내고, 단순히 읽기 쉬운 것에 그치지 않고 사용하기에도 좋은 함수로 만든다는 것을 다시금 생각해 보게 만들었습니다. 

복잡한 코드를 짧게 줄이는 것은 비교적 쉬운 일입니다. 하지만 그렇게 축약된 코드가 의미까지 분명히 전달하는 것은 전혀 다른 문제입니다. 이 점에서 저는 불필요한 요소를 줄이되 각 코드의 조각이 명확한 역할을 수행하도록 하는 ‘오컴의 면도날’ 법칙을 떠올렸습니다. 바로 이런 코드가 이상적이라는 생각이 들었습니다.

 이 장에서 강조한 좋은 함수란 단순히 짧은 함수가 아닌, 코드의 의도와 목적을 한눈에 드러내면서도 협업과 유지보수 측면에서도 큰 장점을 가진 함수입니다. 실제로 코드가 명확할수록 다른 개발자와 협업할 때의 이해도와 수정 속도가 크게 향상되고, 이는 팀 전체의 생산성을 높여 기여할 것이라 생각합니다. 또한 코드의 일관성과 가독성은 유지보수에도 큰 도움이 될 것이며, 기능 수정이나 버그 해결 시에도 큰 도움이 되리라 생각합니다.

3장의 함수 규칙들은 단순히 잘게 쪼개는 것이 목적이 아니라, 최소 블록인 함수에서부터 효율을 높이는 실질적인 지침이라는 생각이 들었습니다. 물론 이 책이 쓰인 게 생각보다 오래되었고, 전부 다 맞진 않다고 생각해서. 언어 특성을 고려해 최신 트렌드에 잘 맞춰야 한다고 생각하고 있습니다.

 

---

 

3장까지의 생각

 1장부터 3장까지 읽고 나서 가장 처음으로 든 생각은 'Brevity is the soul of wit'라는 말이었습니다. 책에서 강조한 클린코드, 의미 있는 이름, 의도를 드러내는 코드 작성, 작게 만들기와 한 가지 일만 하기의 원칙은 코드의 간결함과 명확성을 추구하는 말과 맞닿아 있다는 느낌이 들었습니다. 그리고 제 상황과도 너무 비슷한 느낌이 들어서 이런 비유를 하게 되었습니다. 😂

 여기까지만 읽었을 때 이 책은 단순히 코드 작성뿐만이 아니라, 한 걸음 더 나아가 프로그래머로써 생각할 거리를 던져 주는 것 같습니다. 읽기 쉽고, 명확하며, 협업과 유지보수에 강한 코드의 본질을 생각하게 해주는 느낌이 들었습니다.

결론적으로, 이 세장은 코드를 통해 명확하고 일관된 소통을 할 수 있도록 돕는 기초 지침서라는 생각이 들었습니다. 단순히 무엇인가를 해라! 해야만 한다! 가 아닌 코드를 읽히기 좋은 글처럼 설계해야 한다는 관점에서 프로그래밍을 더욱 깊이 이해하게 해주는 책 압니다.

 

이 글은 여기까지 마치고, 다음 4장부터 찾아뵙겠습니다. 긴 글 읽어주셔서 감사합니다. 🙇‍♂️