코드 다듬기
클린 코드 발자국
주식의 양면성
✅ 주식이 많다는 것은 비즈니스 요구사항을 코드 레벨에서 설명 하지 못 했다는 이야기
⚠️ 코드를 설명하는 주석에 대한 영향도는 코드를 설명 하는 주석에서 안좋은 주석 의 영향도가 나온다. 코드를 설명하는 주석은 개발자의 의도에 맞게 작성 된 코드가 아닌 주석에 의존하는 상황이 발생 하며, 주석에 의존하게 되는 경우 구현부에 있을 코드를 작성 한 뒤 주석으로 마무리 하려는 습관이 나온다. 즉, 낮은 품질의 코드를 생산 하는 길이 되는 것
"주석은 언제 써야 할까?"
좋은 주석이란?
의사 결정의 히스토리 를 도저히 코드로 표현 할 수 없을 때 주석으로 설명 할 것
주석에 자주 변하는 정보는 최대한 지양 해서 작성 할 것
코드나 정책의 변경 시 주석 주석도 함께 업데이트 할 것
주석이 없는 코드 보다 부정확한 주석이 달린 코드가 더 치명적이다.
/**
* 객체의 정책 설명 ...
* A안, B안 중 AB 테스트를 통해 결정된 사항으로 작성 ...
* 관련 문서: https://example.com
*/
public class ExamplePolicy {정리하기
변수와 메서드 배치
변수
변수를 사용하는 곳과 가까운 위치에 둔다. -> 변수가 등장 한 이후 긴 시간이 흐른 뒤 사용 된다면 변수의 존재를 잊거나 변수의 내용을 잊어버릴 수 있다. 되도록 가까운 위치에 두는 것이 좋다.
메서드
객체는 협력을 위한 존재이기 때문에 객체와 협력 하는 존재에게 드러낼 정보를 가장 상단에 위치하는 것을 선호하는 편이다.
Public 메서드
Public 메서드끼리도 나름의 기준을 가지고 배치하는 것이 좋다.
상태 변경 로직(핵심) > 판별(상태를 묻는 행동) >= 조회 메서드(상태 값 조회)
Private 메서드
Public 메서드에서 언급 된 순서대로 배치 한다.
만약, 공통으로 해당 Private 메서드를 사용하는 곳이 많다면 가장 하단 또는 Private 메서드가 시작하는 곳에 배치한다.
패키지 나누기
패키지 이름은 문맥의 정보를 담아 상대방이 읽게 하여금 다른 의미를 제공 할 수 있다.
gamelevel / Beginner, Middle, Advanced
Beginner가 어떤 행동을 하는 클래스인지 몰라도 gamelevel 패키지 내에 속해 있다면 Beginner 레벨이라는 것을 알 수 있는 것과 같다.
패키지를 쪼개지 않으면 관리가 어렵고, 패키지를 너무 쪼개면 관리가 어렵다.
본인의 의지만으로 대규모 패키지 변경 커밋을 날리지 말자. 꼭 팀원 간 협의 후 배포 시점을 정하여 결정 할 것!
결국 처음 만들 때 잘 고민해서 패키지를 나누는 것이 가장 좋다
Last updated