안녕하세요 한소희입니다. 공부를 통해 배운 내용을 작성하고 있습니다. 혹여 해당 포스팅에서 잘못된 부분이 있을 경우, 알려주시면 빠르게 수정 조치하도록 하겠습니다. 감사합니다.
목차
좋은 코드란 무엇인가?
좋은 코드의 기준 - Naming
좋은 코드의 기준 - Style
좋은 코드의 기준 - 구조화
01. 좋은 코드란 무엇인가?
개발자에게 가장 중요한 능력 중 하나는 간결하고 확실한 의사소통이라고 생각한다. 이때, 개발자는 코드를 이용해 소통을 하기 때문에, 무엇보다 좋은 코드를 짤 줄 알아야 한다는 것이 나의 의견이다.
그렇다면, 좋은 코드란 무엇일까. 사람마다 '좋은 코드'의 정의는 조금씩 다를 수 있다. 따라서 필자는 '다수의 개발자가 생각하는 좋은 코드의 정의'에 대해 소개해보고자 한다. 함께 좋은 코드의 개념을 익혀보며, '소통에 능한 개발자'가 되어보자!
02. 좋은 코드의 기준 - Naming
첫 번째로 소개할 기준은 작명 센스다.
대부분의 개발자들은 '업무 중 가장 힘든 작업'으로 '작명'을 꼽는다고 한다.
나도 처음에는, 작명 자체를 가볍게 여겨 'i','dsdjo' 처럼 변수명을 지정했지만, 지금은 가장 심혈을 기울이고 있는 부분이다. 개인 프로젝트 시에는 그나마 괜찮지만, 다양한 사람들과 코드를 공유하며 네이밍 작업에서의 중요성을 뼈저리게 느낀다.
일반적으로 작명은, '범용성'과 '구체성' 가운데에서 지어야 한다.
이 말은, '변수의 특징을 분명히 설명하면서도 너무 복잡하지 않은' 명칭을 이용해야 한다는 의미다.
우리가 '각 과목의 점수'를 변수로 지정한다고 가정하자.
이때 'score1', 'score2'... 와 같이 변수를 지정한다면, 각 변수가 어떤 과목 점수를 의미하는지 한눈에 파악할 수 있을까? 그렇지 않다.
이처럼 네이밍은 코드의 가독성에 영향을 미치는 요소다. 그렇다면, 어떤 방식으로 작명을 하는 것이 좋을지 살펴볼 필요가 있다.
2-1. 네이밍 방법
( 원 변수명은 'mathscore' 라고 가정 )
- 스네이크 표기법: math_score
- 파스칼 표기법: MathScore
- 카멜 표기법: mathScore
나는 보통 스네이크 표기법을 애용하는 편이다. 이외 다양한 작명 방법 및 예시는 아래 스타일 설명에서 다룰 '스타일 가이드'를 활용하면 되겠다.
03. 좋은 코드의 기준 - Style
결국, 좋은 코드는 '가독성이 높은 코드' 즉, 간결하며 타인과 소통 시 어려움이 없는 코드다. 하지만, 코드는 개개인이 구조를 짜기 때문에 사람마다 코드를 짜는 방식에서 차이가 날 수 있다. 누구는 주석을 앞에 다는 것을 좋아할 수도 있고, 혹자는 주석을 뒤에 다는 것을 선호할 수 있으니 말이다.
이처럼 사람들마다 좋은 코드의 기준이 다르므로, '좋은 코드'에 대한 정의가 모호해질 수 있다.
각 언어 개발사는 이런 이슈를 해결하기 위해 스타일 가이드를 저마다 작성해두었다.
예를 들어, 파이썬의 경우, 'PEP8'이라는 스타일가이드를 제공한다. 이 곳에 가면, 변수 정의와 띄어쓰기, 탭, 공백, 따옴표 등 세세한 부분에 대한 스타일 가이드가 있는 것을 알 수 있다.
코딩은 타인과 함께 협업하는 경우가 대부분이므로, 각 언어의 스타일가이드를 적절히 활용하는 것이 좋은 습관이라 할 수 있겠다.
⬇ python 스타일가이드 살펴보기
PEP 8 -- Style Guide for Python Code
The official home of the Python Programming Language
www.python.org
04. 좋은 코드의 기준 - 구조화
한 곳에 모아 짠 코드는 마치 '셔츠의 단추'와 같다고 생각한다. 셔츠의 단추를 다 잠갔다고 했을 때, 앞 단추를 잘못 꿰었다면 어떻게 되는가? 첫 단추를 고쳐 매면, 이내 그 아래 단추도 전부 고쳐 매야 할 것이다.
이처럼 한 곳에 모아 짠 경우, 첫 기능을 수정하려고 시도했을 때, 생각하지도 못한 뒷 부분에서 에러가 발생할 수 있다. 이러한 문제를 해결하기 위해, 우리는 구조화(파일 분산)를 해야 한다.
예시로, FLASK의 Blue Print 를 들어보겠다. (2021 전주시빅데이터 분석 공모전을 준비할 때 사용했었다.)
FLASK 앱을 짤 때, 대부분의 개발자는 Blue Print를 활용한다. 이를 활용하면, app route를 기능 별로 분산관리할 수 있기 때문에, 각 페이지의 기능을 간편히 수정/삭제할 수 있기 때문이다.
물론 분산이 무조건적으로 다 좋은 것은 아니다. 정말 아주 간단한 기능 구현의 경우, 굳이 파일을 분산시켜 관리하지 않아도 될 수 있다.
하지만, 프로젝트의 규모가 커질 것을 우려하는 경우라면, 파일 분산을 습관화할 필요성이 있다. 또한 대부분의 대규모 프로젝트도 분산된 개발환경을 갖추고 있다고 하니, 분산 파일 환경에 익숙해져 볼 필요가 있다고 본다.
포스팅을 정리하며 -
가독성이 좋은 코드 / 간결한 코드에 대해 깊이 생각해보게 됐다.
코드는 혼자 운용하는 것이 아닌, 조직이 함께 운용해야 하므로
코드의 가독성과 간결성, 그리고 기준에 맞는 코드 작성이 참 중요하다는 것을 깨닫게 됐다.
앞으로는 네이밍부터 깔끔하게 지정하는 연습을 해보아야겠다.
'컴퓨터 사이언스 (CS) > 자료구조 및 알고리즘' 카테고리의 다른 글
| 06. 프로그래밍과 문제해결_내장 메소드 (0) | 2021.06.03 |
|---|---|
| 05. map 에러 해결 방법 (0) | 2021.06.02 |
| 04. 인스턴스 변수와 메소드 (0) | 2021.06.02 |
| 03. 객체지향 프로그래밍 개론 (0) | 2021.06.02 |
| 01. 프로그래밍 언어 이해하기 (0) | 2021.06.02 |