나쁜코드
프로그래머라면 나쁜코드로 고생한 적이 분명히 있을 것이다. 그것을 “고향”이라 부른다.
노력하다 마감시간이 다가오면 결국 소스코드는 더러워지는 경우가 정말 많고 나중에 다시 다듬어야지 생각하면서 정상적으로 돌아가는 기능에 안도감을 느껴 그대로 방치하는 경우가 태반이다.
이것을 르블랑의 법칙 “나중은 결코 돌아오지 않는다”라고 말한다.
나쁜코드의 문제점 ?
- 나쁜코드의 문제점은 개발 속도를 크게 저하시킨다.
- 코드를 고치다 보면 엉뚱한 곳에서 문제가 많이 생긴다.
- 즉 간단한 변경이 없음
- 이러한 작업을 반복하다 보면 결국 개선이 아니라 더욱 쓰레기 더미는 높아지고 청소할 방법이 없어지게 된다.
- 나쁜 코드가 쌓일수록 팀의 생산성은 떨어진다.
- 이러한 상황에서 생산성을 증가시키기 위해 인력을 투입하지만 새 인력은 기존의 시스템 설계에 대한 이해가 깊지 않기 때문에 변경과 설계 의도에 반하는 변경을 구분하지 못하게 된다.
왜 나쁜 코드를 작성하게 되는 것일까?
가장 큰 이유는 기한을 맞추기 위해 나쁜코드가 작성된다고 나와있고 대부분 그렇게 생각할 것이다.
하지만 좋은 개발자들은 위의 이유가 틀린 것을 알고 있다.
- 그 이유는 나쁜 코드를 작성할수록 엉망진창이기 때문에 속도가 곧바로 늦어지고 결국 기한을 놓치게 된다.
- 기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 방법이다.
그래서 깨끗한 코드가 뭘까?
- 깨끗한 코드를 작성하는 방법은 그림을 그리는 행위와 비슷하다. 그림을 보면 대부분의 사람은 잘 그려졌는지 엉망으로 그려졌는지 알 수 있다.
- 하지만 잘 그린 그림을 구분하는 능력이 그림을 잘 그리는 능력은 아니다. 즉 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 해서 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.
- 깨끗한 코드를 작성하려면 “청결”이라는 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다.
- 열쇠는 “코드감각”이다 어떤 사람은 “코드감각”을 타고나고 어떤 사람은 투쟁해서 얻어야 한다.
- “코드감각”이 있으면 좋은 코드와 나쁜 코드를 구분하고 절제와 규율을 적용하여 나쁜코드를 좋은 코드로 바꾸는 전략도 파악한다.
- “코드감각”이 없는 개발자도 나쁜 모듈을 알아보지만 그것 뿐이다.
유명한 사람들의 깨끗한 코드
비야네 스트롭스트룹(C++ 창시자)
나는 우아하고 효율적인 코드를 좋아한다.
- 논리가 간단해야 버그가 숨어들지 못한다.
- 의존성을 최대한 줄여야 유지보수가 쉬워진다.
- 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.
- 성능을 꼭 “속도”를 뜻하는 것은 아니다.
- 나쁜코드는 나쁜코드를 유혹한다.
- 오류는 명백한 전략에 의거해 철저히 처리한다.
- 깨끗한 코드는 한 가지를 제대로 한다.
그래디 부치
깨끗한 코드는 단순하고 직접적이다.
- 깨끗한 코드는 단순하고 직접적이다.
- 깨끗한 코드는 잘 쓴 문장처럼 읽힌다
- 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다.
- 명쾌한 추상화와 단순한 제어문으로 가득하다
데이브 토마스
깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
- 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
- 단위 테스트 케이스와 인수 테스트 케이스가 존재한다.
- 의미있는 이름이 붙는다.
- 특정 목적을 달성하는 방법은 하나만 제공한다.
- 의존성은 최소이며 각 의존성을 명확히 정의한다.
- API는 명확하며 최소로 줄인다.
마이클 페더스
깨끗한 코드는 누군가 주의 깊게 짰다는 느낌을 준다.
- 깨끗한 코드는 주의 깊게 작성한 코드다.
- 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드 세세한 사항까지 꼼꼼하게 신경쓴 코드라고 말할 수 있다.
론 제프리스
중복에 집중한다.
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.