1장 깨끗한 코드

책의 목표

• 코드에 대해 많은 사실을 학습
• 좋은 코드와 나쁜 코드를 구분하는 능력
• 좋은 코드를 작성하는 방법
• 나쁜 코드를 좋은 코드로 바꾸는 실력

 

코드가 존재하리라

• 코드는 요구사항을 상세히 표현하는 수단이다!
  • 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다.
  • 고도로 추상화된 언어나 특정 응용 분야 언어로 기술하는 명세 역시 코드이다.
    1. 추상화된 요구사항을 명확한 정형 구조로 뽑아내는 도구도 코드이다.

코드는 사라질 가망이 전혀 없다!

 

나쁜 코드

• 읽기 어려운 코드
  • 이해해보면 정말 간단한 코드인데 이해하려면 수 차례 읽어봐야 한다.
• 수정하기 어려운 코드
  • 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생겨 매번 얽히고설킨 코드를 '해독'해야 한다.

 

나쁜 코드를 짜게 되는 이유?

• 일정을 압박하는 상사, 멍청한 관리자 쓸모없는 마케팅 관리자?
  • 사용자 요구사항에 맞춰 설계를 하고, 정보를 얻고, 프로젝트를 계획한다. 하지만 촉박한 일정에 전문가가 아닌 상사의 요구에 혼나지 않으려고 거기에 맞춰 코드를 빠르게 '나중에' 리팩터링 해야지 뭐 하는 마음으로 코드를 '양산'한다.
    • '나중은 결코 오지 않는다. (르블랑의 법칙)

지금은 일정이 빠듯하니 기능만 구현하고 나중에 수정하자!!라는 말은 정말 나도 프로젝트를 진행하면서 내뱉은 말이라 공감이 많이 되었습니다.. 정말 작은 기능이었지만 그 후에 리팩터링 하면서 시간을 많이 썼던 경험이 있습니다 ㅠㅠ

 

설계와 요구사항 분석을 꼼꼼히 확인한 후 TDD를 통해 구현해야 할 기능에 대한 테스트 정리를 하고 진행하는 이유가 여기에서 나오는 것인가... 내가 경험했던 내용을 책에서 보니 감회가 새롭다! 진짜 생산성을 떨어뜨리는 일이었음을 깨달았다..

처음 프로젝트 진행할 때 구현해야할 기능을 메모장에 적어놓고 했었던.. ㅎㅎ,,., 내가 창피했다.. (이러니 계속 생각한 기능이 바뀌었었지..)

또 정말 와닿는 문장이 있었다.

본인이 의사이고 환자가 상사라면 환자의 요구를 무조건 들어야 하는가?
전문가는 의사인 나인데 혼나지 않기 위해? 나의 전문성을 뒤로한 채로 상사의 요구사항에 맞춰야 하는가?
이것은 범죄와 같다고 표현해주셨다. 

맞는 말이다. 나도 전문가이니까 기획, 관리자 말을 그대로 따르는 행동보단 조율하고 원하는 니즈가 무엇인지 정확히 분석해야겠다.

프로그래머로선 고민하고 시간을 들여서 깨끗한 코드를 만들려고 노력해야겠다!

매번 코드를 볼 때마다 고치고 싶은 욕구가 생기는 건 '코드 감각'이 있다는 증거라 생각하고 자신감을 가지자!

 

깨끗한 코드란?

깨끗한 코드는 한 가지를 제대로 한다.
- 비야네 스트롭 스트룹(C++ 창시자이자 The C++ Programming Language 저자)

비야네는 우하하고 효율적인 코드를 좋아하는데, 그런 코드는 '보기에 즐거운' 코드이다.

보기에 즐거운 코드라는 게 와닿는다. 읽으면서 이해되는 코드를 보면서 막 가슴속에 차오르고 기분이 좋았던 경험이 있는데 그때가 아무래도 보기에 즐거운 코드를 읽어서 인지 아닐까 싶었다.

 

한 가지에 집중하는 코드, 각 함수와 클래스와 모듈은 항상 주변 상황에 현혹되거나 오염될 수 있으니 한 가지에만 집중할 수 있도록 하자!

 

깨끗한 코드는 단순하고 직접적이며 잘 쓴 문장처럼 읽힌다.
- 그래디 부치(OOADA 저자)

책을 읽을 때 단어가 사라지고 이미지가 떠오르는 경험이 있지 않은가? 이를 보고 잘 쓰인 책이라고 하며, 코드를 봤을 때 어떤 의도인지 명확하게 명쾌하게 작성되어야 하기 때문에 코드는 추측이 아니라 사실에 기반해야 한다.

 

읽기 쉽고 고치기도 쉬우며 테스트 케이스가 존재하고 이름, 의존성을 명확히 정의한다.
- 데이브 토마스(OTI 창립자이자 이클립스 전략의 대부)

마찬가지로 읽기 쉬운 코드, 가독성을 중요시 하지만 여기에 고치기도 쉽고 테스트가 잘 짜여 있다고 했다. 이 말에도 공감할 수 있는 경험이 있다는 것에 책을 읽는 재미가 더해지는 것 같다.

테스트 주도 개발을 하기 전 기능을 마구 추가한 후 테스트 코드를 짠 경험이 있는데 정말.. 복잡하고 여기저기 꼬여있고 의존성이 마구 연결된 기능에 대한 단위 테스트는 끔찍했다..

아무리 코드가 가독성이 높아도 테스트 케이스가 없으면 깨끗한 코드라 할 수 없다..

손댈 곳 없이 주의 깊게 짰다는 느낌을 주는 코드. 고칠 궁리를 하다 보면 언제나 제자리로 돌아오는 코드.
- 마이클 페더스(Working Effectively with Legacy Code 저자)

코드 리뷰를 할 때 (리드 개발자 없이 우리끼리 프로젝트를 진행하며..ㅎㅎ) 전체의 그림을 그리는 능력은 아직 부족하지만... 손댈 부분이 없는 것 같다고 생각했던 적이 있는데 이런 느낌의 이야기가 아닌가 싶다.!

나도 주의 깊게 짜려고 노력하고 시간을 많이 쓰지만 항상 에러 발생 위험이 있는 부분이 나왔다는..

중복을 줄이고 이름에 대한 표현력을 높이고, 초반부터 간단한 추상화 고려하기가 깨끗한 코드를 만드는 비결이다.
-론 제프리스(EPI, EPA in C# 저자)

짐작했던 기능을 각 루틴이 그대로 수행한다.
- 워드 커닝햄(위키 창시자, 피트 창시자,... 코드를 사랑하는 프로그래머들의 대부)

코드를 독해하느라 머리를 쥐어짤 필요가 없어야 하고, 설계자가 코드를 어이없을 정도로 단순하게 설계해 모듈을 읽으면 다음에 벌어질 상황이 보이는 것이 깨끗한 코드라고 할 수 있다.

 

우리는 저자다

Javadoc에서 @author 필드는 저자를 소개한다. 저자에게는 독자가 있고 독자와 잘 소통할 책임도 있다. 다음에 코드를 짤 때 우리 자신이 저자가 된다. 따라서 독자와 잘 소통할 책임이 우리에게도 있으니 소통을 잘할 수 있는, 깨끗한 코드를 짜야 독자가 모듈을 이리저리 왔다 갔다 하는 시간을 줄여줄 수 있을 것이다!

 

보이스카우트 규칙

'캠핑장은 처음 왔을 때보다 더 깨끗하게 해 놓고 떠나라.'

한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요는 없다.

변수 이름 하나 개선하고, 조금 긴 함수 하나를 분할하고,... 

시간이 지날수록 코드가 좋아지는 프로젝트를 하자!!

 

1장은 깨끗한 코드 즉, 한 가지의 기능을 하고, 읽기 쉽고 고치기 쉽고, 테스트 코드가 있고, 짐작한 기능이 제대로 작동하는 코드를 짜기 위해 어떤 마음가짐을 가져야 하며 무엇을 중시해야 하는지 어떤 자세로 개발에 임해야 하는 지를 리마인드 할 수 있었던 것 같습니다. 특히 개발에 있어서 뭐라고 명확히 정의를 내릴 수 없었던 부분을 정리할 수 있어서 좋았던 것 같습니다!