[Code.presso] 3주차-1. SW 유지보수성 향상을 위한 Clean Code(1)

Code.presso Java 웹 개발 트랙 체험단 활동 3주차 첫번째 코스로, Clean Code에 대해 학습한 내용을 정리해보려고 한다!

평소에 클린 코드 작성법에 대해 제대로 한번 배워보고 싶었는데 이렇게 좋은 기회가 생겨서 강의를 듣기 전부터 기대가 컸다😊

강의 제목은 "SW 유지보수성 향상을 위한 Clean Code" 으로, 자세한 정보는 👇🏻아래👇🏻 링크를 통해 확인할 수 있다.

📌 SW 유지보수성 향상을 위한 Clean Code - 강의 정보

✋🏻 포스팅 내 사용된 사진 파일들의 저작권은 모두 코드프레소에 있으며, 강의자료 공유 및 업로드는 불가능합니다.

---

🏷 Clean Code 소개

✔️ Code 품질에 대한 서로 다른 의견

코드의 품질은 매우 주관적인 문제이다.
개개인마다 좋은 코드에 대한 다른 정의와 수준을 가지고 있기 때문이다.

이와 같이, 변수 이름을 짓거나 주석을 다는 행동에도 개발자마다 다른 기준을 가지고 있을 수 있다!

❗️Clean Code 를 위한 정확한 공식은 없으며, 앞으로 학습할 내용 또한 정답이 아니다❗️

논란의 여지가 있는 내용도 있을 수 있겠지만, 이번 기회를 통해 Clean Code에 대해 깊이있게 생각해 볼 수 있다면 충분히 의미있는 경험이 될 것이라 생각하며 정리를 시작해보려고 한다😃

✔️ Clean Code란 무엇일까?

앞서 말했듯 Clean Code의 엄격한 정의는 존재하지 않는다.
그러나 대가들의 아이디어에서 힌트를 얻을 수 있는데, 공통적인 의견을 조합해보면 다음과 같다!

1. 사람이 읽고 이해하기 쉽다.

2. 단순한 한가지 역할을 하고, 명확한 이름(표현)을 가지고 있다.

3. 중복이 없다.

4. 테스트 케이스가 있다.

➡️ 정리하자면 Clean Code란, 사람이 읽고 이해하기 쉽고, 명확한 한가지 역할을 하며, 이 역할을 의미있게 표현하고, 중복이 없으며 테스트 케이스가 존재하는 코드이다.

그렇다면 Clean Code가 도대체 왜 중요할까🧐❓

소프트웨어는 사실상 한번 개발되면, 오랜 기간동안 유지보수된다.
새로운 코드를 작성하고 개발하는 시간보다, 기존 코드에 추가 작업하는 시간이 압도적으로 많다.

즉, 대부분의 시간을 기존 코드를 읽고 이해하는데 사용한다는 것이다!

따라서 코드의 품질이 낮아지면 여러 문제가 당연히 뒤따를 수밖에 없고, 이는 개인과 조직 모두에게 커다란 비효율을 발생시킨다.

이제부터, "Clean Naming ➡️ Clean Method ➡️ Clean Comment ➡️ Clean Formatting ➡️ Clean Control Structure ➡️ Code Refactoring" 과정을 순서대로 학습하며 Clean Code에 더욱 더 가까이 다가가보도록 하겠다!

📌 중요하지만, Clean Code의 범위에 속하지 않는 것

• 자료구조/알고리즘
• 소프트웨어의 성능 개선
• 신뢰성, 안정성을 위한 개발 기법
• 소프트웨어 아키텍쳐 설계 기법
• 언어 별 Programming Best Practice

---

🏷 Clean Naming

✔️ Clean Naming의 원칙

개발의 약 75%의 시간을 코드를 읽고 이해하는데 사용하는 만큼, 변수/상수/함수/클래스 등의 이름을 짓는 과정은 매우 중요하다.

공통적으로 "명확히 설명하는 이름" 을 강조하고 있는데, 어떤 조건을 가지는지 지금부터 알아보자!

💡 Clean Naming의 원칙

1. Function, Class 역할을 명확하게 표현하자.

• 명확히 한가지 역할을 해야한다.
• 역할이 많으면 이름도 명확하지 않게 된다.
• 명확한 이름을 짓기 어렵다면, 너무 많은 역할을 하고 있는 게 아닌지 고려해보자.

2. 불필요한 정보와 반복을 제거하자.

• 이름은 이해가능한 최소한의 정보(너무 짧지고, 길지도 않은)를 담고 있어야 한다.
• 불필요한 정보 ➡️ UserData, processFunc()

3. 줄임말을 사용하지 말자.

• 줄임말은 가독성을 심각하게 저하시킨다.
• 누구나 이해할 수 있는 줄임말 이라는 것은 존재하지 않는다. 내가 이해할 수 있다고 해서 다른 사람들도 이해할 수 있을 거라는 생각은 X.

4. 규칙과 일관성은 매우 중요한 요소이다.

• 언어별, 조직별 Naming Convention을 일관성 있게 지켜야한다.
• 예를 들어, 팀에서 정보를 조회할 때 get 동사를 사용하기로 했다면, getUser() 와 같이 사전에 정의해둔 Naming Convention을 고려하여 작명하자.
• 코드 리뷰를 통해 가이드를 잘 지키고 있는 지 확인하는 것도 좋은 방법이다.

5. 동료와 상의하자.

• 좋은 이름이 떠오르지 않을 때, 내가 잘 지었는지 이름에 대해 확신이 없을 땐 동료와 상의하자.

✔️ Variable을 위한 Clean Naming

변수의 경우를 살펴보자.

Number 혹은 String 변수, Object 변수는 어떤 데이터가 담겨있는지 명확히 설명하는 이름이어야 하고,
Boolean 변수는 true/false 로 답변할 수 있는 질문 형태의 이름이어야 한다.

이와 같이 네이밍을 할 수 있고,

조금 더 자세하게 표현해도 좋다.

단일 문자로 이루어진 이름, 줄임말, 불필요한 정보나 명확하지 않는 이름, 그리고 숫자 접미사 등은 피해야 하는 Bad Smell Pattern이다🙅🏻‍♀️

✔️ Method를 위한 Clean Naming

메소드의 경우를 살펴보자.

메소드의 이름 또한 의도와 기능을 명확하게 표현해야하는데, 동작(동사) + 대상(명사) 의 형태로 표현한다.
그리고 한 가지 일만 수행해야 한다.

특정 기능을 수행하는 메소드는, 메소드의 의도와 수행하는 동작을 명확히 설명하는 이름이어야 하고,
Boolean 을 체크하는 메소드는, 변수와 동일하게 true/false 로 답변할 수 있는 질문 형태의 이름이어야 한다.

이와 같이 네이밍을 할 수 있고,

조금 더 자세하게 표현해도 좋다.

1. 메소드가 이름보다 더 많은 기능을 수행
2. 이름에 and or if/else 가 포함
3. 동일한 동작에 대해 동사 단어가 일관성있게 사용되지 않음
4. 동사의 의미가 모호함
이러한 형식은 피해야 하는 Bad Smell Pattern이다🙅🏻‍♀️

✔️ Class를 위한 Clean Naming

클래스의 경우를 살펴보자.

클래스의 네이밍이 중요한 이유는 클래스에 의해 생성되는 객체를 의미있게 설명해야 하기 때문이다.

클래스의 이름을 지을 때에는, 구체적이고 명확한, Convention을 준수하는 일관성있는 이름을 사용해야 하고 보편 언어를 활용해야 한다.

무엇을 나타내는 지 이해하기 힘든 이름보다는 깔끔하고 구체적이게 이름을 지어야 한다.

또한 조직 내부에서 특정 개념에 대한 용어를 사전에 정의하고 일관성 있게 사용해야 한다.
Factory, Creator, Builder 등을 Factory 하나로 통일하니 훨씬 보기에도, 이해하기에도 쉬워졌다.

📌 보편 언어
실제 개발을 진행하다 보면, 도메인 전문가와 엔지니어들이 사용하는 언어가 다를 때가 많은데,
도메인 전문가들이 사용하는 언어에 기준을 두고 개발을 진행해야 한다!

✔️ Coding Rule

Coding Rule 이란 소프트웨어 개발 가이드라인 및 규칙의 모음으로, 소프트웨어의 유지보수 및 신뢰성 등 향상을 위해 준수가 강력히 권장된다.

각 언어별로 다양한 기업과 단체에서 발표했는데 필요시 해당 사이트를 참고하면 좋을 것 같다.

---

🏷 Clean Method

메소드와 함수는 소프트웨어서서 가장 기본이 되는 모듈이다.

Clean Method 의 원칙으로는 크게 4가지가 있다.

1. 가능한 한 충분히 작아야 한다.

2. 한가지를 해야하고, 그 한가지를 잘 해야한다.

3. 테스트 가능해야 한다.

4. 중복이 없어야 한다.

하나씩 알아보자😃

✔️ Parameter 와 Clean Method

Parameter의 개수에 따라 Clean Method 를 정의내릴 수 있다.

Method를 호출할 때에는, 호출하는 사람의 인지적 부하를 최소로 만들어 주어야 하고 내부 코드나 API 문서를 보지 않고도 이해할 수 있어야 한다.

보통 3개 이상일 때부터 개선 가능성을 검토해보아야 한다.

첫번째로 메소드를 분할하는 방법이 있다.
메소드가 너무 많은 역할을 하고 있을 가능성이 있기 때문에, 명확히 한가지 역할을 하는 2개 이상의 메소드로 분할하는 것이다.

두번째는 Parameter Object를 사용하는 방법이다.
Parameter Data를 저장하는 Object를 활용하자.

✔️ Clean Method의 크기

작고 역할이 명확한 메소드는 읽고 이해하기 용이하고, 기존 코드를 수정할 때에도 편하며, 단위 테스트에 용이하고 재사용성이 높다는 장점을 가진다.

그러나 적절한 Method의 크기는 정의내리는 사람마다 기준이 다르다.

중요한 것은 라인 수 보다 자신의 코드에 대한 끊임 없는 질문과 개선이다❗️

• 이 함수를 동료가 쉽게 이해할 수 있을까?
• 충분히 작은가? 더 작게 분할할 수 있을까?
• 단위 테스트 코드에 의해 충분히 테스트되고 있을까?
• 너무 많은 역할을 하고 있진 않을까?

✔️ 한 가지의 명확한 역할

한 가지의 명확한 일을 하는 메소드는 아래와 같은 특징을 가진다.

1. 명확한 Naming이 가능하고, 이름만으로 기능을 이해할 수 있다.
2. 복잡도가 낮아질 가능성이 높다(Cyclomatic Complexity)
3. 메소드의 내부 코드를 이해하고 수정하기 용이하다.
4. 단위 테스트하기 용이하다.

여기서 한 가지의 일 이란, 동일한 추상화의 수준을 가지는 것을 의미한다.

사진과 같이 하나의 메소드는 동일한 추상화의 수준만을 가져야 한다!

한 가지를 잘하는 메소드를 만드는 것은 생각보다 쉽지가 않다😅
이를 위해서는 코드리뷰를 통해 메소드를 지속적으로 리뷰하고 개선하는 조직 내 컨센서스를 만들어 나가는 것과,
끊임없는 질문과 개선이 아주 중요한 역할으로 작용한다.

✔️ 중복 코드

중복 코드란 일정 라인 수 이상이 다수 중복되어 존재하는 코드로 다양한 문제점을 발생시킬 수 있다.

중복 코드의 종류🧐

1. 메소드 전체 중복 코드

• 다수의 메소드 구현부가 100% 일치

2. 연속된 일련의 코드 중복

• 전체는 아니지만 일부 연속된 코드가 다수 중
  복

3. 일부만 다른 코드 중복

• 코드가 중복되지만 중간 1~2라인 정도만 다름
• 리팩토링하기 가장 까다로운 유형

중복 코드의 문제점😰
이와 같은 중복 코드들은 불필요한 코드 베이스를 크게 만들고, 코드를 수정해야 할 때 다수의 코드를 모두 수정해야 한다는 불편함이 있다.
또한 중복 코드에 잠재적 결함이 있을 시 결함도 같이 중복될 수 있다.

중복 코드의 발견👀
코드 리뷰를 통해 중복 코드를 발견하기도 하지만, 수동으로 전체 소프트웨어 시스템의 중복을 다 발견하기는 쉽지 않다.
➡️ CPD와 같은 정적 분석 도구를 활용한다!

중복 코드의 해결💡

• 다양한 리팩토링 전략 및 design pattern 사용한다.
• Extract Method
  • 중복된 코드를 새로운 메소드로 추출한다.
• Extract Superclass
  • 서로 다른 클래스에 코드가 중복될 경우, 중복 코드 부모 클래스에 위치시키고 기존 클래스들은 해당 클래스를 상속한다.
• Template Method Pattern
  • 알고리즘의 일부가 중복되는 경우에 사용한다.

✔️ Method 측정 지표

메소드를 측정하는 지표에는 여러가지가 있다.

1. Lines of Code
말 그대로 메소드의 길이를 측정하는 것이다.
조직에서 Bad Smell의 기준을 정하고 이를 넘는 메소드를 검출한다.

2. Cyclomatic Complexity
메소드 내부의 복잡도를 측정하는 지표로, 메소드 내부의 조건문 중첩이 복잡할수록 높아진다.
CC가 높을수록, 테스트와 수정이 어려워진다.

---

이렇게 Clean Code의 개념, Clean Naming, Clean Method 에 대해 다뤄보았다.

유지보수성 높은 소프트웨어 개발에 대해 깊게 생각해볼 수 있는 기회가 된 것 같아서 뜻깊었다!

코드프레소 홈페이지(https://www.codepresso.kr/)에는 오늘 포스팅한 Clean Code 관련 강의뿐만 아니라 다양한 강의들이 개설되어 있으니 모두 한번 씩 살펴보고 수강해보면 좋을 것 같다😃