클린코드 (애자일 소프트웨어 장인 정신)
나쁜코드
80년대 후반 킬러 앱을 구현한 회사가 있었다. 회사가 성장하면서 개발 주기가 늘어나며, 이전 버전에 있던 버그가 다음 버전에도 그대로 남아 있어 프로그램 시동 시간이 길어지고 프로그램이 죽는 횟수도 늘어났다. 얼마 못가 그 회사는 망했다.
회사가 망한 이유에는 무작위로 짠 코드들 때문이었다. 출시가 바빠 코드를 마구잡이로 짯고, 기능을 추가 할수록 코드는 엉망이되어 감당이 불가능 하였다. 회사가 망한 원인은 나쁜 코드 탓이었다.
르블랑의 법칙: 나중은 결코 오지 않는다.
대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼고 나중에 정리하겠다고 다짐하고 하지 않으면 르블랑의 법칙을 깨닫게 될것이다.
기한을 맞추는 유일한 방법은 깨끗한 코드를 유지하는 방법이다.
깨끗한 코드란?
아마 프로그래머 수만큼이나 정의도 다양할 것이다.
비야네 스트롭스트룹 (C++의 창시자이자 The C++ Programming Language 저자)
"나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 깨끗한 코드는 한 가지를 제대로 한다. "
그래디 부치(Object Oriented Analysis and Design with Application 저자)
"깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
가그래디는 비야네와 흡사하지만 가독성을 강조한다.
큰 데이브 토마스(OTI 창립자이자 이클립스 전략의 대부)
"깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미 있는 이름이 붙는다. 특정 목적을 달성하는 방법은 하나만 제공한다. 의존성은 최소이며 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에 코드는 문학적으로 표현해야 마땅하다.
큰 형님 데이브도 가독성을 강조하지만 다른 사람이 고치기 쉽다고 단언한다.
마이클 패더스(Working Effectively with Legacy Code의 저자)
"깨끗한 코드의 특징은 많지만 그 중에서도 모두를 아우르는 특징이 하나 있다. 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로, 고칠 궁리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다.
한마디로 요약하면 '주의'이다 이것이 이 책의 주제이다.
론 제프리스(Extreme Programming Installed와 Extreme Programming Adventure in C# 저자)
켄트 벡이 제안한 단순한 코드 규칙으로 구현을 시작한다.
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.
제프리스가 말하는 점은 같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다.
워드 커닝햄(위키 창시자, 익스트림 프로그래밍 공동 창시자, 디자인 패턴을 뒤에서 움직이는 전문가, 소몰토크와 객체지향의 정신적 지도자, 코드를 사랑하는 프로그래머들의 대부)
코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.
이 책에서는 깨끗한 코드를 짜는 법을 설명 해준다.
보이스카우트 규칙
잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다. 시간이 지나면서 엉망으로 전락하는 코드가 한둘이 아니다.
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라
체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.
의미있는 이름
소프트웨어에서 이름은 어디나 쓰인다. 우리는 변수에도 이름을 붙이고, 함수에도 이름을 붙이고, 인수과 클래스와 패키지에도 이름을 붙인다. 소스 파일에도 이름을 붙이듯 이름을 잘 지으면 여러모로 편하다. 이름을 잘 짓는 간단한 규칙을 몇개 알아보자.
- 의도를 분명히 밝혀라
의도가 분명한 이름이 정말로 중요하다. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
EX.
int d; //time
int time // time이름 d는 아무 의미도 드러나지 않는다. time 처럼 이름을 사용하면 코드이해와 변경이 쉬워진다.
- 그릇된 정보를 피하라
프로그래머는 코드에 그릇된 단서를 남겨서는 안된다. 코드의 의미를 흐리기 때문이다. 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다.
서로 흡사한 이름을 사용하지 않도록 주의한다. 이렇게 일관성이 떨어지는 표기법은 그릇된 정보이다.
- 의미 있게 구분하라
컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다. 예를 들어, 동일한 범위 안에서는 다른 두 개념에 같은 이름을 사용하지 못한다.
- 발음하기 쉬운 이름을 사용하라
사람들은 단어에 익숙하다. 우리 두뇌에서 상당 부분은 단어라는 개념만 전적으로 처리한다. 정의상 단어는 발음이 가능하다 말을 처리하려고 발달한 두뇌를 활용하지 않는다면 안타까운 손해다. 그러므로 발음하기 쉬운 이름을 선택하여야 한다.
- 검색하기 쉬운 이름을 사용하라
문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다. 상수가 여러 자리 숫자이고 누군가 상수 내 숫자 위치를 바꿧다면 검색으로 찾아내지 못한다.
- 인코딩을 피하라
새로운 개발자가 익힐 코드 양은 상당히 많다. 인코딩 언어까지 익히라는 요구는 비합리적이다. 문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다.
- 자신의 기억력을 자랑하지 마라
독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다. 똑똑한 프로그래머와 전문가 프로그래머 사이에서 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고이다.
- 클래스 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합하다. 동사는 사용하지 않는다.
- 메서드 이름
메서드 이름은 동사나 동사구가 적합하다.
- 기발한 이름은 피하라
이름이 너무 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만, 이름을 기억한다. 재미보단 명료한 이름을 선택하라.
- 한 개념에 한 단어를 사용하라
추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 똑같은 메서드를 클래스마다 다르게 부르면 혼란을 야기한다. 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다.
- 말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
- 해법 영역에서 가져온 이름을 사용하라
코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다. 기술 개념에는 기술 이름이 가장 적합한 선택이다.
- 문제 영역에서 가져온 이름을 사용하라
적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다. 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다.
- 의미 있는 맥락을 추가하라
스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
ex. firstname, lastname -> addrfirstname, addrlastname
- 불필요한 맥락을 없애라
예를 들어 GSD라는 이름을 쓰고싶은데 IDE에서는 G를 누르고 자동 완성 키를 누르면 IDE는 모든 클래스를 열거하므로 현명하지 못하다.
헝가리식 표기법
자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다. 객체는 강한타입이며, IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다.
마치면서
좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야한다. 이것이 제일 어렵다. 좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육 문제이다.
