좋은 코드, 그것이 알고 싶다

고민의 시작

개발자라면 누구나 고민하는 지점이 있다. 바로 '좋은 코드'에 대해서이다. 학부 수업을 들을 때도, 회사를 다닐 때도 '좋은 코드'를 작성해야 한다는 이야기를 수없이 들었고, 또 그러고 싶었다. 하지만 그 '좋은 코드'란 대체 무엇인가? 나는 그 질문에 대한 답이 '좋은 사람', '좋은 개발자' 만큼 폭넓은 기준을 가졌다고 생각한다. 그래서 여러 자료를 참고하여 '백엔드' 개발자 입장에서의 관점을 적어보려 한다.

 

좋은 코드란 무엇일까?

일단 '좋은 코드'에는 수많은 정의가 있다. 읽기 쉬운 코드, 테스트가 용이한 코드, 오류가 없는 코드, 짧은 코드, 중복이 없는 코드 등등. 프로그램의 목적 혹은 개인의 취향 등 다양한 관점에서의 정의가 있다. 그래서 구글링...을 하면 좀 식상하니까 Chat GPT에게 넌지시 물어봤다.

 

우리의 Chat GPT는 위와 같이 아주 모범 답안을 내놓았다.

전부 다 맞는 말이다.(말은 쉽지...)

 

클린 코드?

 

클린 코드는 로버트 C.마틴의 책 제목이자 말 그대로 '클린'한, 깨끗한 코드를 의미한다.

개발자들의 꾸준한 추천 도서이므로 나도 조만간 읽어보려고 한다!!

 

그럼 이번엔 '클린 코드'에 관하여 유명한 개발자들의 의견을 알아보자

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent but rather is full of crisp abstractions and straightforward lines of control.  클린 코드는 간결하고 직관적이다. 읽기 쉽게 작성된 문장처럼 읽힌다. 클린 코드는 설계자의 의도를 명확하게 드러내며, 간결한 추상화와 직관적인 제어 구문이 가득하다.
- Grady Booch(Object-Oriented Analysis and Design with Applications 저자)

You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem. 각 루틴을 읽어보면 예상한 대로인 깔끔한 코드를 작업 중이라도 생각할 수 있다. 코드가 문제를 해결하기 위해 만들어진 언어로 보인다면 아름다운 코드라고 할 수 있다.
- Ward Cunningham(Wiki의 창시자)

 

 

역시 다 맞는 말이다.

이제 여러 의견을 종합하여 보기 좋게 '좋은 코드'의 조건을 정리해보려 한다.

 

 

1. 가독성

공통으로 계속 언급되는 요소는 바로 '가독성'이다. 그럼 왜 대체 이렇게 가독성을 강조하는가?...는 이미 작성된 코드를 분석해 본 경험이 있는 모든 사람이 아마 공감할 것이다. 일관성 없는 네이밍, 중구난방한 줄 바꿈, 이름은 하나인데 기능은 수십 개인 함수 등등... 악몽 같은 코드를 만나면 '가독성'에 목숨을 걸게 된다. 

일관성 있는 네이밍, 팀 규칙이 필요하고, 들여쓰기와 서로 밀접한 개념은 세로로 가까이 둬야 한다. 행 길이도 너무 길면 잘 읽히지 않는다. 가독성이 좋은 코드는 해석하는 시간을 줄여준다. 해석하는 시간이 수정하는 시간보다 몇 배는 많이 들기 때문에 이는 곧 개발 시간 단축과 코드 품질 상향으로 이어진다. 얼마나 좋은 나비효과인가!

 

 

2. 의미 있는 네이밍

또한 의미 있는 네이밍도 중요하다. 이름은 곧 그 존재를 각인시킨다. 변수를 a, b, 함수를 funcA, funcB로 이름 짓는 것은 당장 아주 간단한 실습 예제로는 편하고 보기 좋겠지만 이런 습관은 실무에 1도 도움이 되지 않는다. 그 코드가 온전히 본인의 것이어도 안될 일이지만 훗날 누군가 그 코드를 분석하고 수정해야 한다면 더더욱 아니 된다. 이름은 직관적이고, 발음하기 쉬우며, 의미가 명확하게 짓는 것이 좋다. 또한 네이밍 규칙을 세워두는 것도 도움이 된다.

 

 

3. 함수는 한 가지 일만 잘하게 만들기

처음 프로그래밍을 배우기 시작했을때 함수 하나에 여러 기능을 왕창 넣었다. 그저 오류 없이 제대로 돌아가는게 목표였기 때문이다. 그러한 과제를 제출했을 때를 다시 떠올려보면 정말 안타깝다. 함수는 최대한 작을 수록 좋고, 더불어 중복도 없어야 한다.

또 함수는 명령과 조회를 분리해야 한다. 뭔가를 수행하거나, 뭔가를 답하거나 둘 중 하나만 하는 것이 함수의 의미를 명확히 한다. if (set("username", "unclebob")) 코드를 읽어보면, "username"이 "unclebob"으로 설정되어 있는지 확인하는 코드인지, 아니면 "username"을 'unclebob'으로 설정하는 코드인지 명확하게 알 수 없다. 'set'이라는 단어의 의미가 중의적이기 때문이다. 

 

 

4. 좋은 주석과 나쁜 주석

잘 달린 주석은 코드 분석의 시간을 줄여준다. 반면 근거 없이, 의미 없이 달린 주석은 시간을 배로 잡아먹는다. 과연 주석은 어떻게 달아야 잘 다는 것일까? 주석은 '그냥' 달아도 되는 것일까?

코드를 작성하는 것은 그 코드로 문제를 해결하기 위함이다. 그러므로 가급적 코드로 그 의도를 설명하는 것이 말그대로 '좋은 코드'이다. 의도를 설명하고 있는 코드에 또 다시 의도를 설명하는 주석은 나쁜 주석이라고 볼 수 있다. 

반면 중요성을 강조하거나, 결과를 경고하거나, 정보를 제공하는 주석은 좋은 주석으로 볼 수 있다. 때로는 법적인 이유로 주석이 들어가게 될 수도 있다.

 

정리하며

이 밖에도 좋은 코드에 대한 많은 의견이 있고 나도 더 고민하고 배워나가는 입장이라 이 글을 쓰면서 도움이 많이 됐다.(반성도 했다.)

리팩터링과 테스트코드 작성 등에 대해서도 포스팅을 할 예정이다. 더 좋은 코드, 더 좋은 개발자가 되기 위하여 오늘도 한 걸음을 나아가는 모두에게 응원을 보낸다.

 

---

 

- 참고 자료 출처:

https://jbee.io/etc/what-is-good-code/

좋은 코드란 무엇일까?