일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 자료구조
- I/O장치
- Direct12
- 동적계획법
- 프로그래머스
- 락
- 백준
- 영속성
- 알고리즘
- 그리디알고리즘
- 타입 객체
- 병행성
- DirectX12
- DirectX 12
- 스케줄링
- 다이나믹프로그래밍
- 멀티프로세서
- 운영체제
- 다이나믹 프로그래밍
- 렌더링 파이프라인
- 병행성 관련 오류
- 멀티쓰레드
- codility
- directx
- 파일시스템 구현
- 쓰레드
- 컨디션 변수
- 디자인패턴
- OS
- 그리디 알고리즘
- Today
- Total
기록공간
[Clean Code] 1. 깨끗한 코드 본문
코드가 존재하리라
코드는 요구사항을 상세히 표현하는 수단이다.
기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 이것이 프로그래밍이고, 이렇게 명시한 결과가 바로 코드이다.
언젠가는 코드가 사라져 시키는 대로 돌아가는 무언가가 나올 거라 기대하는 사람들이 있지만, 이는 절대로 불가능한 기대이다. 창의력과 직관을 보유한 인간조차도 성공적인 시스템을 구현하기 힘들다.
궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심하자.
요구사항에 가까운 언어를 만들 수도 있고, 정형 구조를 뽑아내는 도구를 만들 수도 있다.
하지만 어느 순간에는 정밀한 표현이 필요하다. 그 필요성을 없앨 방법은 없다. 그러므로 코드도 항상 존재하리라.
나쁜 코드
프로그래머들은 좋은 코드가 중요하다는 사실을 안다. 왜냐면 오랫동안 나쁜 코드에 시달려 왔기 때문이다.
나쁜 코드는 조금만 건들여도 버그가 나기 일수이고 유지보수도 정말 힘들다. 이런 코드로 도배되어 있는 회사는 얼마 못가 망한다. 보통 나쁜 코드는 출시에 임박하여 코드를 마구 짜서 생기는 결과물이라고 할 수 있다.
나쁜 코드는 회사의 존폐위기를 좌지우지할 정도로 영향력이 있기 때문에 꼭 해결하고 넘어가야한다.
과연 나쁜 코드가 급해서 서두르느라 나온 결과물일까? 아마 그랬을것이다. 하지만 다른 이유도 존재한다.
우리는 언젠가 자신이 짠 나쁜 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있을것이다. 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안돌아가는 프로그램보다 좋다고 스스로를 위로한 경험이 있을것이다.
그리고 나중에 다시 돌아와 정리하겠다고 다짐했을 것이다. 하지만 나중을 결코 오지 않는다.
나쁜 코드로 치르는 대가
나쁜 코드는 개발 속도를 크게 떨어뜨린다. 프로젝트 초반에는 빠를지 몰라도 몇년만에 속도가 급격하게 떨어진다.
코드를 고칠때마다 엉뚱한 곳에서 문제가 생긴다. 나쁜 코드가 쌓일수록 생산성은 떨어진다. 생산성이 떨어질때마다 팀에서는 생산성을 높여야 한다는 극심한 압박에 시달린다. 이는 결국 더 나쁜 코드를 양산할 뿐이다. 결국 마지막은 생산성이 거의 0에 수렴하게 된다.
원대한 재설계의 꿈
결국 이런 프로젝트는 혐오스러운 코드로 부터 해방되기 위해 재설계에 들어간다.
이러한 재설계는 비용도 많이 들 뿐만아니라, 개발 기간도 오래 걸리게 된다. 재설계가 잘 되리라는 보장도 없다.
처음부터 깨끗한 코드로 만들려고 노력한다면 이러한 비용을 절감할 수 있을 뿐만 아니라 개발 기간도 단축시킬 수 있다. 덤으로 전문가로서 인정 받을 수도 있으리라.
태도
나쁜 코드가 우리 프로그래머 만의 잘못은 아니라고 생각할 수 있을 것이다. 부정확한 요구사항, 빡빡한 일정, 마케팅 등 여러 이유를 들것이다. 하지만 프로그래머는 프로젝트를 계획하는 과정에 깊숙히 관여한다. 그러므로 프로젝트 실패는 프로그래머에게도 커다란 책임이 있다. 특히 나쁜 코드가 초래하는 실패는 더더욱 책임이 크다.
일정과 요구사항을 강력히 밀어붙이는 것은 그들의 책임이듯, 좋은 코드를 사수하는 일은 프로그래머의 책임이다.
의사를 비유로 들어보자. 어느 환자가 수술 전에 손을 씻지 말라 요구한다. 시간이 오래 걸리니까.. 환자는 어떻게 보면 상사이다. 하지만 의사는 단호히 거부한다. 질병과 감염의 위험은 환자보다 의사가 더 잘 알기 때문이다. 환자 말을 그대로 따르는 행동은 전문가답지 못하다.
프로그래머도 마찬가지다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
원초적 난제
나쁜 코드를 양산하면 기한을 맞추지 못한다. 오히려 엉망진창인 상태로 인해 속도가 늦어지고, 결국 기한을 놓친다.
기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
깨끗한 코드라는 예술?
안타깝게도 깨끗한 코드를 구현하는 것은 그림을 그리는 행위와 비슷하다.
그림을 보면 대부분의 사람은 잘 그렸는지 엉망으로 그렸는지 안다. 그렇다고 잘 그린 그림을 구분하는 능력이 그림을 잘 그리는 능력은 아니다.
다시 말해, 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 꺠끗한 코드를 작성할 줄 안다는 뜻은 아니다.
깨끗한 코드를 작성하는 프로그래머는 빈 캔버스를 우아한 작품으로 바꿔가는 화가와 같다.
깨끗한 코드란?
깨끗한 코드란 과연 무엇일까? 이 분야에서 유명하고 노련한 프로그래머들의 의견을 들어보자.
- 비야네 스트롭스트룹(C++ 창시자) :
"나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 깨끗한 코드는 한 가지를 제대로 한다." - 그래디 부치(UML 창시자) :
"깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다." - 데이브 토마스(OTI 창립자이자 이클립스 전략의 대부) :
"깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미있는 이름이 붙는다. 특정 목적을 달성하는 방법은 하나만 제공한다. 의존성은 최소이며 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에 코드는 문학적으로 표현해야 마땅하다." - 마이클 페더스(레거시 코드 활용전략 저자) :
"깨끗한 코드의 특징은 많지만 그 중에서도 모두를 아우르는 특징이 하나 있다. 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로, 고칠 궁리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다." - 워드 커닝햄(위키 창시자) :
"코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다."
결론
깨끗한 코드를 짤 수 있도록 사용하는 기법이나 도구, 그리고 생각하는 방식을 알더라도 뛰어난 프로그래머가 된다는 보장은 없다. 하지만 적어도 이를 터득하고 실천하려고 노력 할 수만 있다면 뛰어난 프로그래머에 한 층 더 가까워질 것이다. 결국 연습만이 살길이다..
'Java > Clean Code' 카테고리의 다른 글
[Clean Code] 3. 함수 (0) | 2021.09.29 |
---|---|
[Clean Code] 2. 의미 있는 이름 (0) | 2021.09.17 |