클린 코드란?

팀원들과 협업을 하기 전 안드로이드 코드를 인수인계받아야 하는 상황이 있었다.

내가 조져질 정도로 어려운 코드들은 아니었기 때문에 코드 이해와 활용은 금방 끝낼 수 있었다.

그리고 한 가지 생각한 것이, 만약 내가 다른 사람에게 인수인계해야 하는 상황이 온다면 별다른 수고 없이 이해할 수 있는 코드를 짜고 싶었다.

여기서부터 뻗치는 생각이 한두 개가 아니라서, 먼저 내가 생각한 문제를 한 문장으로 정의해봤다.

 

다른 안드로이드 개발자가 본다면 어렵지 않게 이해할 수 있는 코드를 짜고 싶다

 

그리고 먼저 클린 코드란 무엇일지 내 나름대로 상상해봤다. 코드 하나에 국한되지 않고 코딩 전체적으로 생각해봤다.

 

• 주석이 적어야 한다. 적다는 건 주석을 안 쓴다는 게 아니라, 반드시 있어야 하는 내용만을 주석으로 표현했기 때문에 상대적으로 주석의 수가 적다는 뜻이다.
• 변수명은 일반인이 봐도 이해될 수 있어야 하지 않을까 싶다. 일반인도 이해하는데 개발자가 이해 못할리가?
• 만들어 놓고 안 쓰는 메서드, 변수, 클래스, 인터페이스 등등이 없어야 하지 않을까? 처음 본다면 뭐 있는 파일인가 싶어서 확인할테고, 쓰레기 코드였다는 걸 알면 열받을 것 같다.

일단 이 3가지로 정리해봤다. 적지만 알찬 주석, 일반인이 봐도 이해할 수 있는 변수명, 쓰레기 코드가 없는 것이 내가 생각한 클린 코드가 성립될 수 있는 최소한의 조건이었다. 그리고 공부했다.

 

유명한 개발자들도 클린 코드에 대해서 생각했는지, 어떤 분야의 대가라느니 창시자라느니 하는 외국인들의 말을 종합해보면 아래의 문장으로 정리될 수 있었다.

 

• 클린 코드는 이해하기 쉽고 변경하기 쉬운 코드다

국내외 포스팅들을 돌아봐도 결국 그 글들에서 하고자 하는 말은 이것을 벗어나지 않았다. 글의 전개 방식이나 말하는 방식이 다를 뿐 말하려고 하는 건 저것이었다.

 

그럼 클린 코드는 어떻게 해야 만들어지는 것일까?

위에서 클린 코드의 조건 3가지를 내 나름대로 생각해봤다. 그럼 그렇게 하면 클린 코드지 않을까?

하지만 아직 추상적이다. 좀 더 정확하게 정의내리고 싶었다.

 

1. 의미 있는 변수명을 써라 : 내가 이 변수를 왜 만들었고 어떤 기능을 하며 어떻게 쓰는지 그 방법을 알 수 있는 변수명을 쓰라고 한다. 이것은 변수만 그런 게 아니라 메서드, 클래스 등 이름을 붙일 수 있는 것에 모두 적용되는 것 같다. 만약 이름에 주석이 필요하다면 그건 내 의도를 나타내지 않는 것이다.

클래스명같은 경우엔 동사를 쓰지 않는 게 좋고, 메서드명에 동사 또는 동사 구문을 쓰는 게 좋다고 한다.

 

2. 기능(function)의 첫 번째 규칙은 작아야 하는 것, 두 번째 규칙은 더 작아야 하는 것이라고 한다. 이건 if문, else문, while문 등의 블록이 1줄 길이여야 한다는 것이다. 그리고 이 라인은 함수 호출이어야 한다.

파라미터의 개수 또한 최대한 줄이는 게 좋다. 함수 파라미터가 2~3개 이상 필요하다 싶으면 이 파라미터 중 일부를 자체 클래스로 래핑해야 할 수도 있다. 누구는 try-catch-finally 구문만 있는 함수를 만들라고 하면서, 이 구문의 본문을 별도의 함수로 분리하라고 한다. 아직 공부가 깊지 않아서 이렇게 만드는 것의 장점이 무엇인지는 모르겠다.

 

3. SOLID라는 클린 코드의 주요 원칙이 있다. 이 SOLID는 로버트 마틴이란 사람이 이름 지은 객체 지향 프로그래밍과 설계의 5가지 기본 원칙이기도 하다. 이 SOLID는 이해가 잘 안 되서 나중에 포스팅을 따로 작성해서 정리하겠다.

S : Simple Responsibility Principle(SRP), 단일 책임의 원칙. 작성된 하나의 클래스는 하나의 기능만 가지며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데만 집중해야 한다.

O : Open/Closed Principle(OCP), 개방 폐쇄의 원칙. 소프트웨어의 구성요소인 컴포넌트, 클래스, 모듈, 함수는 확장에는 열려 있고 변경에는 닫혀 있어야 한다. 즉, 변경에 필요한 비용은 최대한 줄이고 확장을 위한 비용은 극대화해야 한다는 의미다. 이는 요구사항의 변경이나 추가되는 것이 생기더라도 기존 구성요소의 수정은 없어야 하며, 기존 구성요소를 쉽게 확장해서 재사용해야 한다는 것이다. 알 것 같지만 이해가 안 된다.

L : Liskov Substitution Principle(LSP), 리스코브 치환의 원칙. 서브 타입은 언제나 기반 타입으로 교체될 수 있어야 한다. 혹은 프로그램의 객체는 정확성을 깨지 않으면서, 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 뭔 소리인지 전혀 이해가 안된다.

I : Interface Segregation Principle(ISP), 인터페이스 분리 원칙. 안 쓰는 인터페이스는 구현하지 말고 가능한 최소한의 인터페이스를 쓰란 뜻이다.

D : Dependency Inversion Principle(DIP), 의존성 역전 법칙. Dependency Inversion이란 구조적 디자인에서 발생하던 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 관계를 끊는 걸 말한다. 역시 뭔 소린지 모르겠다.

 

 

결론

• 클린 코드는 이해하기 쉽고 바꾸기도 쉬운 코드를 말한다