코드 다듬기

클린 코드 발자국

주식의 양면성

✅ 주식이 많다는 것은 비즈니스 요구사항을 코드 레벨에서 설명 하지 못 했다는 이야기

⚠️ 코드를 설명하는 주석에 대한 영향도는 코드를 설명 하는 주석에서 안좋은 주석 의 영향도가 나온다. 코드를 설명하는 주석은 개발자의 의도에 맞게 작성 된 코드가 아닌 주석에 의존하는 상황이 발생 하며, 주석에 의존하게 되는 경우 구현부에 있을 코드를 작성 한 뒤 주석으로 마무리 하려는 습관이 나온다. 즉, 낮은 품질의 코드를 생산 하는 길이 되는 것

"주석은 언제 써야 할까?"

좋은 주석이란?

• 의사 결정의 히스토리 를 도저히 코드로 표현 할 수 없을 때 주석으로 설명 할 것

• 주석에 자주 변하는 정보는 최대한 지양 해서 작성 할 것

• 코드나 정책의 변경 시 주석 주석도 함께 업데이트 할 것

  • 주석이 없는 코드 보다 부정확한 주석이 달린 코드가 더 치명적이다.

예시

/**
* 객체의 정책 설명 ...
* A안, B안 중 AB 테스트를 통해 결정된 사항으로 작성 ...
* 관련 문서: https://example.com
*/
public class ExamplePolicy {

정리하기

좋은 주석은 우리가 가진 모든 표현 방법을 총 동원 하여 코드에 의도를 녹여내고 난 다음에도 전달 해야 할 정보가 남아 있을 때 사용 하는 것이다.

✳️ 레거시 코드를 읽을 때 최대한 코드 레벨에서 이해를 높히는 것을 간과하지 말 것

변수와 메서드 배치

변수

• 변수를 사용하는 곳과 가까운 위치에 둔다. -> 변수가 등장 한 이후 긴 시간이 흐른 뒤 사용 된다면 변수의 존재를 잊거나 변수의 내용을 잊어버릴 수 있다. 되도록 가까운 위치에 두는 것이 좋다.

메서드

• 객체는 협력을 위한 존재이기 때문에 객체와 협력 하는 존재에게 드러낼 정보를 가장 상단에 위치하는 것을 선호하는 편이다.

Public 메서드

• Public 메서드끼리도 나름의 기준을 가지고 배치하는 것이 좋다.

  • 상태 변경 로직(핵심) > 판별(상태를 묻는 행동) >= 조회 메서드(상태 값 조회)

Private 메서드

• Public 메서드에서 언급 된 순서대로 배치 한다.

• 만약, 공통으로 해당 Private 메서드를 사용하는 곳이 많다면 가장 하단 또는 Private 메서드가 시작하는 곳에 배치한다.

패키지 나누기

패키지 이름은 문맥의 정보를 담아 상대방이 읽게 하여금 다른 의미를 제공 할 수 있다.

• gamelevel / Beginner, Middle, Advanced

Beginner가 어떤 행동을 하는 클래스인지 몰라도 gamelevel 패키지 내에 속해 있다면 Beginner 레벨이라는 것을 알 수 있는 것과 같다.

패키지를 쪼개지 않으면 관리가 어렵고, 패키지를 너무 쪼개면 관리가 어렵다.

본인의 의지만으로 대규모 패키지 변경 커밋을 날리지 말자. 꼭 팀원 간 협의 후 배포 시점을 정하여 결정 할 것!

• 결국 처음 만들 때 잘 고민해서 패키지를 나누는 것이 가장 좋다