내가 생각하는 협업하기 좋은 코드 [1편]

늘보·2023년 1월 6일
2

코딩스타일

목록 보기
1/2
post-thumbnail

대학생 때 내가 생각하는 '좋은 코드'는 단지 요구사항을 충족하는 최대한 짧은 코드였다.
취업 후 소스코드를 보는데, 내 생각이 완전히 틀렸다는걸 깨닫고 서점에 가서 책을 한 권 구매하게 된다. 그 책의 이름은 로버트 C. 마틴의 'Clean Code' 였고, 아직도 처음 읽었을 때 충격을 잊지 못한다. 책을 접한 이후 '좋은 코드'란 '협업하기 좋은 코드'라는 생각과 함께 다음과 같은 생각을 하게 되었다.

'누군가가 내 코드를 읽고, 수정하기 쉬워야 그 코드는 비로소 하나의 의미있는 자산이 되는구나.'

해당 포스팅에선 책의 내용 일부와 더불어 내가 현업에서 코드를 작성하며 느낀 '좋은 코드'에 대한 생각을 함께 정리해보고자 한다.

📍 '좋은 코드'의 기준은 사람마다 다를 수 있음을 유의하자.


1. 이해가 쉬운 코드

1.1 함수/변수명은 명확히

함수명과 변수명은 명확해야한다.

업무 중 data라는 변수를 보고 당황한 적이 많다.
해당 변수가 어떤 데이터를 담고 있는지 찾기 위해 Ctrl 키와 함께 여러번 여행을 떠나 본 경험이 있다.

함수와 변수, 혹은 클래스에 대해 이름을 지을 때, 불명확한 이름은 피해야 한다.

# No,
data = 30
html(data)

# Yes,
timeout = 30
get_response_body(timeout)

🔔 이름을 명확히 짓기 위한 당신의 노력은 제3자의 수많은 수고를 덜어줄 수 있다.

1.2 함수는 짧게, 하나의 기능만

함수는 짧아야 한다. 그리고 하나의 기능만 수행해야 한다.

가끔씩 오픈소스를 수정해서 사용해야 하는 경우가 있다.
Github에서 한 함수가 300줄 정도인 코드를 본 적이 있는가? 하나의 함수를 이해하는데 30분이 걸렸다.
그렇다. 해당 함수에선 약 5가지 기능을 수행하고 있었다.

이렇게 길고 여러 기능을 수행하는 함수는 이해하기 쉽지 않을 뿐더러, 수정이나 확장이 쉽지 않다.
최대한 짧고, 간결하게 하나의 기능을 수행하도록 작성하자.

# No,
def get_ip_address(mac_address):
    # ...
    arp = {}
    arp["hardware_type"] = 0x0000
    # ...
 
# Yes,
def get_ip_address(mac_address):
    ip = send_arp(mac_address)
    return ip

🔔 파이썬 한 줄 코딩을 하라는 건 절대 아니다..!
오히려 가독성을 해쳐 이해를 힘들게 하는 경우도 있다.

1.3 Indent 깊이는 얕게

Indent 깊이는 되도록 얕게 개발하자.

불필요한 Indent는 우리에게 두가지 미션을 준다.

  • 첫번째는, 끝을 찾아야 하는 미션
  • 두번째는, 띄어쓰기 입력이라는 미션

함수가 짧거나 IDE가 Tab을 자동으로 스페이스바로 바꿔준다면 그나마 다행이다.
불필요한 Indent는 줄이자. 적어도 3개는 넘어가지 않도록 노력하자.

# No,
def is_pe_file(file_path):
    try:
        with open(file_path, "rb") as f:
            file_buffer = f.read()
            # ...
            if signature == 0x4550:
                # ...
 
# Yes,
@handle_open_error
def is_pe_file(file_path)
    file_buffer = read_file(file_path)
    # ...
    if signature != 0x4550:
        return False
    # ...
    return True
    

🔔 TIP 1. 함수로 나눠보기
🔔 TIP 2. 파이썬의 경우 데코레이터를 적극 활용

2. 검색이 쉬운 코드

2.1 통일된 용어 사용

조직, 문서 혹은 기존 소스 코드에서 사용하는 통일된 용어를 사용하자.

처음보는 소스 코드를 수정할 일이 있었다. 당황했다. 예상한 단어로 아무것도 검색되지 않았다. 결국 모든 소스를 일일히 찾아 변경해야 할 함수를 찾았던 경험이 있다. 그리고 수정하면서도 내가 수정하는 부분이 맞는지 계속해서 의심했었다.

만약 본인이 타인이 작성한 소스코드를 수정해야 한다면,
문서를 철저히 읽고 기존 소스에서 사용하는 용어들과 스타일을 비교하며 쭉 훑어보자.
훨씬 좋은 코드를 만들 수 있을 것이다.

# 😵
pid = 1
process_id = 1
processid = 1
open_file()
read_file()
root = Master()
admin = Master()
user = Slave()
client = Slave()

🔔 커피마시며 의사소통할 때까지 영향을 미친다.

2.2 줄임말 피하기

되도록이면 단어를 줄이지 말자.

검색이 힘들뿐만 아니라 이해도 힘들다.
본인은 제일 좋은 코드는 별도의 '문서가 필요없는 코드'라는 생각을 한 적이 있다.
이를 위해선 코드가 설명적이어야 하는데, 바로 줄임말 없는 단어가 그 역할을 해준다고 생각한다.

이름은 이름의 역할을 충분히 하도록 놔두자.

# No,
chkr = Checker()
mac = Addr()
ver = args.version
ver2 = args.verbose

# Yes,
file_format_checker = FileFormatChecker()
mac_address = MacAddress()
version = args.version
verbose = args.verbose

🔔 짧게 만들려고 줄여쓰다가 문서를 만들어야 하는 더 큰 수고가 필요할 수 있다.


해당 포스팅은 로버트 C. 마틴의 'Clean Code'에서 영향을 받아 작성되었습니다.

첫 Velog 포스팅 글을 읽어주셔서 감사합니다. 곧이어 2편으로 돌아오겠습니다 😃

profile
늘보의 개발생활

0개의 댓글