클린 코드

나쁜 코드는 개발 속도를 크게 떨어뜨린다.
(...) 
코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다. 간단한 변경은 없다. 매번 얽히고설킨 코드를 '해독'해서 얽히고설킨 코드를 더한다. (...) 
나쁜 코드가 쌓일수록 팀 생산성은 떨어진다.

 

여럿 개발자의 마음을 쿡쿡 찌르는 문구. 아마 모두가 겪어본 적이 있을 테다. 누군가가 작성한 코드를 수정하고, 문제가 터지고, 해독하고, 한참 시간이 걸리고, 수정하고, 문제가 터지고, 이해하고, 비슷한 엉망 코드를 얹고. 반복. 반복.

 

사실 최근 아키텍처, 테스트, 클린 코드에 관심을 가지는 것도 이러한 맥락에서다.

앱과 비슷한, 혹은 동일한 기능의 웹을 개발하는데... 앱에서 작성한 코드 중 활용할 수 있는 게 거의 없었다.

불과 6,7개월 전에 내가 작성한 코드조차도!  

만일 그 때부터 유지보수와 재사용에 집중해 코드를 작성했다면... 얼마나 많은 시간과 노력을 아낄 수 있었을까?

 

그들이(프로젝트 관리자) 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. 
(...) 
프로그래머도 마찬가지다(의사와 같다). 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
(...)
진짜 전문가는 두 번째 부분이 틀렸다는 사실을 잘 안다. 나쁜 코드를 양산하면 기한을 맞추지 못한다. 
(...) 
기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

 

송곳 수준의 문장. 나쁜 코드의 원인을 외부에서 찾고자 하는 유혹은 어찌나 강렬한지!

이제는 안다. 소프트웨어 전문가는 자신의 일을 해야 한다. 그 일은 자신의 코드를 깨끗하게 유지하는 것이다.

즉 반대로 말하자면... 자신의 코드를 깨끗하게 유지하는 것이 소프트웨어 전문가의 길이다.

 

깨끗한 코드를 작성하려면 '청결'이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다. 열쇠는 '코드 감각'이다. 어떤 사람은 코드 감각을 타고난다. 어떤 사람은 투쟁해서 얻어야 한다. '코드 감각'이 있으면 좋은 코드와 나쁜 코드를 구분한다. 그뿐만이 아니다. 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다. 
(...)
다시 말해, 깨끗한 코드를 작성하는 프로그래머는 빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와 같다.

 

소프트웨어 개발을 고민할 수록, 소프트웨어 개발자는 목수와 비슷하다고 생각했다.

망치질 한 번 한 번에 모든 힘을 쏟는. 최고 수준의 망치질을 수천 번 동안 반복해 최상의 결과물을 내는 목수.

 

밥 아저씨는 프로그래머를 화가나 작가에 비유한다. 

감각을 통해 나쁜 그림이나 문장을 포착하고, 절제와 규율을 적용해 이를 최고의 작품이나 글로 완성해 내는.

 

// 우아하고 효율적인 코드
깨끗한 코드는 '보기에 즐거운' 코드다. 잘 만든 오르골이나 잘 디자인된 차를 접할 때처럼 깨끗한 코드는 보는 사람에게 즐거움을 선사해야 한다는 뜻이다. 
(...) 
나쁜 코드는 나쁜 코드를 '유혹'한다!

// 단순하고 직접적인 코드
깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다. 
(...)
좋은 소설과 마찬가지로 깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내야 한다. 명백한 해법을 제시하며 긴장과 문제를 풀어야 한다.

// 다른 사람이 고치기 쉬운 코드
깨끗한 코드는 주의 깊게 작성한 코드다. 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다. 세세한 사항까지 꼼꼼하게 신경 쓴 코드다. 주의를 기울인 코드다.

// 짐작했던 기능을 그대로 수행하는 코드
코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다. 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다. 
(...) 
각 모듈은 다음 무대를 준비한다. 모듈을 읽으면 다음에 벌어질 상황이 보인다. 
(...)
'코드가 그 문제를 풀기 위한 언어처럼 보인다면' 아름다운 코드라 말한다.

 

클린 코드에 대한 여러 프로그래머들의 정의. 절로 고개가 끄덕여지는 문장들.

 

의도를 분명히 밝혀라
변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은?
따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

 

이름 짓기. 어쩌면 클린 코드의 첫걸음이지 않을까.

다른 사람이 지은 요상한 네이밍을 볼 때면, 왜 이렇게 작성했을까... 하는 생각이 든다.

하지만 중요한 건 → 정작 본인이 개발할 때는 마땅찮은 이름이 떠오르지 않는다는 것!

 

그리고 그 원인은... 결국 해당 코드 맥락이 명확하지 않기 때문이다.

각 코드들이 자신이 만든 맥락 속에서 어떤 의미를 가지는지를 신경 쓴다면...

각각의 의미 속 개념에 맞는 단어를 포착하고, 이를 꾸준히 유지해야 한다.

(이때 해당 단어들은 해법 영역 or 문제 영역에서 가져올 수 있을 테다!)

 

작게 만들어라! 한 가지만 해라!
함수를 만드는 첫째 규칙은 '작게'다! 함수를 만드는 둘째 규칙은 '더 작게'다.

 

이젠 귀에 딱지가 앉을 정도. 결코 부족하지 않다.

 

함수당 추상화 수준은 하나로!
함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. 
(...)
한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. 특정 표현이 근본 개념인지 아니면 세부사항인지 구분하기 어려운 탓이다. 
(...) 
(문제는) 근본 개념과 세부사항을 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다.

 

'읽기 어려운' 함수를 만드는 요인 중 큰 부분이지 않을까?추상화 수준이 다른 함수는 이해하기가 어렵다. 수정하기도 두렵다.

 

그리고... 마지막 줄처럼 자기도 모르게, 스르륵, 제멋대로 추상화 수준의 코드를 추가하고 만다.

 

의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저한다. 변경하면 득 보다 해가 크다 생각해 더 이상 코드를 정리하지 않는다. 그러면서 코드가 망가지기 시작한다.

 

단위 테스트의 한 구절. 지난번 읽었던 클린 아키텍처와 궤를 같이 한다.

예상치 못한 결함이 예상되어(참 이상한 말이다. 하하!) 변경을 두려워한 경험이 얼마나 많을까! 

 

항상 명심하자. 소프트웨어 엔지니어는 소프트웨어를 만든다. 소프트웨어는 변화에 쉽게 대응하기 위해 존재한다.

즉 소프트웨어 엔지니어가 만든 결과물은 쉽고, 빠르고, 안정적이게 변화할 수 있어야 한다.