Clean Code
실무에서의 클린 코드의 의의
Clean Code를 작성해야함이 "개발자 자기만족" 이상으로 회사에서 의의가 있는 이유는 무엇일까?
"그 코드는.. 건드시지 않는게 좋을거예요. 제가 나중에 볼게요."이와 같은 코드를 지뢰코드라고 한다.
지뢰 코드는 흐름 파악이 어렵고 도메인 맥락 표현 안되며 동료에게 물어봐야 알 수 있는 코드를 뜻한다.
이는 후에 추가로 이루어지는 개발 과정에서 병목을 유발하고 유지보수 난이도 높아지는 원인이 되며
보통 성능이 안좋은 경우도 많다.
즉 클린코드를 작성해야 하는 이유는 유지보수 시간의 단축을 위함이다.
읽기좋은 코드는 코드 리뷰와 디버깅 시간을 단축시킨다.
하지만 위와 같은 의견에 반문을 제시하는 사람들도 존재할 것이다.
"실무에서는 일정과 요구사항을 강력하게 밀어붙이는 관리자들이 존재하기 때문에 클린코드고 나발이고 시간이 촉박하다."
스스로가 의사라고 가정해보자.
어떤 환자가 자신을 수술하기 전에 손을 씻지 말아달라고 부탁한다.
하지만 단호하게 거부하며 손을 씻을 것이다.
질병과 감염의 위험은 환자보다 의사가 더 잘 알고있으며
환자의 말을 그대로 따르는 행동은 (범죄일 뿐만 아니라) 전문가 답지 못하기 때문이다.프로그래머도 마찬가지다.
나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 그대로 따르는 것은 전문가답지 못하다.
우리에게 일정으로 압박하는 것은 그들이 해야 할 일이고,
코드를 우아하게 유지하는 것은 우리가 해야 할 일인 것이다.
실전에서의 적용
우리는 기존 코드에 기능을 추가하는 상황이나,
남이 짠 코드 혹은 내가 지난주에 짠 코드에 다른 코드를 추가하는 경우가 많다.
해당 상황에서 자주 발생하는 문제가 존재한다.
(TOSS | SLASH 21 개발자 래퍼런스 의 발표내용 중의 코드를 발췌하여 예시로 사용하였다.)
클린 코드는 짧은 코드를 뜻하는 것이 아니다.
클린 코드는 찾고싶은 로직을 빠르게 찾을 수 있는 코드를 뜻한다.
이를 응집도, 단일책임, 추상화 3가지 측면에서 고려하여 코드를 수정해보도록 한다.
- 응집도
같은 목적을 갖는 코드는 한군데에 뭉쳐두자는 말.
function QuestionPage() {
// ..1
const [popupOpened, setPopupOpened] = useState(false);
async function handleClick() {
setPopupOpened(true);
}
// ..2
async function handlePopupSubmit() {
await 질문전송(연결전문가.id);
alert('질문을 전송했습니다.');
}
return (
<>
<button onClick={handleClick}>질문하기</button>
{/* ..3 */}
<Popup title='보험 질문하기' open={popupOpened}>
<div>전문가가 설명드려요</div>
<button onClick={handlePopupSubmit}>확인</button>
</Popup>
</>
);
}팝업을 조작하는 코드가 ..1, ..2, ..3에 흩어져있다.
파악도 한번에 되지 않고 버그 발생 가능성도 높은 코드.
해당 코드를 커스텀 훅을 이용해 다음과 같이 한군데에서 관리할 수 있도록 만들 수 있다.
function QuestionPage() {
// custom hook useMyExpertPopup
const [openPopup] = useMyExpertPopup(연결전문가.id);
async function handleClick() {
setPopupOpened(true);
}
return (
<>
<button onClick={handleClick}>질문하기</button>
</>
);
}하지만 이는 더 읽기 힘든 코드가 되어버렸다.
어떤 내용의 팝업을 띄우는지, 액션이 어떤지 알아내기 위해서는 파일 이동이 이루어져야하기 때문.
이는 커스텀훅을 사용하는 코드의 대표적인 안티패턴.
당장 몰라도 되는 디테일만 숨기는 형식으로 '코드숨김'을 이루어야 한다.
뭉쳐서 짧은 코드로 만든다고 무조건 깨끗한 코드가 되는건 아니다.
찾아다니면서 의미를 찾아야 하면 그 나름대로 나쁜 코드인 것.
이와같은 핵심 데이터만 전달받고 세부 구현은 뭉쳐서 숨겨두는 프로그래밍을 선언적 프로그래밍 이라고 한다.
'무엇'만 바꿔서 쉽게 재사용이 가능하다는 장점이 있다.
선언적 프로그래밍의 반대는 명령형 프로그래밍 이라고 하지만,
선언적 프로그래밍도 코드를 오픈해보면 모두 명령형 프로그래밍으로 작성되어있다.
선언적 프로그래밍이 최신 트렌드긴 하지만
props으로 세부 내용을 하나하나 컨트롤 해야할 때는 명령형 프로그래밍을 해야하긴 한다.
존재로 의의가 있다는 뜻.
- 단일책임
하나의 일이나 제대로 하는 함수를 만들자는 뜻.
다음은 지난 30여년동안 여러 다양한 표현으로 프로그래머들에게 주어진 충고이다.
함수는 한 가지를 해야한다.
그 한 가지를 잘해야 한다.
그 한 가지만을 잘해야 한다.동일한 함수 내에서 단순히 다른 표현이 아닌, 의미 있는 이름으로 다르게 추출할 수 있다면
그 함수는 여러 작업을 하는 셈이다.
함수가 하나의 일만 제대로 할 수 있도록 함수를 짜는데에 가장 중요한 첫번째 규칙은
함수를 '작게' 유지하는 것이다.
함수의 내부 코드는 5~10줄을 넘어가면 안되고
들여쓰기 또한 2단을 넘어가면 안된다.
이는 [woowacourse/woowacourse-docs] PR전 clean code guide에도 모두 명시되어 있다.
완벽한 함수를 만들었다면 그에 상응하는 완벽한 이름을 지어주어야 한다.
함수는 동사로 시작하며 해당 기능을 모두 설명할 수 있는 변수명을 달아주도록 한다.
한가지 팁은, 이름짓기가 복잡(영어 이름이 너무 길어질 때)하면 한글 변수명을 사용하는것도 좋은 효과를 볼 수 있다는 것.
- 추상화
로직에서 핵심 개념을 뽑아내는 것을 말한다.
구체적인 코드를 추상화 하면 코드가 짧아지고 타인이 혹은 미래의 자신이 이해하는데 좋게 할 수 있다는 것.
'피카소의 소'로 추상화를 이해해보자.
구체적인 소의 모습에서 디테일을 지워나가다가 본인이 소에서 남기고 싶은 개념만 남겨 둔 모습이다.
이를 코드에서 적용해보면 다음과 같다.
추상화 전
<div style={팝업스타일}>
<button
onClick={async () => {
const res = await 회원가입();
if (res.success) {
프로필로이동();
}
}}
>
전송
</button>
</div>;추상화 후
<Popup onSubmit={회원가입} onSuccess={프로필로이동}></Popup>;추상화에도 단계(위의 소 그림을 생각)가 존재하기때문에 하나의 파일에서는 추상화 단계를 맞춰주는게 좋다.
하나의 파일 내에서 단계가 너무 중구난방이면 사고가 널뛰게 되고, 이는 신뢰도를 떨어뜨린다.
// ...
return (
<>
{/* 높은 추상화 */}
<Title>별점을 매겨주세요</Title>
{/* 낮은 추상화 */}
<div>
{STARS.map(() => (
<Star />
))}
</div>
{/* 높은 추상화 */}
<Reviews />
{/* 낮은 추상화 */}
{rating !== 0 && (
<>
<Agreement />
<Button rating={rating} />
</>
)}
</>
);제시하는 액션 아이템
담대하게 기존코드 수정하기
쫄지말고 기존 코드를 씹고 뜯고 맛보고 즐기고 부시자.
큰 그림 보는 연습하기
'그때는 맞고 지금은 틀리다.'인 코드들이 많다.
기능 추가 자체에서 큰 문제가 발생할 확률이 굉장히 높기 때문에 그림을 크게 보는 시야가 중요하다.
팀과함께 공감대 형성
명시적으로 이야기를 하는 시간이 필요하긴 하다는 것.
ETC
본문은 다음의 내용을 기반으로 작성되었음을 알립니다.
