반응형
1. 이름이 중요한 이유
예루살렘 히브리 대학교의 전산학과 교수 드로 페이텔슨은 프로그래밍 작업에서 이름을 선택하는 실험을 통해 모호하지 않은 이름을 생각해 내는 것이 얼마나 어려운지를 증명했다.
- 명명이 중요한 이유
- 이름은 코드베이스의 상당 부분을 차지한다. 200만줄의 이클립스 소스코드에서 토큰의 33%, 문자의 72%가 식별자에 해당한다.
- 코드 리뷰 시 이름에 관해 많이 언급됨 4건 중 1건이 명칭과 관련한 언급을 포함했으며, 식별자 이름에 대한 언급은 9%를 차지하는 것으로 나타냈다.
- 이름은 문서화의 가장 쉬운 형태 프로그래머가 가장 많이 읽는 문서는 코드 내의 주석과 이름이다.
- 이름이 표식 역할 할 수 있다. 변수 이름은 주석문 외에도 코드를 이해하는 데 도움이 되는 중요한 표식이다.
- 명명에 대한 다양한 관점
- 버틀러: 좋은 이름은 문법적으로 정의할 수 있다.
- 알라마니스: 이름은 코드베이스 내에서 일관성이 있어야한다.
- 초기 명명 관행은 지속적인 영향을 미친다.
- 존스 홉킨스 대학교의 수석연구원 돈 로리는 명명 동향을 조사해 본 결과 프로그램 개발 초기에 만들어진 식별자의 품질이 계속 유지된다는 결론을 도출했다.
2. 명명의 인지적 측면
- 형식이 있는 이름은 STM을 돕는다.
- 명확한 이름이 LTM에 도움이 된다.
- 변수 이름은 이해에 도움이 되는 다양한 유형의 정보를 포함할 수 있다.
- 코드의 도메인에 대해 생각할 때 이름이 도움이 된다.
- 프로그래밍에 대해 생각할 때도 이름이 도움이 된다.
- 경우에 따라 변수에 LTM이 이미 알고 있는 규약에 대한 정보가 포함될 수도 있다.
- 이름의 품질 평가 시기
- 문제해결에 몰두하고 있을 때에는 높은 인지 부하를 겪기 십상이기 때문에 좋은 변수 이름을 생각하기 어렵다. 그러므로 코드 리뷰를 통해 식별자의 이름을 검토하는 시간을 가져보자
3. 어떤 종류의 이름이 더 이해하기 쉬운가?
- 축약할 것인가, 하지 않을 것인가?
- 코드를 이해하고 버그를 쉽게 찾기 위해서라면 명확한 의미의 단어를 사용해야 하는 반명, 기억을 잘하기 위해서라면 간결한 약자를 사용해야 한다. 좋은 변수 이름을 명명하기 위해서는 이 둘 사이의 주의 깊은 균형이 필요하다.
- 단일 문자가 변수로 흔히 사용된다.
- 예루살렘 히브리 대학교의 연구원 갈 베니아미니의 연구를 통해 단일 문자 변수 이름과 데이터 타입의 연관성에 대해 당연한 것으로 여길 수 없다는 점을 상기시켜 준다. 따라서 식별자의 이름으로 단어를 선택하거나 명명 규약에 따르는 것이 향후 코드 이해를 위해 더 나은 방법이다.
- 스네이크 케이스냐, 캐멀 케이스냐?
- 로욜라 대학교 메릴랜드의 컴퓨터 과학 교수 데이브 빙클리의 캐멀 케이스 변수와 스네이크 케이스 변수에 대한 이해도의 차이의 결과를 보면 캐멀 케이스가 개발자와 비 개발자 모두에게 더 높은 정확도로를 갖는다.
4. 이름이 버그에 미치는 영향
- 나쁜 이름을 가진 코드에 버그가 더 많다
- 버틀러는 잘못된 명명 방식은 단지 읽고 이해하고 유지 보수하기 어려운 코드가 아니라 잘못된 코드일 가능성이 높다는 연관성을 발견했다.
5. 더 나은 이름을 선택하는 방법
- 이름 틀
- 이름 틀은 변수 이름의 요소가 일반적으로 결합되는 패턴이다.
- 인지 부하 측면에서 관련된 개념을 변수 이름 내에서 그리고 변수이름 내 다른 위치에서 찾는 것은 불필요한 외부 인지 부하를 유발한다.
- 변수 이름이 비슷한 겨우 동일한 이름 틀을 사용하면 LTM이 관련 정보를 더 쉽게 찾을 수 있다.
- 더 나은 변수명에 대한 페이텔슨의 3단 게 모델
- 이름에 포함할 개념을 선택한다.
- 각 개념을 나타낼 단어를 선택한다.
- 이 단어들을 사용하여 이름을 구성한다.
발제문
- 변수의 이름을 결정하는 과정에서 축약 형태와 명확한 의미를 갖는 전체 단어의 선택 사이에서 어떤 균형을 유지하면 좋을까요?
저는 코드 작성 시 for문을 최대한 사용을 안 하는데 그 이유는 i나 j 같은 단일 문자가 특정 알고리즘의 변수로 사용되는 순간 머리가 멈춰버리는 성능 낮은 작업 기억 공간을 갖고 있기 때문입니다. 대신 상황에 맞게 map이나 filter같은 고차 함수를 애용하는 편입니다.
그리고 축약 형태도 불호하는 편입니다. 회사에서 “법인회사 코드”에 관한 db칼럼 명을 compCd(companyCodeDetail)로 사용했었는데 새롭게 들어온 모든 팀원들이 compCd에 대한 의미를 모른 채 개발했고 결국엔 서비스까지 문제가 생기는 일화가 있었습니다. 그리고 db칼럼명을 직관적으로 바꾸기 위해 추가 인력까지 발생하는 악순환이 현재 진행 중입니다.
반응형
'독서 > 2024' 카테고리의 다른 글
[프로그래머의 뇌] CHAPTER10 복잡한 문제 해결을 더 잘하려면 (0) | 2023.05.15 |
---|---|
[프로그래머의 뇌] CHAPTER9 나쁜 코드와 인지 부하를 방지하는 두 가지 프레임워크 (0) | 2023.05.15 |
[프로그래머의 뇌] CHAPTER7 생각의 버그 (0) | 2023.05.14 |
[프로그래머의 뇌] CHAPTER6 코딩 문제 해결을 더 잘하려면 (1) | 2023.05.14 |
[프로그래머의 뇌] CHAPTER5 코드를 더 깊이 있게 이해하기 (1) | 2023.05.13 |