- Young 영역 : 새롭게 생성한 객체의 대부분이 여기에 위치한다. 대부분의 객체가 금방 접근 불가능 상태가 되기 때문에 매우 많은 객체가 Young 영역에 생성되었다가 사라진다.

GC 종류
        - Minor GC : Young 영역에서 발생하는 GC
        - Major(Full) GC : Old 영역에서 발생하는 GC

참조 링크 - Java Garbage Collection

형식 맞추기

• 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다.
• 팀이 합의하여 규칙을 정하고 모두가 그 규칙을 따라야 한다.

형식을 맞추는 목적

• 코드 형식은 중요하다.
• 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다.
• 구현한 코드들이 변경되더라도 개발자의 스타일과 규율은 잘 사라지지 않는다.

적절한 행 길이를 유지하라

• 자바에서 파일 크기는 클래스 크기와 밀접하다.
• 일반적으로 작은 파일이 큰 파일보다 이해하기 쉽다.

신문 기사처럼 작성하라

• 독자는 위에서 아래로 읽는다.
• 메소드 전체 내용을 요약하는 이름을 작성한다.
• 세세한 내용은 또 하나의 메소드로 분리한다.

개념은 빈 행으로 분리하라

• 빈 행은 새로운 개념을 시작한다는 시각적 단서다.
• 다른 개념 사이에 개행이 빠지면 가독성이 현저히 떨어진다.

세로 밀집도

• 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다.

수직 거리

• 같은 파일에 속할 정도로 밀접한 두 개념은 세로 거리로 연관성을 표현한다.
  • 여기서 뜻하는 연관성이란 한 개념을 이해하는데 다른 개념이 중요한 정도다.
  • 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는 사람이 함수 연관관계와 동작 방식을 이해하기 위해 여기저기 찾느라 시간과 노력을 소모한다.

[수직분리]

변수 선언

• 처음으로 사용하기 직전에 선언하며 수직으로 가까운 곳에 위치해야 한다.
• 비공개 함수는 처음으로 호출한 직후에 정의해야 쉽게 눈에 띄어야 한다.

인스턴스 변수

• 클래스 맨 처음에 선언한다.

종속함수

• 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.
• 또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치해야 자연스럽게 읽힌다.

개념적 유사성

• 개념적인 친화도가 높을수록 코드를 가까이 배치한다.
• 종속적인 관계가 없더라도 기능적으로 유사하다.

public boolean isAdmin() {  
  return StringUtils.equals(RoleCodes.ADMIN, role.getName());  
}

public boolean isManager() {  
  return StringUtils.equals(RoleCodes.MANAGER, role.getName());  
}

public boolean isUser() {  
  return StringUtils.equals(RoleCodes.USER, role.getName());  
}

세로 순서

• 호출되는 순서대로 함수를 배치하면 소스 코드 모듈이 고차원에서 저차원으로 자연스럽게 내려간다.
• 가장 중요한 개념을 표현하고나서 세세한 사항을 표현하면 함수 몇 개만 읽어도 개념을 파악하기 쉬워져서 세세한 사항까지 파고들 필요가 없다.

가로 형식 맞추기

• 행 길이는 어느 정도가 적당할까?
  • 여러 논쟁이 있지만 120자 정도로 제한하는 것을 권고한다고 한다.

가로 공백과 밀집도

• 가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다.
  • ex) 할당 연산자 명확, 메소드 파라미터 구분, 연산자 우선순위 강조

가로 정렬

• 정렬을 통해 강조하려고한 진짜 의도가 가려질 수 있다.
• 변수 유형은 무시하고 변수 이름부터 읽게 되버린다?
  • 정렬이 필요할 정도로 목록이 길다면 문제는 목록 길이지 정렬 부족이 아니다.
  • 만약 선언부가 길어진다면 클래스를 쪼개야 한다는 의미다.

들여쓰기

• 들여쓰기가 없다면 인간이 코드를 읽기란 거의 불가능일 것이다.
• 들여쓰기한 파일은 구조가 한눈에 들어온다.
  • ex) 변수, 메소드, 분기문 등..

• 들여쓰기 무시하기

  • 간혹 간단하고 짧은 메소드에서 규칙을 무시하고픈 유혹이 생긴다.

  public String render() { return ""; }
  
  public String render() {   
    return "";   
  }

팀 규칙

• 각자 선호하는 규칙이 있지만 팀에 속한다면 자신이 선호해야할 규칙은 바로 팀 규칙이다.
  • 그래야 스타일이 일관적이고 매끄럽다.
  • 팀 규칙을 정하여 IDE 코드 형식기를 설정하여 모두가 그 규칙을 따라야 한다.
• 좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이뤄진다.

마치며

팀에서 포괄적인 규칙을 정하여 IDE에 적용하여 사용하다가 의아스러운 부분이 있었다.
상세한 부분에 대해서도 팀 내 규칙을 정하여 한 사람이 작성한듯한 가독성 좋은 코드를 작성해야 한다.

적용한 룰에 예외적으로 느껴진 항목

• 테스트케이스 MockMvc 포맷
• 포맷으로 지정한 가로 길이를 조금 초과하는 경우
• 조건문 내 1줄 정지성 키워드(break, return, throw ..) 브레이스 여부

참고문헌 - CleanCode 애자일 소프트웨어 장인 정신