Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
TIL-5 형식 맞추기
by leeq
#clean_code
2년 전
832

TIL (Today I Learned)

2022.02.28

오늘 읽은 범위

5장. 형식 맞추기

책에서 기억하고 싶은 내용을 써보세요

  1. 코드 형식은 의사소통의 일환이다. - p96

  2. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아 놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. - p96

  3. 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다. - p97

  4. 신문 기사처럼 작성하라. - p98

  5. 빈 행은 새로운 개념을 시작한다는 시각적 단서다. - p98

  6. 변수는 사용하는 위치에 최대한 가까이 선언한다. - p101

  7. 친화도가 높을수록 코드를 가까이 배치한다. - p106

  8. 그러면 소스 코드 모듈이 고차원에서 저차원으로 자연스럽게 내려간다. - p107

  9. 가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다. - p108

  10. 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다. - p113

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

테세우스와 아테네의 젊은이들이 탄 배는 서른 개의 노가 달려 있었고, 아테네인들에 의해 데메트리오스 팔레레우스의 시대까지 유지 보수되었다. 부식된 헌 널빤지를 뜯어내고 튼튼한 새 목재를 덧대어 붙이기를 거듭하니, 이 배는 철학자들 사이에서 일어나는 ‘자라는 것들에 대한 논리학적 질문’의 살아있는 예가 되었는데, 어떤 이들은 배가 그대로 남았다고 여기고, 어떤 이들은 배가 다른 것이 되었다고 주장하였다.

- 플루타르코스

이 장의 서론을 읽으며 문득 위의 "테세우스의 배" 라는 철학적 문제가 생각났다. 한 마디로 요약하자면, "오랜 시간이 흘러 테세우스의 배의 모든 나무 조각들을 교체한다면 그것을 테세우스의 배라고 할 수 있는가?" 라는 문제이다. 나도 나름의 답을 지니고 있는데, 내 생각은 "테세우스의 배라고 볼 수 없다." 이다. 배에는 용골이라는, 배의 중심축이 되는 건축물로 치자면 대들보와 같은 뼈대 부품이 있다. 보통 이 부품이 파손된다면 배는 수리가 불가능할 정도로 중요한 부품이다. 즉, 태세우스의 배의 용골을 비롯한 모든 부품을 교체하였다면, 그것은 테세우스의 배의 부품을 재활용하여 다른 배를 건조한 것이라 볼 수 있다.

클린 코드 책을 읽다 뜬금 없는 태세우스의 배니 용골이니 하는 이야기를 왜 쓰고 있는가 하면, 코드에게 스타일은 용골과 같은 것이기 때문이다. 진행 중인 프로젝트의 코드는 끊임 없이 진화한다. 버그를 수정할 수도 있고, 새로운 기능을 추가할 수도 있다. 이미 퍼블리시된 프로젝트라도 말이다. 그 과정에서 명확하게 정립된 스타일은 큰 도움이 된다. 변수를 찾기 위해 파일을 뒤적이지 않아도 되고, 함수와 클래스는 있으리라 예상하는 곳에 존재한다. 약간 과장하자면 스타일은 팀의 아이덴티티라고 할 수 있다. 코드와 기능은 그 위에 얹어질 뿐이다.

팀으로 일할 때는 스타일이 더 중요한 역할을 한다. 내가 작성해도 다시 돌아보면 알아보기 힘든 것이 코드인데, 다른 스타일로 작성된 코드는 한 번에 이해하지 못하는 것이 당연하다. 때로는 스타일이 맞지 않는 코드를 이해하는 것보다, 내 스타일로 고쳐서 쓰는 것이 더 빠른 경우도 있었다. 이와 관련된 일화들도 많지만, 협업 경험에 대한 푸념은 이전 장들에서 많이 썼으니 이 장에서는 쓰지 않겠다. 최근에는 사용자 정의 규칙을 지원하는 코드 분석 툴이 많으니, 이에 대해 더 공부해봐야겠다.

이 장에서는 코드 형식의 중요성에 대해 다시 생각해볼 수 있었다. 다만, 예시로 나열한 형식들은 일반적인 Syntax나, Convention이라고 할만한 것들이라, 크게 와닿지는 않았다. 또한 일부 차트는 로그 스케일을 사용하지 않는 것이 데이터의 차이를 더 극명하게 보여줄 수 있을 것 같아서 아쉬웠다.

나도 나름의 코딩 스타일이 있지만, 이 장에서 설명해주는 것처럼 일반적인 스타일과는 동떨어진 부분도 있다. 예를 들어, 소스 코드의 추상화 수준이 고차원에서 저차원으로 내려가도록 작성하는 것을 간과할 때가 많다. 변명을 하자면, 이는 인터프리터 언어를 사용하던 버릇이다. 인터프리터 언어에서는 함수나 변수를 선언 전에 사용할 수 없으니까 말이다. 하지만 이 책에서 함수 파트를 읽고 난 이후에는 이 문제를 주의하여 코딩하고 있다.