깨끗한 코드
Clean Code 의 첫 도입부는 책 이름답게 "깨끗한 코드" 라는 주제를 다루고 있습니다.
첫번째 장에서는 깨끗한 코드의 중요성과 유명하고 노련한 프로그래머들이 생각하는 깨끗한 코드에 대한 생각들이 담겨 있었습니다.
이번 포스팅에선, 위 내용에 대한 주관적인 요약을 다뤄보려 합니다.
1. 코드가 존재하리라.
최근 프로그램을 제작하기 위한 많은 기술들이 등장하고 있으며, 아마 프로그램을 제작하는 방법은 점점 편리해졌습니다.
제작하는 방법이 쉬워지는 만큼, 개발자들은 코드보단 요구사항에 조금 더 집중해야한다고 생각하는 의견들도 많이 있습니다.
생각해보면, 새로 등장하는 많은 언어들은 어렵거나 귀찮은 내용을 점점 추상화하고 있습니다.
(어느덧 C++ 이후 부터의 언어는 포인터를 찾아볼 수 없고, 병렬 처리같은 복잡한 수준의 구현은 함수형 등으로 쉽게 나타낼 수도 있습니다.)
이러한 구현과정의 추상화는 계속될 것이며, 우리는 요구사항에 조금 더 집중할 수 있을 것입니다.
그렇지만 요구사항을 나타내는 구체적인 방법은 결국 코드이며, 코드는 계속 우리 곁에 남아있을 것입니다.
2. 나쁜 코드
협업을 하게 되면, 동료들의 많은 코드를 볼 수 있습니다.
또한, 이 코드를 사용하거나 고쳐야할 상황도 많으며 종종 누군가가 작성했던 나쁜 코드들에게 시달렸을 것입니다.
(아마 종종 누구가는 자신일 확률이 높을 수도 있습니다. ㅡㅡ^)
나쁜 코드는 당연한 이야기이지만 개발 속도를 크게 떨어트립니다.
간단한 변경이란 없고, 코드를 변경할 시 여기저기서 문제가 발생할 것입니다.
이러한 일들은 팀 생산력을 크게 저하시킬 것입니다.
생산력을 올리고자, 새로 인원을 충원해도 그들은 설계의도를 모르기 때문에 더 나쁜 코드가 생산될 수 있죠.
덕분에 생산력은 0를 향해 내려갈 것입니다.
이 상황이 계속되면, 개발자들은 재설계를 요구할 수 밖에 없습니다.
모듈 하나 추가할 때마다 너무 많은 시간이 들며, 이곳 저곳 버그가 많다면 계속 헝겊을 짜집는 것보다는 새로 만들기를 희망합니다.
관리자들 역시 재설계에 자원을 쏟기 싫지만, 생산성이 0이기에 어쩔 수 없이 허락을 할 것입니다.
이제, 개발자들은 두 팀으로 나눠집니다.
기존 시스템을 유지할 인력과 새로 재개발을 할 타이거 팀으로 말이죠.
타이거 팀은 기존 시스템을 대체할 새 시스템을 내놓아야 합니다. 또한 기존 시스템에 추가되는 변경점도 따라잡아야 하죠.
이 상태는 오랫동안 이어질 수 있습니다.
오랫동안 이어진다면 기존 타이거팀은 모두 떠났고, 또 다른 인력이 새 시스템을 설계 하겠다고 할 것입니다.
(현재 시스템 역시 엉망이기 때문이겠죠..)
위의 이야기는 책에 등장하는 경험담이며, 현재 제가 재직하고 있는 회사에서도 겪고 있습니다... ㅜㅡㅜ
깨끗한 코드를 만드는 노력은 비용 절감뿐 아니라, 전문가로써 살아남는 방법이라 주장하고 있습니다.
3. 태도
나쁜 코드가 심각한 장애물이라는 것은 개발자라면 많이 공감을 할 것입니다.
왜 우리들의 코드는 이렇게 되었을까요?
요구사항이 원래 설계를 뒤집는 방향으로 변해서? 일정이 촉박해서? 멍청한 관리자와 조급한 기획자 때문에?
이 책에서는 이러한 잘못은 모두 프로그래머에게 있다고 합니다.
관리자와 기획자는 우리에게 현실성을 자문하고, 도움을 요청합니다.
우리에게 정보를 구하지 않더라도, 우리는 적극적으로 그들에게 정보를 제공해야 합니다.
우리는 프로젝트에 가장 깊게 관여하고 있으며, 프로젝트 실패는 우리에게 커다란 책임이 있습니다. 나쁜코드가 초래하는 실패라면 더더욱 책임이 큽니다.
"아니, 잠깐만요.. 상사가 시키는 대로 하지 않으면 짤린다구요!" 우리의 의견은 보통 이럴 텐데 말이죠..
하지만, 대다수의 관리자들은 진실을 원하며, 일정에 쫓기더라도 좋은 코드를 원합니다.
관리자들이 일정을 밀어붙이는 것은 그들의 책임이며, 좋은 코드를 사수해야하는 것은 우리들의 일입니다.
이 책에서는 한가지 비유를 했습니다.
자신이 의사라 가정하자.
어느 환자가 수술전에 손을 씻지 말라고 요구한다. 시간이 너무 오래걸리니깐?
하지만, 의사는 단호하게 거부한다. 왜? 질병과 감염의 위험은 환자보다는 의사가 잘 아니까.
환자 말을 그대로 따르는 행동(범죄일 뿐만 아니라)은 전문가 답지 못하다.
개발자 역시, 나쁜코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 것은 전문가 답지 못할 것입니다.
4. 깨끗한 코드란?
나쁜 코드는 이와 같이 나쁘며, 빨리 가려면 깨끗한 코드를 유지해야 한다고 인정해야 한다고 가정합시다.
그렇다면, 깨끗한 코드는 어떻게 작성할까요?
이 책에서는 깨끗한 코드를 구현하는 행위는 그림을 그리는 것과 같다고 비유합니다.
대부분의 사람들은 그림이 잘그렸는지 엉망인지 알고 있습니다.
하지만, 그림을 구분하는 능력이 그림을 잘 그리는 능력은 아닙니다.
깨끗한 코드를 작성하려면 '청결' 이라는 어렵게 습득한 코드감각을 활용해 자잘한 기법을 이용하는 절제와 규율이 필요합니다. 나쁜 모듈을 보면 좋은 모듈로 개선할 방안을 떠올리며, 최고 방안을 선택한 후 여기서 거기까지 이동하는 경로를 세웁니다.
즉, 깨끗한 코드를 작성하려면 코드 감각을 익혀야 하며 그 전에 깨끗함이 무엇인지 알 필요가 있습니다.
깨끗한 코드의 정의는 매우 다양합니다. 프로그래머 수만큼 말이죠..
그래서, 이 책에서는 유명하고 노련한 프로그래머들이 말하는 깨끗한 코드에 대한 의견을 소개했습니다.
이번 절에서는 이 의견들 중 인상깊은 내용에 대한 소개를 하고자 합니다.
- 깨끗한 코드는 잘 읽혀야 한다.
많은 의견 중 공통적인 가장 첫번째 의견은 잘 읽히는 코드여야 한다고 합니다.
잘 읽히는 코드는 우아하며, 보기에 즐거워야 합니다.
잘 쓴 문장처럼 잘 읽히며, 설계자의 의도를 숨기지 않습니다. 추측이 아닌 사실에 근거해야 하며, 필요한 내용만 담아야 합니다.
또한, 표현력 역시 명확해야 할 것입니다. (이름짓기 등..)
이와 같이 깨끗한 문장은 작성자와 구독자 모두 읽기 쉬워야 하며, 고치기도 쉬워야 합니다.
- 깨끗한 코드는 한가지 일을 제대로 한다.
수많은 소프트웨어 원칙은 이 간단한 교훈 하나로 귀결됩니다.
나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려집니다.
깨끗한 코드는 한가지에 '집중'하며, 각 함수, 클래스, 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한 길만 걷는다고 합니다.
'메소드 추출' 과 같은 리팩토링은 이 교훈을 따르기 위한 방법입니다.
- 깨끗한 코드는 짐작했던 기능을 그대로 수행한다.
이 내용은 매우 당연하지만, 심오한 내용입니다.
하지만, 짐작했던 그대로 수행하는 모듈은 생각보다 많지 않을 것입니다.
(헷갈리고, 모듈끼리 복잡하게 엉켜있고, 또는 엉뚱한 기능도 수행하고.. ㅜㅡㅜ)
깨끗한 코드는 읽으면서 놀랄 일이 없어야 합니다.
각 모듈은 다음 무대를 준비하며, 다음에 벌어질 상황이 보여야 합니다.
즉, 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 된다고 합니다.
실제 책의 내용에는 조금 더 공감되고 좋은 내용이 더 있었습니다.
하지만, 모든 내용은 결국 모듈을 한 가지 일만 하도록 최대한 작게 구현하며, 의도를 잘 표현할 수 있도록 세심한 주의 할 것을 말합니다.
마지막으로 한가지 생각해 볼 것은 코드를 잘짜는 것이 전부가 아니라는 것입니다.
시간이 지나도 언제나 깨끗함을 유지하는 것이 더 중요한 듯 합니다.
'소프트웨어 장인정신' 에서도 언급하는 보이스카우트 규칙은 이 내용을 말하고 있습니다.
"캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라!"
시간이 지날수록 코드가 좋아지는 프로젝트에서 작업한다면 얼마나 좋을까요?
사실 전문가라면, 너무도 당연한 이야기입니다.
'지속적인 개선이야말로 장인 정신의 본질'이라는 저자의 말을 남기며, 이번 포스팅을 마칩니다.
 |
|
'개발이야기 > Clean Code' 카테고리의 다른 글
| 의미 있는 이름 (6) | 2018.01.07 |
|---|---|
| [프롤로그] Clean Code (0) | 2018.01.05 |