클린코드 스터디 덕분에 클린코드라는 책을 접하게 되었다.
클린코드 책을 읽으면서 지난날의 나를 반성하게 되었다.
단순히 코드 기능에만 집중하고 테스트와 코드 중복등 다른 요소들을 고려하지 않았다.
하지만 아직 늦지 않았다는 생각을 가지면서 다시 시작해보겠다.
요구사항
우선 깨끗한 코드를 알아보기 전에 내가 책을 읽으면서 인상깊게 봤던 여러 구절들을 소개하려고 한다.
"기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다"
"궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다"
이 두 구절을 읽으면 요구사항이라는 단어가 겹치는 모습을 볼 수 있다.
요구사항이라는 단어의 정의를 네이버 백과사전에서 찾으면 밑의 결과 처럼 나온다.
①어떤 문제를 해결하거나 특정의 목적을 위하여 사용자가 필요로 하는 조건이나 능력.
②계약, 표준, 명세 또는 다른 형식으로 제시된 문서에 맞추어 시스템이나 시스템 구성 요소가 갖추어야 할 조건이나 능력. 요구 사항들은 시스템이나 시스템 구성 요소의 후속 개발 단계의 자료가 된다.
[네이버 지식백과] 요구 사항 [requirement, 要求事項] (IT용어사전, 한국정보통신기술협회)
요구사항의 정의를 문장에 넣어서 보면
기계가 실행할 정도로 상세하게 필요한 조건이나 능력을 명시하는 작업, 이것이 바로 프로그래밍이다.
궁극적으로 코드는 필요한 조건이나 능력을 표현하는 언어라는 사실을 명심한다.
나쁜 코드
나쁜 코드의 위험성을 알리기 위해 책에서 한가지 예시를 말해주었다.
80년대 후반 킬러 앱 하나를 구현한 회사가 있었다. 제품은 커다란 인기를 끌었으며 수많은 전문가가 구매해 사용했다.
그런데 제품 출시 주기가 점차 늘어지기 시작했다. 이전 버전에 있었던 버그가 다음 버전에도 그대로 남아 있었다.
이러다 회사는 얼마 못가 망했다.
이 회사가 망한 원인은 바로 나쁜 코드 탓이었다.
그들은 출시에 바빠 코드를 마구 짰다. 기능을 추가 할수록 코드는 엉망이 되어갔고, 결국 감당이 불가능 한 수준에 이르었다. 나쁜 코드로 치르는 대가를 잘 보여주는 그래프가 하나 있다.
바로 Productivity VS Time 그래프이다.
코드를 마구잡이로 짜면 기능은 잘 작동할 수 있다. 하지만 에러가 생기면 코드를 고쳐야되고 복잡하게 얽힌 코드를 보면서 고치면 오히려 새로 짜는 것 보다 시간이 더 많이 걸린다.
그래프에서도 처음에는 생산성이 100이었다가 점점 시간이 지나면서 0에 수렴하는 모습을 보인다.
나쁜 코드가 쌓여 생산성이 0이 되면 개발자들은 결국 재설계를 해야된다.
프로그래머라면 한번쯤은 기한에 쫒겨 코드를 아무렇게 막 짠 경험이 있을 것이다.
하지만 그들도 코드를 짜면서 속으로는 "아 나중에 고치면 되겠지"라는 생각을 할 것이다.
그들은 틀렸다. 나중에라는 말은 코딩에서는 존재하지 않으며 빨리갈 수 있는 유일한 방법은 코드를 최대한 깨끗하게 유지하는 습관이다.
깨끗한 코드
C++의 창시자인 비야네 스트롭스트롭은 깨끗한 코드를 '보기에 즐거운 코드'로 비유하였다.
그러면서 깨끗한 코드란 한 가지를 잘 한다고 단언했다.
말을 조금 더 풀어서 쓰면 나쁜 코드는 수많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다.
하지만 깨끗한 코드는 한 가지에 '집중'한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다. 나는 이 표현을 "각 함수와 클래스와 모듈은 정해진 한가지 기능만 성실히 수행한다"라고 생각한다.
Object Orientied Analysis and Design with Application의 저자 그래디 부치는 가독성을 강조했다.
가독성을 강조하면서도 '명쾌한 추상화'라는 단어도 언급하였다.
명쾌한이라는 단어는 구체적인이라는 단어와 유사하다. 글쓴이는 명쾌한을 "힘차게 단호하고 사실적인"이라는 의미로 해석하였다. 코드는 추측이 아니라 사실에 기반해야 한다. 프로그래머는 단호하다는 인상을 주어야 한다라는 말을 명쾌한 추상화라는 말을 통해서 전달했다.
OTI 창립자이자 이클립스 전략의 대부 데이브 토마스는 깨끗한 코드를 다른사람이 고치기 쉬운 코드라고 표현하였다.
내가 생각해도 이 말이 깨끗한 코드에 가장 근접한 말 인것 같다.
다른사람이 내 코드를 고치기 위해서는 코드를 먼저 이해 해야한다. 이해를 하기 위해서는 다양한 의존성 및 함수들을 보는데 이러한 코드들이 한가지에 집중하며 가독성이 좋으면 이해하기 쉽기 때문이다.
미국의 소프트웨어 엔지니어이자, Extreme Programming의 개발자인 켄트 백은 몇가지 규칙을 제안하였다.
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.
이러한 규칙만 잘 지키더라도 깨끗한 코드가 될 수 있다고 생각한다.
이때 클래스, 메서드, 함수의 개수를 최대한 줄인다고 여러개의 기능을 하나에 넣으면 안된다.
'한가지 기능'을 지키면서 개수를 최대한 줄여야 한다.
보이스카우트 규칙
코드를 읽는 시간과 코드를 짜는 시간의 비율은 10:1 정도이다.
우리는 새 코드를 짜면서 끊임없이 기존 코드를 읽는다.
보이 스카우트 규칙이란 "캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라" 입니다.
이렇듯 우리는 프로그래밍에 보이스카우트 규칙을 대입해서 코드는 처음 왔을때보다 더 깨끗하게 해놓고 떠나라 라는 말을 생각할 수 있습니다. 시간이 지날수록 코드가 좋아지는 프로젝트에서 작업하면 모두가 좋을 것입니다.
