Clean Code : 추천사 및 1장(깨끗한 코드)
Clean Code : 추천사 및 1장(깨끗한 코드)
다니는 회사의 인턴 부터 시작해 정규직이 되고 난 후, 신규 프로젝트에 투입되었는데, 다른 사람의 코드를 분석하고 활용해야 하는 경우가 많았습니다. 예전부터 확장성 있고 효율적인 좋은 코드에 대해 관심이 있었지만, 이번 신규 프로젝트를 통해 좋은 코드의 중요성에 대해 한 번 더 느끼게 되어 공채 동기들과 함께 Clean Code - 로버트 C. 마틴을 베이스로 하는 Clean Code 스터디를 시작하게 되었습니다.
추천사
James O. Coplien의 추천사는 덴마크의 속담인 사소한 곳에서 발휘하는 정직은 사소하지 않다라는 문구로 시작합니다. 이 속담이 저에게는 사소한 것에 신경쓰고 관심가지는 것이 모여 큰 것을 이룬다는 의미로 다가왔는데, 평소에 좋아한 미켈란젤로의 I know. I"ve been there.(내가 안다.)라는 말이 나오는 일화와 비슷한 느낌의 속담이라 반가웠습니다 :)
추천사에서 5S 원칙을 소개하였는데, 이 5S 원칙은 소프트워에 개발자라면 선택이 아니라 필수라고 소개했습니다. 5S 원칙은 아래와 같습니다. (덴마크어로 되어있는 것 같습니다.)
Seiri(정리 or 조직 or 정렬): 적절한 명명법 등과 같은 방법을 사용해 무엇이 어디에 있는지 알아야 합니다.Seiton(정돈 or 단정함 or 체계화): 코드는 누구나 예상하는 위치에 있어야 합니다.Seiso(청소 or 정리 or 광내기): 과거 이력이나 미래에 대한 바람을 기재한 주석 혹은 주석으로 처리한 코드는 제거해야 합니다.Seiketsu(청결 or 표준화): 그룹 내에서 일관적은 구현 스타일과 기법이 필요합니다.Shutsuke(생활화 or 규율): 관례를 따르고 자기 코드를 자주 돌아보고 변경해야 합니다.
5번은 진정으로 책임 있는 개발자라면 제품 생명주기까지 고려해야 한다는 의미라고 합니다.
1장. 깨끗한 코드
왜 좋은 코드가 중요할까요?? 좋은 코드의 장점을 나열하기 보다는 좋은 코드를 신경쓰지 않아 망한 회사를 예를 들어보겠습니다.
80년대 후반 킬러 앱 하나를 구현한 회사가 있었습니다. 제품은 커다란 인기를 끌었는데, 제품 출시 주기가 점점 늦어지더니 버그와 프로그램이 죽는 횟수가 늘어나더니 결국 회사가 망했습니다. 원인은 예상하다시피 출시에 바빠 구현에만 신경쓴 코드를 작성하였다는 것입니다. 때문에 기능을 추가할수록 코드는 엉망이 되어갔고 결국은 감당이 불가능한 수준에 이르렀습니다. 즉, 회사가 망한 원인이 나쁜 코드 탓이었던 것입니다.
여기서 생각해볼 것은 왜 나쁜 코드를 작성하는 것일까요??라는 물음입니다. 대부분은 급해서, 서두르느라, 나중에 고치려고 나쁜 코드를 작성하게 됩니다. 하지만 르블랑의 법칙(Leblanc's Law)에 따르면 나중은 결코 오지 않습니다. 위의 경우처럼 나쁜 코드는 극단적으로는 회사가 망할수도 있고, 개발 속도를 크게 떨어뜨리기 때문에 처음 부터 좋은 코드를 작성하는 것이 중요합니다.
르블랑의 법칙(Leblanc’s Law) : 나중은 결코 오지 않는다는 의미입니다. 나중에 손보겠다고 한 코드를 작성하면 돌아간다는 사실에 안도감을 느끼며 위로하게 되고 결국 고치지 않게 되는 것입니다.
하지만 나중에 리팩토링하면 되지 않을까 생각할 수 있습니다. 하지만 회사는 계속적으로 이윤을 창출해야 합니다. 때문에 새로운 서비스나 기능을 추가하면서 리팩토링 팀을 만들게 됩니다. 이 때부터는 리팩토링 팀과 기존 팀과의 경주가 시작되는 것입니다. 때때로 이 경주는 아주 오랫동안 이어지고 초기 레이스의 코드가 몇 년뒤의 경주에서는 나쁜 코드가 되어있을 가능성이 있습니다. 때문에 초기부터 깨끗한 코드를 만드려는 노력이 비용을 절감하고 전문가로서 살아남는 방법인 것입니다.
1-1. 태도
나쁜 코드가 생기는 이유는 가지각각 이지만 전적으로 프로그래머 잘못이라고 합니다.
예를 들어, 어느 환자가 수술 전에 손을 씻지 말라고 요구한다고 해도 의사는 단호하게 거부할 것입니다. 그 이유는 질병과 감염의 위험은 환자보다 의사가 더 잘 알고 그 행동은 전문가답지 못하기 때문입니다.
프로그래머도 마찬가지입니다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못한 것입니다.
나의 생각
저도 전적으로 프로그래머 잘못이라고 생각은 하지만,,, 정말 어쩔 수 없는 상황도 있다고 생각합니다. 때문에 이런 경우에는 프로그래머가 전적으로 책임지고 르블랑의 법칙을 깨뜨리려고 노력해야 한다고 생각합니다.
1-2. 원초적 난제
한두 해 이상 몸 담은 프로그래머라면 나쁜 코드가 업무 속도를 늦춘다는 사실을 알고 있습니다. 하지만 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 느낍니다. 하지만 오히려 나쁜 코드를 양산하는 것이 기한을 맞추지 못하게 될 수도 있습니다. 그러니까 기한을 맞추려면 코드를 최대한 깨끗하게 유지하는 습관이 필요합니다.
1-3. 깨진 유리창 이론과 보이스카웃 규칙
깨끗한 코드를 설명할 때 많이 나오는 이론을 소개하겠습니다.
깨진 유리창 이론: 깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론으로, 사소한 무질서를 방치하면 큰 문제로 이어질 가능성이 높다는 의미를 담고 있습니다.- 나쁜 코드를 방치하면 그 나쁜 코드를 중심으로 나쁜 코드가 확산된다는 의미로 많이 사용 됩니다.
보이스카웃 규칙: 엉망으로 어질러져 있는 곳을 발견하면, 일단 청소하고 누가 그렇게 했는지는 생각하지 말고 다음으로 야영하러 오는 사람들을 위해 신경써서 환경을 개선하라는 규칙으로 언제나 처음 왔을 때보다 깨끗하게 해놓고 캠프장을 떠날 것이라는 의미를 담고 있습니다.- 나쁜 코드를 발견하면 원래 코드를 작성한 사람이 누구이건 간에, 좋은 코드로 개선하려는 노력이 필요하다는 의미로 많이 사용 됩니다.
1-4. 깨끗한 코드란?
깨끗한 코드를 작성하려면 코드 감각이 필요합니다. 때문에 코드 감각을 키우기 위한 노력을 해야합니다. 아래는 유명하고 노련한 프로그래머들이 생각하는 깨끗한 코드에 대한 글입니다.
Bjarne Stroustrup(비야네 스트롭스트룹)
C++ 창시자 이자 The C++ Progrmming Language 저자 입니다. 효율적이고 꼼꼼한 처리를 강조하는 것을 볼 수 있습니다.
나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 깨끗한 코드는 한 가지를 제대로 한다.
Grady Booth(그래디 부치)
Object Oriented Analysis and Design with Application 저자 입니다. 가독성을 강조하는 것을 볼 수 있습니다.
깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
Big Dave Thomas(큰 형님 데이브 토마스)
큰 형님 이라는 것 보니 동생도 있는 것 같습니다. OTI 창립자이자 이클립스 전략의 대부입니다. 가독성을 강조하고 깨끗한 코드는 다른 사람이 고치기 쉽다고 단언하는 것을 볼 수 있습니다.
깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미 있는 이름이 붙는다. 특정 목적을 달성하는 방법은 여러 가지가 아니라 하나만 제공한다. 의존성은 최소이며 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에 코드는 문학적으로 표현해야 마땅하다.
Michael Feathers(마이클 페더스)
Working Effectively with Legacy Code저자 입니다. 코드를 주의 깊게 짜는 것이 중요하다고 강조하는 것을 볼 수 있습니다.
깨끗한 코드의 특징은 많지만 그 중에서도 모두를 아우르는 특징이 하나 있다. 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다.(작성자가 이미 모든 사항을 고려했으므로) 고칠 궁리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다.
Ron Jeffries(론 제프리스)
Extreme Programming Installed와 Extreme Programming Adventure in C#저자 입니다. 론은 스트레티직 에어 커맨드 사에서 포트란으로 프로그래밍을 시작한 이래 거의 모든 플랫폼에서 거의 모든 언어로 코드를 구현해왔다고 합니다. 중복과 표현력 높이기, 초반부터 간단한 추상화 고려하기 이 3가지만 신경 써도 깨끗한 코드라는 목표에 성큼 다가갈 수 있다고 강조합니다.
최근 들어 나는 켄트 벡이 제안한 단순한 코드 규칙으로 구현을 시작하고 끝낸다. 중요한 순으로 나열하자면 간단한 코드는 아래의 규칙을 만족합니다.
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.
규칙을 설명한 후 여러 내용이 있지만
- 중복을 피하라.
- 한 기능만 수행하라.
- 제대로 표현하라.
- 작게 추상화하라.
이 몇개의 문단으로 요약할 수 있습니다.
Ward Cunningham(워드 커닝햄)
Wiki(위키) 창시자, Fit(피트) 창시자, Extreme Programming(익스트림 프로그래밍) 공동 창시자, 디자인 패턴을 뒤에서 움직이는 전문가, 스몰토크와 객체 지향의 정신적 지도자, 코드를 사랑하는 프로그래머들의 대부 입니다. 명백하고 단순해 짐작한대로 돌아가는 코드가 깨끗한 코드라고 강조하는 것을 알 수 있습니다.
코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드로 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.
1-5. 1장을 마치며…
예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없으니, 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다고 이 책은 말합니다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개하는 것이기 때문에 이 책을 읽고 실무에서의 적용이나 코드 감각을 키우는 것은 이 책을 읽는 우리들에게 달렸습니다.
이 책은 객체 지향 설계 원칙 SOLID를 산발적으로 거론하기 때문에 SOLID를 알고가야 할 필요성이 있습니다.
참고 링크
참고 : Clean Code - 로버트 C. 마틴
댓글남기기