[인프런 워밍업 클럽 스터디 2기 - 백엔드 클린 코드] 1주차 발자국 회고

[인프런 워밍업 클럽 스터디 2기 - 백엔드 클린 코드] 1주차 발자국 회고

hong721816 1개월 전

학습 내용

 

추상화

추상화 : 복잡한 정보들 속 중요한 정보만 추출하여 남기고, 나머지는 버림

좋은 추상화란? 1. 해당 도메인 영역 안에서, 2. 중요한 정보만을 표현했는가?
추상화를 잘 할 수록 읽기 좋은 코드가 만들어진다..

이름짓기

추상화의 대표적인 예시!
해당 변수나 메서드가 어떤 역할인지, 어떤 일을 하는지 단번에 알아챌 수 있어야 한다.

메서드에서의 추상화 : 한 메서드에서의 주제는 반드시 하나다.
잘못된 추상화는 한 메서드가 2가지 이상의 일을 하고 있을 것.

추상화 레벨 : 하나의 세계 안에서는, 추상화 레벨이 동등해야 한다.

// As-Is
// 너무 구체적인 내용을 if 안에 담지 않았는가?
public static void main(String[] args) {

    showGameStartComments();
		initializeGame();
		showBoard();
		...
    if (gameStatus == 1) {
        System.out.println("지뢰를 모두 찾았습니다. GAME CLEAR!");
        break;
    }
}

// To-Be
// 추상화 레벨을 비슷하게 
public static void main(String[] args) {

    showGameStartComments();
		initializeGame();
		showBoard();
		...
    if (doesUserWinTheGame()) {
        System.out.println("지뢰를 모두 찾았습니다. GAME CLEAR!");
        break;
    }
}

 

인지적 경제성

최소한의 인지로 최대의 효율 얻기

Early return : 미리 return을 해버려 else의 사용을 최대한 줄이기
앞선 조건을 기억하지 않기 위함!

중첩 분기문, 중첩 반복문 : depth를 줄이기!
but, 무조건 1depth로 만드는 것이 아닌, 추상화를 통한 사고 과정의 depth를 줄이는 것이 중요!

사용할 변수는 가깝게 선언

공백라인도 의미를 가진다.

부정어구 사용 자제 : !isLeftDirection() 보다는 , isRightDirection() 으로
부정연산자는 가독성이 떨어진다.

예외처리 : 항상 NPE를 방지하는 방향으로 !! 예외가 발생할 가능성을 낮추기, Optional을 고려하기

 

객체 설계하기

새로운 객체 설계 시 1개의 관심사로 명확하게 책임이 정의되었는지 확인하기

getter / setter 사용 자제. update~ 같이 의도를 드러내는 네이밍 사용하기

 

SOLID 원칙

단일 책임 원칙 - 하나의 클래스는 하나의 변경 이유 (책임) 만을 가지도록
책임이라는 경계선이 사람마다 다르기 때문에, 책임을 볼 줄 아는 눈을 기르는 것이 중요하다

개방-폐쇄 원칙 - 확장에는 열려있고, 수정에는 닫혀있기.
시스템의 기능을 확장할 때, 최대한 기존 코드를 변경하지 않도록 설계하기

리스코프 치환 원칙 - 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 치환할 수 있어야 함
자식클래스가 부모클래스의 행동을 변경해서는 안된다.

인터페이스 분리 원칙 - 인터페이스를 잘게 쪼개서 자신이 사용하는 인터페이스에만 의존하도록

의존성 역전 원칙 - 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안됨
두 모듈 모두 추상화에 의존해야 함 -> 저수준 모듈의 변경이 고수준 모듈에게 영향을 끼치지 않도록

 

4L 회고

Liked

기능 구현에만 급급하던 지난 프로젝트와 달리, 클린코드란 개념에 대해 배울 수 있어서 좋았다.

특히, 인지적 경제성 파트에서의 Early return 과 부정어구 사용 파트에서 많은 깨달음을 얻었다.

내 코드를 돌아보며 이해가 안됐던 경험들을 개선시킬 수 있으리라 생각한다.

SOLID 같은 개념도 그동안 많이 들어와서 잘 알고 있다고 생각했던 개념들이었지만,

직접 코드를 수정해가면서 학습하니 기존 지식을 더 구체화할 수 있어서 정말 좋았다.

 

Lacked

Optional 을 그동안 너무 무의식적으로 사용했다.

그냥 NPE 예방에 효과적이라고 해서, 좋은게 좋은거지 라는 마인드로 사용했던 것 같다.

이번에도 예외처리 파트에서 Optional 에 대해 간략하게 배웠는데, 아직 제대로 사용하는 법을 모르겠다.

해당 내용에 대해 best practice 위주의 더욱 자세한 학습이 필요하다.

 

Learned

상단의 학습 내용

 

Longed for

학습 내용을 기록하고 해당 예시를 들 때, 단순 개념을 적는것보다는 코드로 보는게 더 수월할 듯 하다.

다음에는 회고록에 개념을 정리하면서, 관련 코드예시를 든다면 더 좋을 것 같다.

 

미션 회고

  1. 추상의 개념

  2. 코드 리팩토링

  3. SOLID 개념

 

https://velog.io/@hong721816/%EC%9B%8C%EB%B0%8D%EC%97%85-%ED%81%B4%EB%9F%BD-2%EA%B8%B0-Day4-Mission

접근 방법은 해당 블로그에 정리해 두었다.

댓글을 작성해보세요.

채널톡 아이콘