항해99_TIL220607 (클린코드)

오늘 과제마무리를 했다.

 

@Builder
@NoArgsConstructor
@AllArgsConstructor

@Builder 사용 시 @NoArgsConstructor 어노테이션을 함께 사용하면 에러가난다.

이유는 모든 멤버변수를 받는 생성자가 없기 때문인데, @AllArgsConstructor를 추가해주거나 전체 멤버변수를 갖는 생성자를 만들면된다.

(@Builder 사용 시, 생성한 생성자가 없다면 @AllArgsConstructor가 암묵적으로 적용된다고 한다.)

반대로 생성한 생성자가 있으면 @AllArgsConstructor가 필요한게 아닐까 생각된다.

 

 

클린코드를 정리해봤다.

• 클린코드를 해야하는 이유 : 더욱 훌륭한 커뮤니케이션을 위함입니다.
• 클린코드의 범위를 가독성을 추구하여 직관적으로 이해할 가능성이 높은 코드로 두고, 가독성 영역을 중심으로 이야기해 보겠습니다.
• 클린코드는 코드를 처음 보는 사람도 동작을 직관적으로 파악할 수 있도록 하는 것을 목표로 합니다.
• 가독성 확보는 코드 해석에 드는 비용을 줄이는 작업입니다. 심지어 우리는 코드를 몇 번이나 반복해서 읽습니다.
• 클린코드에서는 코드를 짜는 것과 읽는 것의 비중이 1:10 정도라고 이야기합니다.
• 조금 과장하자면 가독성 확보는 전체 코딩 업무의 90%에 대한 효율화 작업이라고 할 수 있겠습니다.
• 가독 성이란 코드가 잘 읽히고, 해당 코드의 동작을 직관적으로 예측할 수 있는지를 뜻합니다.
  • 표현적 가독성 : 눈에 잘 들어오는 코드, 읽기 편한 코드
  • 기능적 가독성 : 변수, 함수, 클래스 등이 어떤 역할을 갖고, 어떤 동작을 하며, 서로 어떤 관계를 맺는지 직관적으로 파악할 수 있는 코드

 

표현적 가독성

 

• IDE 포맷터 세팅 및 형식 맞추기

IDE에서 읽기 편한 환경을 구성하기 위한 형식 맞추기 작업입니다.

대부분의 IDE는 포맷터를 설정할 수 있도록 지원하는데, 이 설정을 팀원들 간에 통일하면 서로 다른 포맷팅으로 인한 의미 없는 코드 변경을 줄일 수 있습니다.

방법은 다음과 같습니다.

✔ 최대 가로 길이를 화면 절반쯤에 맞춥니다.

✔ 파일당 행은 500줄 미만으로 끊어줍니다.

✔ 하나의 파일은 두괄식으로 작성합니다.

✔ 변수는 사용하는 곳과 가까운 곳에 선언합니다. 즉, 함수가 시작되는 부분에 몰아서 선언하지 않습니다.

 

 

• 함수

함수를 만드는 첫 번째 원칙, 작게. 두 번째 원칙은 더 작게!

클린코드에서는 20줄 미만의 함수를 권장합니다.

때로는 이 기준에 집착해서 필요 이상으로 함수를 쪼개기도 하는데요, 이는 다소 잘못된 적용입니다.

20줄이라는 기준은 함수를 물리적으로 제한하여 자연스럽게 책임을 제한하려는 의도입니다.

‘함수는 한 가지 책임을 갖는다’라는 말을 위한 것입니다.

이를 단일 책임 원칙(SRP, Single Responsibility Principle)이라 부릅니다.

 

 

• 주석

잘못된 코드는 빠르게 수정되지만, 잘못된 주석은 잘 수정되지 않습니다.

그래서 클린코드에서는 주석은 필요악이라고 이야기합니다.

관리가 잘 안되는 만큼 정말 필요한 부분에만 최소한으로 사용하라는 의미입니다.

따라서 TODO / 외적인 맥락 / 제한사항과 같이 ****코드로 설명할 수 없는 부문만 주석으로 설명하고, 가능하면 코드 자체가 스스로를 설명할 수 있게끔(Self-Descriptive) 작성합니다.

주석으로 설명하여 만든 코드도 잘 만들었다고 할 수 있지만 제일 잘 만든 코드는 주석이 없는 코드라고 합니다.

 

기능적 가독성

 

• 함수의 내려가기 규칙

중요한 것은 이야기처럼 읽혀야 한다는 것이다.

책에서 위에서 아래로 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아지는 것을 내려가기 규칙이라고 부른다.

TO 문단을 읽듯이 프로그램이 읽혀야 한다고 하는데 여기서 TO는 영어로 ~하려면의 의미를 가진다.

다시 말해 TO 문단은 현재 추상화 수준을 설명하는데 아래 예시를 보면서 이해를 해보자.

TO 무엇을 하려면, A를 하고, B를 하고, C를 해야 한다.
TO A를 하려면, 이렇게 해야 한다.
TO B를 하려면, 이렇게 해야 한다....

여기서 핵심은 위 예시처럼 위에서 아래로 TO 문단을 읽어내려 가듯이 코드를 구현하면, 추상화 수준을 일관성 있게 유지할 수 있다는 것이다.

 

• 의미 있는 이름

좋은 이름을 짓기 위해서는 모든 것에 이름을 붙인다고 생각하고, 짧고 불명확한 이름보다는 길고 명확한 이름이 낫다는 걸 명심합니다.

항상 이름 있는 상수(Named Constant)를 사용합니다.

-Info, -Data, tmp- 와 같은 무의미한 접미사, 접두사는 제거합니다.

대명사, 축약, 생략은 알아보기 힘듭니다.

disp보다는 display가 더 명확하고, Decode 하기 쉽습니다.

서로 무관한 함수에서 같은 이름을 사용해서는 안 됩니다(구분 가능성).

마찬가지로 서로 연관된 함수에서 같은 대상을 다른 이름으로 불러도 안 됩니다(일관성).

 

• 추상화 단계에 따른 이름 짓기

함수의 이름은 내려갈수록 구체적으로

반대로, 변수의 이름은 내려갈수록 추상적으로

 

• 인자

인자 수는 1~2개로 유지합니다.

3개를 넘어가는 경우 구조체로 묶어서 주고받는 편이 낫습니다.

 

클린코드를 자주 들어봐서 한번 정리할 겸 느껴지는 것들만 정리해봤다.

나중에 책 사서 읽어보는 것도 좋을 것 같다.