📔

Clean Code

많은 개발자들이 말하는 적절한 추상화 뭘까?

개발자들이 자주 언급하지만 막연하게 이해하는 추상화 수준을 실전에서 어떻게 판단하고 적용할 수 있는지 구체적으로 알아보자.

추상화 수준이란?

추상화 수준(Level of Abstraction)은 코드가 "무엇을 하는가(What)"와 "어떻게 하는가(How)" 사이에서 어느 위치에 있는지를 나타낸다.

높은 수준: 비즈니스 로직, 도메인 개념

중간 수준: 알고리즘 구조, 제어 흐름

낮은 수준: 구현 세부사항, 기술적 디테일

우리는 저자다.
Javadoc 에서 @author 필드는 저자를 소개한다. 우리는 저자다. 저자에게는 독자가 있다.  그리고 저자에게는 독자와 잘 소통할  책임도 있다. 
다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하길 바란다. 

코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다. 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 읽기쉬운 코드가 짜기가 쉽지는 않더라도 말이다.  급하다면, 서둘러 끝내려면, 쉽게 짜려면 읽기 쉽게 만들면 된다.

보이스카우트 규칙

캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
지속적인 개선이야 말고 전문가 정신의 본질이 아니던가?

예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없듯이 클린코드 책을 단지 읽었다고만 해서 코드를 잘짠다는 보장도 뛰어난 프로그래머가 된다는 보장도 없는것 같다.

주변에서 해당 책 또한 이젠 오래되었다고 하지만 한편으론 이런 책을 통해 글쓴이의 생각에 편협되지 않고 지속적으로 비판적으로 생각하며 연습 했을 때 책의 효능감을 얻지 않을까 한다.

[0- 1장] 깨끗한 코드

주석이 아닌 시스템이 말하게 하기

들어가면서

주석에 대해 진지하게 생각해보았던가? 남발은 하지 말고 꼭 필요한곳에 주석을 사용하자는건 알지만 남발의 기준은? 꼭 필요한곳의 기준은? 애매 모호한 부분을 좀 더 알아보려고 한다.

브라이언 w.커니헨, P.J.플라우거는 나쁜 코드에 주석을 달지말라. 새로 짜라.라고 한다. 코드로 그만큼 충분히 의도를 표현하지 못했다고 이해해볼 수도 있다. single of truth가 되는 코드가 이미 잘못되었는데 여기에 덧붙이는 주석은 오히려 문제점을 더 가지고 올 수 있다고 생각한다. 어떤 문제점이냐면 주석은 오래될 수록 코드에서 멀어진다. 그래서 결국 거짓말을 하게 되고 프로그래머들이 주석을 유지하고 보수하기가 현실적으로 어려워 지는 문제점이다.

clean code책과 파이브오브라인을 참고해 케이스들을 정리해보았다.

본문

1.개발 중 유용하게 사용한 주석은 개발 후 배포전에는 제거 할 수 있게 버전 관리 시스템을 이용하는게 좋다.

간혹 새로운 코드를 실험해 보면서 실패하면 신속하게 되돌리기 위해 기존코드를 주석으로 처리하는 경우가 있다. 이 때 문제는 혼자 작업하거나 깃브랜치에 대한 시스템이 팀에 정립되어 있지 않은 경우 혹은 main위에서 작업하는 경우 이미 main에 주석이 병합되고 나면, 개발자가 이를 정리할 타이밍을 놓칠 때가 있다. 주석으로 옛 코드를 남겨두는 대신, Git 브랜치를 활용해 실험과 복구를 관리하는게 좋다. 브랜치를 따서 실험하고 실패하면 버리면 되고, Git이 모든걸 기억하니 따로 주석을 백업할 필요가 없다.

그렇지 않으면 아래와 같이 main 코드가 주석투성이가 되거나, 다른 팀원이 보기엔 “어느 게 진짜 코드인지” 혼란스러워 진다.

[4 장] 주석 - 주석이 아닌 시스템이 말하게 하기

챕터의 초반부터 getter/setter는 private 변수의 의미를 무색하게 만드는 자기모순적인 패턴이라고 비판한다. 변수를 숨기면서 동시에 노출하는 이 어중간한 접근이 객체도 자료구도조 아닌 마치 최악의 하이브리드를 만드는 모순을 보여주었다.

예를 들어, 다음과 같은 코드를 보자:

이 클래스는 겉으로는 객체처럼 보이지만, 실제로는 단순히 데이터를 담는 자료구조에 불과하다. private으로 변수를 숨겼지만, getter/setter를 통해 외부에서 마음대로 접근할 수 있기 때문이다. 이는 다음 코드와 본질적으로 다르지 않다:

[6장] 객체와 자료구조 곱씹어보기

주요 내용들을 정리하자면 다음과 같다.

수직 형식 (Vertical Formatting)

파일 크기: 작은 파일이 이해하기 쉬움 (200~500줄 정도가 적당)

신문 기사처럼: 위에서 아래로 읽을 때 고수준 개념이 먼저, 세부사항은 아래로

수직 거리: 관련된 개념은 가까이, 관련 없는 개념은 멀리 배치

수평 형식 (Horizontal Formatting)

행 길이: 120자 이하 권장

가로 공백: 연산자 주변, 함수 이름과 괄호 사이 등에 공백으로 의미 강조

팀 전체가 일관된 형식 규칙을 따르는 것이 개인 취향보다 중요

[5장] 형식맞추기 - 단순한스타일이 아닌 커뮤니케이션의 문제