클린 코드 읽기 1 - 깨끗한 코드

toastedEevee·2024년 6월 25일
0

클린 코드 읽기

목록 보기
1/7
post-thumbnail

요즘은 로버트 C. 마틴의 클린코드를 읽고 있다. 우선 7장까지 1회독하고 한 번 정리하면서 또 읽어보자.

코드가 존재하리라

기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다. 이렇게 명시한 결과가 바로 코드다.

궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다. 요구사항에 더욱 가까운 언어를 만들 수도 있고, 요구사항에서 정형 구조를 뽑아내는 도구를 만들 수도 있다. 하지만 어느 순간에는 정밀한 표현이 필요하다. 그 필요성을 없앨 방법은 없다. 그러므로 코드도 항상 존재하리라.

나쁜 코드로 치르는 대가

나쁜 코드는 개발 속도를 크게 떨어뜨린다. 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다. 간단한 변경은 없다.

나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 그러다가 마침내 0에 근접한다.

코드가 왜 그렇게 되었을까? 좋은 코드가 어째서 순식간에 나쁜 코드로 전락할까?

잘못은 전적으로 우리 프로그래머에게 있다. 우리가 전문가 답지 못했기 때문이다.

좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.

자신이 의사라고 가정하자. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 너무 걸리니까.
확실히 환자는 상사다. 하지만 의사는 단호하게 거부한다. 왜?
질병과 감염의 위험은 환자보다 의사가 더 잘 아니까.

프로그래머도 마찬가지이다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

그럼에도 모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다. 진짜 전문가는 이 부분이 틀렸다는 사실을 잘 안다.
나쁜 코드를 양산하면 기한을 맞추지 못한다. 오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다.

그러니까 빨리가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

깨끗한 코드란?

깨끗한 코드란 한 가지를 제대로 한다.

논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. - 비야네 스트롭스트룹( C++ 창시자)

수많은 소프트웨어 설계 원칙이 이 간단한 교훈 하나로 귀결된다는 사실은 우연이 아니다. 나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 깨끗한 코드는 한 가지에 ‘집중’한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다.

깨끗한 코드는 잘 쓴 문장처럼 읽힌다.

깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다. - 그래디 부치

좋은 소설과 마찬가지로 깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내야 한다. 긴장을 쌓으며 클라이맥스에 이르렀다가 명백한 해법을 제시하며 긴장과 문제를 풀어야 한다.

코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다. 코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야 한다.

깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.

깨끗한 코드에는 의미 있는 이름이 붙는다. 특정 목적을 달성하는 방법은 하나만 제공한다. - 데이브 토마스(이클립스 전략)

테스트 주도 개발(Test Driven Development)은 오늘날 가장 근본적인 원칙 중 하나가 되었다. 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. 아무리 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 않다.

또한 코드는 작을수록 좋다.

깨끗한 코드는 언제나 누군가 주의 깊게 짜놓은 느낌을 준다.

고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로. - 마이클 페더스

누군가 시간을 들여 깔끔하고 단정하게 정리한 코드. 세세한 사항까지 꼼꼼하게 신경쓴 코드이다.

중복을 줄이고, 표현력을 높이고, 초반부터 간단한 추상화를 고려하라.

모든 테스트를 통과한다. 중복이 없다. 시스템 내 모든 설계 아이디어를 표현한다. 클래스, 메서드, 함수 등을 최대한 줄인다. - 론 제프리스

같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다.

표현력은 의미 있는 이름을 포함한다.

객체가 여러 기능을 수행한다면 여러 객체로 나눈다. 메서드가 여러 기능을 수행한다면 메서드 추출 리팩터링 기법을 적용해 기능을 명확히 기술하는 메서드 하나와 기능을 수행하는 메서드 여러 개로 나눈다.

프로그래밍을 하다보면 집합에서 특정한 항목을 찾아낼 필요가 자주 생긴다. 이러한 상황에서는 추상 메서드나 추상 클래스를 만들어 실제 구현을 감싼다.

코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드이다.

코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다. - 워드 커닝햄(위키 창시자)

깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다. 코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다. 각 모듈은 다음 무대를 준비한다. 모듈을 읽으면 다음에 벌어질 상황이 보인다.

보이스카우트 규칙

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

미국 보이스카우트가 따르는 이 간단한 규칙이 프로그래밍에서도 유용하다.

한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.

지속적인 개선이야말로 전문가 정신의 본질이다.

profile
내가그린솜뭉치

0개의 댓글