Break Out of Your Comfort Zone

클린코드와 코드 리팩토링

 
  • Jan 08, 2020

클린코드와 코드 리팩토링

Clean Code & Code Refactoring

# Clean Code란?


"깨끗한 코드는 한 가지를 제대로 한다." - 비야네 스트롭스트룹
"깨끗한 코드는 절대로 설계자의 의도를 숨기지 않는다. 단순하고 직접적이다." - 그래디 부치
"코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행하는 코드" - 워드 커닝엄
"중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기, 내게는 이 세가지가 깨끗한 코드를 만드는 비결이다." - 론 제프리


"모든 팀원이 이해하기 쉽도록 작성한 코드"


반대로 나쁜 코드란, “대충 짰는데 돌아가는 코드”를 말한다. 코드를 짤 때 “대충 짜고 나중에 고치지 뭐.”라고 생각하고는 한다. But, 나중은 절대 오지 않는다.

"Later is Never"
- Leblanc’s Law -


# 클린코드가 왜 필요한가?

10 : 1
  코드를 읽는 시간 : 코드를 짜는 시간

프로그래밍을 할 때 우리가 코드를 읽는 시간 : 코드를 짜는 시간의 비율이 10 : 1이라고 한다. 이직이 잦은 개발자들은 기존 사람이 남기고 간 코드를 읽고 수정하는 일이 잦다. 즉, 기존 코드를 읽어야 새 코드를 짜기 때문에 읽기 쉽게 만들면 새 코드를 짜기도 쉽다.


# 클린코드의 주요 원칙

  1. Follow Standart Convention

    Coding 표준, 아키텍처 표준 및 설계 가이드를 준수하라.

  2. Keep it simple, Stupid

    단순한 것이 효율적이다. 복잡함을 최소화해라.

  3. Boy Scout Rule

    참조되거나 수정되는 코드는 원래보다 clean해야 한다.

  4. Root Cause Analysis

    항상 근본적인 원인을 찾아라. 그렇지 않으면 반복될 것이다.

  5. Do not multiple language in one source file

    하나의 파일은 하나의 언어로 작성하라.


# 디자인 원칙(Class Design)

Simple Responsibility Principle(SRP)

​ 하나의 클래스는 하나의 책임만 가져야 한다.

Open/Close Principle(OCP)

​ 클래스는 확장에 대해 열려 있어야 하고, 변경에 대해서는 닫혀 있어야 한다.

의존성과 관련된 문제이다. 즉, 함수를 수정했을 때 의존성으로 인해 다른 변경사항이 생겨서는 안된다.

Liskov Substitution Principle(LSP)

​ 파생클래스의 메소드는 기반 클래스의 메서드를 대체하여 사용될 수 있어야 한다.

​ 즉, 서브 클래스는 상위 클래스에 기반을 두고 더 구체화하는 방식을 만들어야 한다.

Interface Segregation(ISP)

​ 클라이언트가 사용하지 않는 메소드에 의존하지 않아야 한다. 즉, 의존성을 줄여야 한다.

DDependency Inversion Principle(DIP)

​ 추상클래스에 구체적인 사항(하위 클래스의 내용)이 들어가서는 안된다.

​ ex) Super - 동물, Sub - 강아지, 고양이, … 를 포함하는 동물 클래스를 추상클래스로 정의할 때

​   동물 클래스에는 강아지 클래스에만 해당하는 내용이 들어가서는 안된다.

그 외 클린 코드를 위한 고려사항들.

  1. 의미 있는 변수명

    • 의도가 분명한 네이밍. 발음하기 쉬운 이름을 선택한다.

  2. 명확하고 간결한 주석

    • 함수의 주요 세부사항은 주석으로 남기기(함수 선언으로는 알 수 없는 내용들)
    • 보기 좋게 배치하고 꾸미기(여러 개의 그룹-문단으로 나누기) + 열 정렬

  3. 읽기쉽게 흐름제어 만들기

    • 삼항 연산자는 꼭 필요하거나 간단한 경우에만 이용하기.

    • do-while 문은 피해라.

    • 부정이 아닌 긍정문 사용하기.
    if(a != 0){
	//부정문 보다는
}
if(a == 0){
	//긍정문 사용하기
}

  4. 함수는 가급적 작게. 하나의 작업만 수행하도록.

    image


"컴퓨터가 이해하는 코드는 누구나 짤 수 있다. 사람이 이해할 수 있는 코드를 짜야 한다."



# 레거시 코드를 다루는 프렉티스 - 코드리뷰

# 코드리뷰란?

"코드를 실행하지 않고 사람이 검토하는 과정을 통해
코드상에 숨어있는 잠재적인 결함(Defect)를 찾아내고 이를 개선하는 일련의 과정"

"소프트웨어 품질을 보장하기 위해 테스팅, 일일 빌드, 프레임워크 사용,
개발패턴, 코드리뷰와 같은 활동 중 가장 효과적인 활동"



# 코드리뷰는 왜 중요한가?

코드 리뷰의 장점으로는 “버그 조기 발견”, “개발 표준 준수”, “중복코드 방지 및 모듈 재사용성 증대” 가 있다.


또한, 코드리뷰는 단순히 버그를 사전에 발견하거나 문제점을 찾는 목적을 넘어서
전체적인 조직의 역량을 강화하는 중요한 역할이다.

​

그만큼 소프트웨어 유지보수, 문제점 발견 등 모든 상황에서 코드리뷰는 굉장히 중요하다. 또한 아래 사진과 같이 리뷰를 같이 했기 때문에 책임을 한 사람에게만 묻는 일을 방지할 수 있다.

사진출처: https://blog.logi-spot.com/코드리뷰의 진짜 목적은 따로 있다.


Search