클린 코드

지방에서 일 하고 있어서 할 수 있는 개발 관련 스터디가 많이 없는데, 좋은 기회가 되어 온라인으로 책터디를 진행하게 되었습니다.

개발 관련 서적을 읽고, 간단하게 후기를 남기는 방식의 스터디였습니다. 적극적으로 이끌어주시는 리더님이 좋았고, 저를 포함한 팀원들의 읽고 난 다음에 책과 관련된 이야기를 나누는 것도 신선했습니다. 그리고 온라인으로 진행하는 스터디가 생각보다 큰 어려움이 없다는 것을 알 수 있게 되어 더 좋았습니다.

이번에 읽은 책은 클린 코드로, 첫 인상과 현재 느낌이 제일 다른 책이라고 말하고 싶습니다.

저는 기존 서비스를 유지보수하고, 새로운 기능을 추가하는 업무를 주로 맡고 있습니다. 남이 작성한 코드를 유지보수를 해야 할 때가 많았는데, 힘들었던 코드도 있었고, 비교적 수월하게 읽어지는 코드도 있었습니다. 학부때는 특정 기능을 빠르게 구현하는 것이 좋다고 생각했으나, 후자의 코드가 많이 중요하다는 것을 업무 중에 알게 되었습니다. 남들에게 읽기 쉽게 느껴지는 코드를 구현하기 위해 나름대로 많은 노력을 기울였습니다.

이 과정에서 신입 때 처음 읽었으나, 그 때와 지금 읽을 때는 사뭇 다른 느낌이었습니다. 첫번째로는 정말 많은 것을 배웠고, 두 번째는 그동안 고민해왔던 내용이 어느 정도 해소가 된다는 느낌을 받을 수 있었습니다.

읽으면서 인상적이었던 내용에 대해 순서대로 포스팅 해 보려고 합니다.

1. 읽기 쉬운 코드가 매우 중요한 이유

실제로 코드를 읽는 과정에서 얼마나 많은 노력이 필요하나요? 대부분의 노력은 코드를 짜는데 들어가지 않나요? 대부분이 화면을 스크롤하거나 다른 모듈을 찾아보는 동작이었다.

당장의 시간은 절약할 수 있지만, 이후의 시간을 아끼기 위해 코드를 잘 짜는 것이 아주 중요합니다.

• 보이스카우트 규칙

캠프장은 처음 왔을 때보다 더 깨꿋하게 해 놓고 떠나라

이전보다 반드시 코드가 깨끗해야 한다는 소리를 들었기 때문에, 최대한 열심히 깨끗하게 유지하기 위해 노력하고 있습니다!

2. 명칭

1) 변수는 반드시 의미 있는 이름으로 지어야 합니다.
2) 긴 범위에서 사용되는 이름은 긴 이름을 사용할 것

3. 함수

함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

함수는 작은 단위로, 한 가지 일만 해야 한다고 합니다. 업무 하다보면 쉽지 않은데, 최대한 크기를 줄이고, 함수화 시키려고 많은 노력 하고 있습니다.

• 최대한 함수의 파라미터 수를 줄일 것.
  실제로 파라미터가 많을 때 함수를 재사용하는데 많은 어려움이 있었습니다.

4. 주석

• 불필요한 주석은 지양
• 더 이상 필요없어진 주석은 지울 것
• 내가 구현했던 코드를 남이 사용할 수 있기 때문에, 사용시 필요한 정보는 반드시 주석으로 추가해야 함
• 추후 개선점으로 보이는 부분이 있으면 반드시 주석으로 남겨 놓을 것

5.클래스

1) 단일 책임 원칙

단일 책임 원칙 (Single Responsibility Principle) : 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 함

• 클래스가 가지는 책임은 단 하나여야 합니다.

2) OCP

Open-Closed Principle : 클래스는 확장에 대해 열려있어야 하고 수정에 대해 닫혀있어야 한다.

6. 점진적인 개선

• 돌아가는 코드를 만든 뒤 정리할 것.

• 처음부터 깨끗한 코드를 작성하고, 개선할 것

오래된 의존성을 찾아내 깨려면 상당한 시간과 인내심이 필요하다. 반면 처음부터 코드를 깨꿋하게 유지하기란 상대적으로 쉽다

처음부터 깨끗하게 유지할 것!

7. 냄새와 휴리스틱

• 경계조건에 대한 테스트 추가
• 죽은 코드 삭제
• 중복 코드 삭제
• 부적절한 static 지양 : static 변수를 여러군데에서 고치게 되면, 문제가 생겼던 적이 있습니다. 그래서 필요없는 static 변수는 지양하고 있습니다.
• 조건문 보다 다형성 지향
• 숨겨진 시간적 결합을 드러낼 것. (A - B 순서로 불리는 함수일 경우, A - B 순서로 불린다는 것을 나타낼 것)

8. 테스트

• 테스트는 항상 충분하게
• 커버리지 도구를 사용
• 사소한 테스트를 건너 뛰지 말 것
• 경계 조건을 테스트해라
• 버그 주변은 철저히 테스트 할 것
• 실패 패턴을 살펴라
• 테스트 커버리지 패턴을 살펴라

정말 인상 깊었던 내용이 많았고, 위 내용을 지키기 위해 많은 노력을 하고 있습니다.

그리고, 인상적이었던 내용은, 6. 점진적인 개선 부분이었는데,
최근에 설계가 잘못되서 구현한 기능을 남긴 채 구조를 변경해야 했던 적이 있었습니다.
이 때 설계의 중요성을 느끼고 처음부터 잘 짜야 한다고 생각했었는데, 이 부담스러운 생각을 많이 걷어 내준 부분이었던 것 같습니다. 7차선으로 늘어날 것 같다고 시골길을 처음부터 7차선으로 공사를 할 순 없다는 말이 인상적이었는데, 처음 모듈 설계시 확장성을 고려하여 설계하되, 너무 완벽하게 짜는데 부담감을 느끼지 않도록 구현을 하고 있습니다.

객체지향 서적 스터디라, 다음 책은 디자인 패턴이 될 것 같습니다.
주로 책터디 후 기존 포스팅을 수정해나가는 방향으로 진행해보려고 합니다.

읽어주셔서 감사하고, 틀린 부분이 있다면 지적해주시면 감사하겠습니다 :)