주니어 개발자가 경험한 읽기 쉬운 코드를 위한 네이밍 가이드
들어가며
개발자로서 일을 시작하고 가장 많이 고민했던 것이 바로 이름 짓기
입니다. 처음에는 단순히 ‘data’, ‘temp’, ‘result’ 같은 간단한 이름들을 많이 사용했는데, 시간이 지날수록 이런 이름들이 얼마나 문제가 될 수 있는지 깨달았습니다.
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.” - Robert C. Martin
로버트 마틴의 이 말씀이 처음에는 와닿지 않았습니다. 하지만 실무에서 일하면서 코드를 작성하는 시간보다 읽는 시간이 훨씬 더 많다는 것을 직접 경험했습니다. 새로운 기능을 개발하거나 버그를 수정할 때도 기존 코드를 이해하는 데 대부분의 시간을 쓰게 되더라구요.
이름은 의도를 전달해야 한다
처음 개발을 시작했을 때는 짧은 변수명이 더 “프로페셔널”해 보인다고 생각했습니다. 하지만 실제로는 정반대였죠.
// Before
function calc(p) {
let t = 0;
p.forEach((i) => (t += i.d));
return t;
}
// After
function calculateTotalDeposit(propertyContracts) {
let totalDeposit = 0;
propertyContracts.forEach((contract) => (totalDeposit += contract.deposit));
return totalDeposit;
}
팀 프로젝트를 하면서 깨달은 건, 다른 개발자가 내 코드를 봤을 때 바로 이해할 수 있는 게 진정한 프로페셔널한 코드라는 것이었습니다.
이름은 설명적이어야 한다
주니어 개발자 시절, 코드 리뷰에서 가장 많이 받았던 피드백이 “이 함수가 정확히 무슨 일을 하는 건가요?”였습니다.
// Before
function processProperty(data) {
// 매물 등록 처리 로직
}
// After
function validateAndRegisterPropertyListing(propertyData) {
// 매물 등록 및 검증 로직
}
이름이 설명적이면 주석이 없어도 코드를 이해할 수 있다는 걸 배웠습니다.
오해의 소지가 있는 이름 피하기
실무에서 가장 많이 실수했던 부분이 바로 모호한 동사 사용이었습니다.
// Before
function update(id) {
// 매물 상태 업데이트 로직
}
// After
function updatePropertySaleStatus(propertyId) {
// 매물 판매 상태 업데이트 로직
}
특히 get
, process
, handle
같은 모호한 동사를 남발했던 게 가장 큰 실수였습니다. 코드 리뷰 때마다 “이 함수가 정확히 뭘 하는 건가요?”라는 질문을 받았죠.
이름은 발음하기 쉬워야 한다
실제로 팀 회의에서 코드를 설명할 때 이런 경험이 있었습니다:
// Before
function getGPEvalDoc(id) {
// 감정평가서 조회 로직
}
// After
function getPropertyAppraisalReport(propertyId) {
// 감정평가서 조회 로직
}
약어를 사용하면 코드는 짧아지지만, 팀원들과 소통할 때 “티엠피유에스알데이터”라고 더듬거리며 설명하게 되더라구요.
약어를 피하자
신입 시절 이런 코드를 많이 작성했습니다:
// Before
let propAddr = ""; // 매물 주소
let mthRent = 0; // 월세
let maintFee = 0; // 관리비
let secDep = 0; // 보증금
// After
let propertyAddress = "";
let monthlyRent = 0;
let maintenanceFee = 0;
let securityDeposit = 0;
코드 몇 글자 줄이겠다고 약어를 사용했다가, 나중에 그 코드를 다시 볼 때마다 해석하느라 더 많은 시간을 낭비했습니다.
마무리
주니어 개발자로 1년을 보내면서 가장 크게 배운 점은, 좋은 코드는 작동하는 코드가 아니라 읽기 쉬운 코드라는 것입니다. 처음에는 “돌아가기만 하면 되지”라고 생각했지만, 이제는 “다음에 이 코드를 볼 사람이 이해할 수 있을까?”를 항상 고민하게 됐습니다.
제가 경험한 것들이 다른 주니어 개발자분들에게도 도움이 되었으면 좋겠습니다. 아직도 배울 게 많지만, 적어도 이름 짓기에 대해서는 조금 더 자신감이 생겼네요!
참고 자료
- Clean Code - Robert C. Martin
- A Guide to Clean Code: The Power of Good Names