[워밍업 클럽 3기] BE클린코드&테스트코드 Day6

🟡 오늘의 목표 진도

---

섹션6. 객체 지향 적용하기

 - 주석의 양면성

 - 변수와 메서드 나열 순서

 - 패키지 나누기

 - 기능 유지보수하기(1) - 버그 잡기

 - 기능 유지보수하기(2) - 알고리즘 교체하기

 - IDE의 도움 받기

 - 키워드 정리

 

 

🟠 공부 정리

---

1. 주석의 양면성

✔ 주석의 양면성

•   주석多 -> 비지니스 요구사항을 코드에 못 녹였다는 이야기
• 코드를 설명하는 주석을 쓰면, 코드가 아니라 주석에 의존 -> 낮은 품질의 코드 만들어짐

✔ 좋은 주석

•  리팩토링 할 때 큰 난관 중 하나 -> 히스토리를 전혀 알 수 없는 코드
• 후대에 전해야 할 “의사 결정의 히스토리”를 도저히 코드로 표현할 수 없을 때, 주석으로 상세하게 설명
• 주석을 작성할 때, 자주 변하는 정보는 최대한 지양해서 작성
• 만약 관련 정책이 변하거나 코드가 변경되었다면, 주석도 잊지 않고 함께 업데이트하기
• 주석이 없는 코드보다, 부정확한 주석이 달린 코드가 더 치명적

✔ 💡좋은 주석의 결론

우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석

2. 변수와 메서드의 나열 순서

 ✔  변수

•   사용하는 순서대로 나열하기

 ✔ 메서드

•  객체는 협력을 위한 존재. 외부 세계에 내가 어떤 기능을 제공할 수 있는지를 드러냄. 공개 메서드를 상단에 배치하는 것을 선호하는 편
• 공개 메서드끼리도 기준(중요도 순, 종류별로 그룹화하여 배치)을 가지고 배치하는 것이 좋음
• 상태 변경 >> 판별 >= 조회 메서드
• 비공개 메서드는, 공개 메서드에서 언급된 순서대로 배치
• 공통으로 사용하는 메서드라면, (가장 하단과 같은) 적당한 곳에 배치

3. 패키지 나누기

 ✔ 패키지는, 문맥으로써의 정보를 제공할 수 있음

 ✔ 패키지를 쪼개지 않으면 관리가 어려워짐

 ✔ 패키지를 너무 잘게 쪼개도 마찬가지로 관리가 어려워짐

 ✔ 대규모 패키지 변경은 팀원과의 합의를 이룬 시점에 하기

 

 

🔵 공부 후 나의 생각 

---

팀 프로젝트에서 코드를 작성하면서,

나는 다른 사람들이 이해하기 쉽도록 주석을 적극적으로 활용했다.

하지만 주석만으로 코드를 설명하는 것이 최선이 아닐 수도 있다는 점을 깨달았다.

 

코드는 시간이 지나면서 변경될 수밖에 없는데,

만약 주석이 코드와 함께 유지되지 않는다면 오히려 혼란을 초래할 수 있다.

변경된 코드와 맞지 않는 주석이 남아 있다면, 이를 본 사람은 잘못된 정보를 얻을 수도 있다.

 

그렇기 때문에 설명을 최대한 코드 자체에 녹여내는 것이 중요하다는 것을 배울 수 있었다.

 

앞으로는 주석에 의존하기보다는,

지금까지 배운 지식과 스킬로

가독성 높은 코드와 명확한 네이밍을 통해 코드 자체가 설명이 되는 구조를 만들기 위해 노력해야겠다.

 

 

 

* 강의에서 IDE 도움받기 파트에서 Sonarlint를 플러그인설치하는 부분이 있는데

2025년 현재 시점에서 마켓에 Sonarlint를 검색하면 강의에서 처럼 Sonarlint가 나오는것이 아니라

SonarQube for IDE가 나온다 . 해당 플러그인을 설치하면 강의와 동일하게 작동되는걸 볼 수 있음.

 

 

 

 

* 현재 인프런 워밍업 클럽에 참여하여 아래 강의 수강 중입니다.

https://www.inflearn.com/roadmaps/5699

클린 코드 & 테스트 코드 가이드 로드맵 로드맵 - 인프런

https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95

Readable Code: 읽기 좋은 코드를 작성하는 사고법 강의 | 박우빈 - 인프런