[클린코드] 1주차 스터디(1장. 깨끗한 코드 ~ 2장. 의미 있는 이름)

책을 읽게 된 계기

프로그래밍을 공부하는 학생들이라면 한 번즘 들어봤을 클린코드는 너무나 유명한 책이라 꼭 읽어보고 싶었다. 특히, 프로젝트를 진행하면서 주석을 유지해야 하는지, 변수와 함수의 네이밍을 어떻게 해야 하는지, 코드 리뷰에서 어떤 기준을 지향해야 하는지 항상 고민이 많았다. 이러한 고민을 해결하고 더 좋은 코드를 작성하는 방법을 배우기 위해 이 책을 선택하게 되었다.

1장. 깨끗한 코드

나쁜 코드는 개발 속도를 저하시킬 뿐만 아니라, 유지보수의 어려움을 초래하며 결국 실패로 이어질 가능성을 높인다. 이러한 실패의 책임은 결국 프로그래머에게 돌아오기 때문에 전문적인 프로그래머라면 깨끗한 코드를 작성하기 위해 끊임없이 연습해야 한다.

하지만 나쁜 코드를 구분할 줄 안다고 해서 반드시 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다. '코드 감각'이 타고나지 않았다면, 좋은 코드를 작성하는 능력을 의식적으로 연습하고 습득해야 한다. 단순히 프로젝트가 정상적으로 동작하는 것에 의의를 두는 것이 아니라, 코드의 지속 가능성까지 고려해야 한다.

✅ 깨끗한 코드란 무엇일까?

여러 프로그래머들의 의견을 종합해보면, 깨끗한 코드는 다음과 같이 정의할 수 있다.

• 보기에 깔끔하고 직관적인 코드
• 읽고 수정하기 쉬운 코드
• 중복을 최소화하고 적절한 추상화를 고려한 코드
• 예상한 대로 동작하는 코드

여기에 더해, 저자가 강조하는 핵심 개념 중 하나는 바로 '보이스카우트 규칙'이다.

캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.

보이스카우트가 따르는 간단한 규칙이 우리 전문가들에게도 유용하다. 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다. 짧은 시간이더라도 지속적으로 개선해나간다면 한꺼번에 많은 시간과 노력을 코드 정리에 쏟을 필요가 없다.
이를 위해 저자는 리팩토링을 지속적으로 수행할 것을 강조한다.

이 장을 읽으며, 단순히 코드를 작성하는 것이 아니라 더 나은 코드로 발전시켜 나가려는 태도가 중요하다는 것을 다시금 깨닫게 되었다. 지속 가능한 코드 작성을 위해 끊임없이 고민하고, 리팩토링하는 습관을 길러야겠다.

 

2장. 의미 있는 이름

2장에서는 여러 네이밍 방법을 소개하고 있다. 사실 회사나 프로젝트마다 네이밍 컨벤션이 존재하기 때문에 클래스는 명사구, 메소드는 동사구로 작성해야 한다는 기본적인 규칙 정도는 익숙했다. 하지만 의미가 중복되는 변수명을 자주 사용했던 경험이 있어, 이 장을 더욱 흥미롭게 읽을 수 있었다.

✅ 올바른 네이밍 방법

📌의도가 드러나는 이름을 사용해라

아래 첫 번째 코드는 코드의 맥락이 명확하지 않아 코드가 수행하는 작업을 직관적으로 이해하기 어렵다. 특히 변수명과 숫자 값(매직 넘버)이 의미를 전달하지 못해 코드의 의도를 쉽게 파악할 수 없다. 
반면, 아래 두 번째 코드는 보다 명확하고 직관적인 코드로 개선되었다. 의미 있는 변수명과 메서드명을 사용하고, 숫자 값(매직 넘버)을 제거함으로써 코드의 맥락이 더욱 명확해졌다.

public List<int[]> getThem() {
 	List<int[]> list1 = new ArrayList<>();
 	for (int[] x : theList)
    	if (x[0] == 4)
	  		list1.add(x);
  	return list1;
}

public List<Cell> getFlaggedCells() {
	List<Cell> flaggedCells = new ArrayList<>();
	for (Cell cell : gameBoard)
		if (cell.isFlagged())
			flaggedCells.add(cell);
	return flaggedCells;
}

📌그릇된 정보를 피하라

혼동되는 의미, 약어, 흡사한 이름을 사용하지 말아야 한다. 예를 들어, 여러 계정을 그룹으로 묶을 때 acoountList보다 accounts 혹은 accountGroup으로 짓는 것이 낫다. List는 컨테이너 유형으로 이름에 넣지 않는 편이 바람직하기 때문이다.

📌의미 있게 구분하라

연속된 숫자를 붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다. 먼저, 연속된 숫자를 덧붙인 이름에는 a1, a2, a3...가 있고 불용어에는 info, data, 관사가 있다. ProductInfo나 ProductData 와 같은 클래스명은 개념을 구분하지 않은 채 이름만 달리한 경우이므로 단순하게 Product 로 짓는 것이 더 적절하다.

📌발음하기 쉬운 이름 사용

발음하기 어려운 이름은 소통을 어렵게 만든다. 코드 리뷰나 협업에서 혼선을 줄이기 위해 누구나 쉽게 읽고 말할 수 있는 변수명을 사용하는 것이 중요하다.

📌검색하기 쉬운 이름을 사용하라

숫자는 코드 내에서 쉽게 눈에 띄지 않으며 검색도 어렵다. 따라서 직관적인 상수명을 사용하여 가독성을 높이는 것이 중요하다.

int realDaysPerIdealDay = 4;
const int WORK_DAYS_PER_WEEK = 5;
for (int j=0; j < WORK_DAYS_PER_WEEK; j++) {
	// 상수를 이용한 예제
}

📌접두어는 필요할 때만 사용하라

인터페이스 클래스를 만들 때 ShapeFactory, IShapeFactory 중에 고민할 것이다. 저자는 접두어를 붙이는 것보다 ShapeFactory로 짓고 구현체는 ShapeFactoryImp라고 명명하는 것이 좋다고 한다. 하지만 이 부분은 팀마다 네이밍 컨벤션이 다를 수 있어 논란의 여지가 있다. 어떤 곳에서는 타입을 명시하기 위해 T 접두어를 붙이거나, 멤버 변수에 클래스명을 포함하는 경우도 있기 때문이다.
반면에, 접두어를 추가하여 의미있는 맥락을 만들 수도 있다. 예를 들어 주소 관련 변수를 firstName, lastName, state로 정의하면 맥락이 명확하지 않다. 그러나 addr이라는 접두어를 추가하여 addrFirstName, addrLastName, addrState로 네이밍하면 주소라는 맥락을 명확히 전달할 수 있다.

📌일관성 있는 어휘

한 프로젝트 내에서 동일한 개념을 여러 가지 단어로 표현하면 혼란을 초래한다. 예를 들어, fetch, retrieve, get으로 제각각 다른 표현을 사용한다면 유지보수에 많은 시간이 걸릴 것이다. 따라서, 한 단어를 여러 의미로 사용하거나, 같은 개념을 여러 단어로 표현하지 않도록 유의해야 한다.

 

---

좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고, 팀원들과의 문화적 배경이 비슷해야 한다. 이처럼 네이밍은 굉장히 어려운 일이기 때문에 프로그래머들은 네이밍에 많은 시간을 투자한다. 클린코드 책이 제시하는 방법이 유일한 정답은 아니므로 여러 회사가 사용하는 네이밍 컨벤션을 공유하며 포스팅을 마무리하겠다.

https://github.com/PRNDcompany/android-style-guide/blob/main/Kotlin.md

android-style-guide/Kotlin.md at main · PRNDcompany/android-style-guide

https://naver.github.io/hackday-conventions-java/

캠퍼스 핵데이 Java 코딩 컨벤션

https://nuli.navercorp.com/data/convention/NHN_Coding_Conventions_for_Markup_Languages.pdf