규턴의 개발블로그

우아한테크코스 프리코스를 진행하면서 클린코드(좋은 코드)에 대해 관심을 가지게 되었다.

또한 현재 진행중인 현대자동차 소프티어 부트캠프에서도 객체지향 + 클린코드에 대해 학습하였다.

 

호눅스님께서 따로 정답은 없다고 하셨지만, 다른 개발자들이 시행착오를 겪으면서 BestPractice는 있다고 생각한다.

그렇기에 내가 배우면서 느낀 클린코드, 객체지향적인 코드가 무엇인지 정리해보고자 한다.

 

 

 

좋은 코드

 

좋은 코드라는 말은 추상적이다.

 

흔히 사람들이 말하는 좋은코드중 하나는

  • 읽기좋은 코드
  • 유지보수하기 좋은 코드(즉, 요구사항의 변경에 유연한 코드)

여기서 읽기좋은 코드와 유지보수하기 좋은 코드는 다른 의미이다. 읽기좋은 코드는 유지보수하기 어려울 수 있으며, 유지보수하기 좋은코드는 읽기좋은코드일 수 있다. 그렇기에 이 둘의 균형을 잘 유지한 것이 좋은 코드라고 할 수 있다.

 

그러면 좋은 코드를 작성하는 방법은 어떻게 될까?

 

1. 코드는 잘게 쪼개자

 

public static void resultStatic(User user) {
        System.out.println(CommonMessage.RESULT_STATIC);
        System.out.println(CommonMessage.HYPHEN);

        resultWinningStatic(user);
        resultProfit(user);
    }

결과 출력을 하는 코드이며

 

resultWinningStatic, resultProfit같은 함수를 private 함수로 만들었다.

이처럼 각 기능들을 작게 쪼개어 함수를 만들면 가독성을 높일 수 있다.

(resultWinningStatic: 결과 출력, resultProfit: 순이익 출력)

 

즉 남이 봤을때 쉽게 이해되는 코드가 될 수 있으며 이것이 좋은 코드라고 생각한다.

 

 

2. 함수는 하나의 일만 하도록 구성

 

만약 위의 코드에서 resultWinningStatic, resultProfit를 합친다면  resultWinningStaticAndProfit 라고 함수명을 지을 수 있다.

 

하지만 resultWinningStaticAndProfit함수는 결과 출력과 수익률출력 두가지를 하고 있다. 

 

해당 함수로 작성하면, 단점은 크게 두가지가 있을 수 있다.

 

1. 테스트 코드 작성이 어려워진다. (테스트 코드에서 하나의 기능만을 테스트 할 수 없다.)

2. 디버깅이 어려워진다. 해당 함수에서 에러가 발생한다면 과연 결과출력과 수익률출력중 어디에서 에러난지를 정확히 알 수 없다.

 

 

 

3. 객체는 상태와 행동으로 구성

 

이것을 이해하기 위해서는 SOLID원칙중 SRP를 생각해서 객체를 생성하면 객체를 객체답게 구성할 수 있다.

 

 

*SRP: 객체 지향 프로그래밍에서 단일 책임 원칙이란 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다. 클래스가 제공하는 모든 기능은 이 책임과 주의 깊게 부합해야 한다. -위키백과-

 

만약 사람을 객체로 구성한다고 생각해보자.

 

사람은 머리, 팔, 다리, 몸통, 손, 손가락 등 정말 여러가지로 나눌 수 있으며 이들 모두 하나의 객체가 될 수 있다.

 

예를들어 '팔'은 2개의 손으로 이루어질 수 있으며,  '팔을 돌리다' 라는 함수를 가질 수 있다.

만약  '팔' 객체에 대한 메서드로 walk()를 만든다면 이는 SRP를 위반하는것이다 . walk는 '다리'라는 객체가 책임을 가져야 하며, 책임이 '팔'로 전가된것을 알 수 있다.

 

이와같이 객체는 상태(손), 행동( 팔을 돌리다) 와 같이 구성될 수 있으며 이를 객체의 특성에 맞게 잘 분리하면 추후 요구사항이 변경되거나 기능이 추가되어도 기존에 존재하는 객체를 사용해 객체내에 존재하는 비지니스 로직을 수정하지 않고 추가만으로 변경된 요구사항에 자연스럽게 대할 수 있다.

 

 

 

좋은코드를 왜 지향해야하는가

 

결국은 일을 빨리 끝내 능률을 높이기 위함이라고 생각한다.

 

물론 C처럼 하나의 메인 메서드에 모든 기능을 구현해도 잘 돌아갈거다.

 

하지만 실제 프로젝트는 요구사항 변경 및 추가가 정말 자주 일어난다.

 

해당 변화가 주어졌을때 기존의 코드를 최대한 수정하지 않고 추가만으로 빠르게 추가된 요구사항을 마무리 할 수 있다.

 

즉 칼퇴를 하기 위함일수도??

 

 

profile

규턴의 개발블로그

@규턴이

포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!