클린코드를 위하여

먼저 글을 시작하기전에 내 자신에게 큰 박수를 보내고 싶다.

 

정말 부끄러운 얘기지만 여태까지 대학생 시절을 포함해서 10년 넘게 개발하는 삶을 살고 있지만,

정작 처음부터 끝까지 관련 전공 서적을 완독한적은 없었던 것 같다.

 

올해는 적어도 두, 세 달에 한권 씩은 전공 서적을 완독해보자는 목표를 세웠는데 드디어 처음으로 완독한 책이 생겼다.

 

바로 "클린코드"이다

겨우 한번 읽은 거 가지고 그러냐 하실 수도 있지만은 ㅎㅎ 저에게는 큰 의미이니 너그럽게 이해해주시길 바란다.

 

책을 읽고 실무에서 언제든 클린코드를 적용 할 수 있게 나름대로 정리를 좀 해보고자 한다.

 

 1. 클린코드의 철학

 

훌륭한 개발자는 나쁜 코드를 지양한다. 

나쁜 코드는 팀의 생산성을 저하시키고 , 나쁜코드는 기술 부채를 만들어 수정이 어렵게 만든다.

 

그렇다면 나쁜 코드와 대비되는 좋은코드. 즉 클린 코드는 무엇일까? 

책에서는 프로그램의 성능을 좋게 만들고, 가독성이 좋아 코드의 의미가 명확하며, 중복을 제거하여 생산성을 향상 시킨 코드를 클린 코드라 칭한다.

 

여기서 클린코드를 이루고자 설계에 너무 쉼취해서, 구현시 모든 사람을 힘들게하는 설계는 해서는 안된다.

예를 들어 여러가지 규칙을 너무 많이 만들어서 클래스와 메서드를 무수히 많이 만들게 되면 이는 오히려 생산성을 저하 시키게 만든다. 이러한 부분은 실용적인 관점에서 타협할 필요도 있다.

 

잘기억하자. 클린코드는 생산성을 높이기 위해 실천하는 것이다.

 

2. 코딩은 혼자하는 것이 아니다.

 

실무에서 대부분 코딩은 혼자만을 위한 것이 아니다. 어떤 프로젝트든 팀 단위로 여러명이 붙어서 프로젝트를 진행한다.

네이밍, 함수, 주석, 포맷팅 등은 공동으로 창작하는 코드에서 아주 아주 중요한 요소이다.

 

그렇기에 팀의 코딩 스타일, 즉 팀 코딩 컨벤션을 지키는 것은 매우 중요하다.

뭔가 팀의 스타일이 이상하다고 하더라도 혼자서 룰을 바꿔서 적용해서는 안된다. 어떠한 상황이든 팀과 맞춰야한다.

 

3. 객체지향을 위하여 노력하기

 

자바든 C#이든 객체지향 언어로 프로그래밍을 하면 객체지향을 코드내에 잘 녹여야한다.

숨길건 숨기는 캡슐화라던지,

다양한 디자인 패턴을 잘 활용한다던지 하는 객체지향 프로그래밍을 하는 노력을 해야한다.

 

이러한 노력은 결합도를 줄이고 응집도를 높이는 프로그램을 만들 수 있게한다.

결합도와 응집도에 대한 내용은 아래 링크를 참고하자.

https://devkingdom.tistory.com/300?category=838914 

결합도와 응집도 이야기

 

그리고 정말 어려운 얘기지만 설계 단계에서 부터 SOLID 원칙을 적용하기 위해 노력해야 한다. SOLID 원칙을 코드에 적용하는 방법은 많은 경험밖에 없다. 잘짠 코드를 읽고, 스스로 적용하기 위해 노력하자.

https://devkingdom.tistory.com/296?category=838914 

객체지향 SOLID 원칙 - SRP, OCP, LSP, ISP, DIP

 

 

4. 오류(예외)처리를 어떻게 하면 좋을까?

 

CheckedException과 UncheckedException에 대한 개념을 모르시는 분들은 아래 링크를 통해 공부를 하고 오면 더 좋을 듯하다.

https://devkingdom.tistory.com/283

[Java] Java Exception 처리하기

오류(예외) 처리는 UncheckedException으로 처리해주는 게 좋다.

 

컴파일 단계에서의 처리보다는 런타임 단계에서의 예외 처리를 하는 것이 서비스가 유연하게 운용될 수 있기 때문이다.

여기서 많이들 하시는 오해가 UnchekedException으로 처리하면 프로그램이 안전하지 않다고 생각하시는데, 절대 그렇지 않다. 실제로 C# 이나 파이썬 같은 언어는 CheckedException을 제공하지도 않는다. UncheckedException 만으로도 충분히 안전한 운영이 가능하다.

 

그리고 실무에서는 예외를 처리할 때 , null을 이용하여 처리하는 것은 지양하자.

 

대신 예외 대신 기본값(null이 아닌 기본값, 도메인에 맞는 기본값) 을 리턴해주는 getOrElse 패턴을 사용해주고

기본값이 없다면 null 대신 차라리 예외를 던지는 getOrElseThrow 패턴을 통해 처리하자.

 

5. 테스트는 매우 중요한 과정이다.

프로그래밍에서 테스트 만큼 중요한게 없다. 

나같이 게으른 사람에게 테스트는 정말 힘든 과정이다. 

 

하지만 절대로 본인을 믿지 마라. 적어도 코드에서는 믿어선 안된다. 모든 케이스를 테스트하기 위해 노력해야한다.

Google에서 제안하는 테스트 비중은 Unit Test 70%, Integration Test 30%, E2E Test 10% 의 비율로 테스트를 하기를 권장하니 참고하자.

 

그리고 단위 테스트를 하기 위해 책에서 F.I.R.S.T 원칙을 제안하는데 테스트할 때 항상 이 원칙을 생각하며 진행하자.

 

F.I.R.S.T 원칙

 

Fast (빠르게)

테스트는 자주 돌려야 하기에 빨리 돌아야 한다.

 

Independent ( 독립적으로)

테스트가 서로에 의존하면 실패 원인을 찾기 힘들기에 독립적으로 작성한다.

 

Repeatable( 반복가능하게)

테스트는 실제 환경, 테스트 환경을 가리지 않고 어떤 환경에서도 반복가능하게 작성되어야 한다.

 

Self-Validating (자가 검증 가능하게)

모든 테스트는 bool 로 명확하게 결과를 내야한다.

 

Timely (시간에 맞게)

테스트 코드를 구현하고 , 그 다음 실제코드를 구현하자. 테스트 하려는 실제코드를 구현하기 직전에 테스트 코드를 구현해야한다.

 

6. 점진적으로 개선하자

코드는 한순간에 다 바꿀수가 없다. 특히 오래되고 낡은 코드일수록 더욱더 그렇다.

하지만 그렇다고 절대 내버려둬서는 안된다. 점진적으로 개선하자.

 

아래 순서로 코드를 점진적으로 고쳐 나가자.

 

1) 코드가 나빠지고 있음을 인지한다.

2) 먼저 테스트 코드를 완벽하게 작성하자( 실제 코드의 변경전과 변경 후에는 동일한 테스트코드가 돌아야한다)

3) 점진적으로 개선하자 ( 책임에 따라 클래스를 나누고 코드를 옮기자. 한번에 너무 많은 코드를 변화시키면 테스트가 깨져버리니 작은 단위로 자잘 자잘하게 점진적으로 변화를 주자)

 

 

이로써 클린코드 책에 대한 정리도 끝난다.

 

이 책은 앞으로도 왠지 내 개발자 삶과 꾸준히 함께 할 것 같은 느낌이든다. 

 

아무튼 다읽어서 너무 행복하다. 

 

긴 글 읽어주시느라 감사합니다.

 

끝.

 

ref.

-로버트 C.마틴, 『클린코드』, 도서출판인사이트(2021)

-zero-base, 한달한권