파이썬(PYTHON) 클린코드 #3_ 개발 지침 약어

안녕하세요. 문범우입니다.

이번 포스팅에서는 개발 분야에서 사용되는 약어(Abbreviations)에 대해서 알아보려 합니다.

물론, 파이썬이라는 언어에서만 해당되거나 염두에 두어야 할 내용이라기 보다는, 프로그래밍에 있어서 어떠한 언어를 사용하던 각 약어들을 염두해두고 프로그래밍을 한다면 보다 좋은 코드를 작성할 수 있고, 특정 상황과 코드에 보다 적합한 아이디어를 얻을 수 있을 것 입니다.

---

1. DRY / OAOO

DRY(Do not Repeat Yourself)와 OAOO(Once And Only Once)는 강조하고자 하는 의미가 비슷하므로 함께 다루어보자. 두개의 약어는, '중복을 피하라'라는 의미를 가지고 있다.

즉, 특정 기능과 역할을 하는 것은 코드에 단 한 곳에 정의되어 있어야 하고 중복되지 않아야 한다. 그리고 이를 통해 코드를 변경하고자 할 때 수정이 필요한 곳은 단 한 군데만 존재해야 한다.

코드의 중복이 발생한다는 건 유지보수를 하는데에 있어서 직접적인 영향을 미칠 수 있다는 것이다. 다양한 문제가 있을 수 있지만 축약해보면 다음과 같은 3가지 문제가 대표적이다.

- 오류가 발생하기 쉽다.

특정 계산 로직이 코드 전체 여러곳에 동일하게 분포되어 있을 때, 계산 로직에 대한 변경사항이 발생하면 코드의 모든 곳을 찾아 변경해주어야 하는데 이때 하나라도 빠뜨리면 오류가 발생하기 쉬워진다.

- 비용이 발생한다.

동일한 기능에 대한 반복 수정이 이루어져야 하기 때문에, 당연히 1회의 수정보다 다수의 수정에 있어서 비용적으로 손해가 발생한다.

- 신뢰성이 떨어진다.

동일한 기능이 코드 여러 곳에 분포되어 있을 때, 모든 곳을 찾아서 수정해야 한다. 물론 언어적 기능과 도구의 도움을 받을 수도 있지만, 모든 곳을 정확히 기억하지 못할 수 있다는 점 때문에 시스템 전체의 신뢰성이 보다 떨어질 수 있다.

간단하게 나마 코드의 중복이 발생할 수 있는 예시와 적절히 조치 된 예시를 살펴보자.

#-*- coding:utf-8 -*-
# DRY / OAOO
 
user_math_score_dic = {
    'A': 90,
    'B': 93,
    'C': 30,
    'D': 100,
    'E': 31,
    'F': 82,
    'G': 79,
}
 
user_eng_score_dic = {
    'A': 30,
    'B': 63,
    'C': 39,
    'D': 94,
    'E': 10,
    'F': 49,
    'G': 68,
}
 
# Danger code
def get_user_score_list(user_math_score_dic, user_eng_score_dic):
    """
    input: 유저의 이름을 key로, 점수를 value로 가지는 dict형 자료형 2개
    output: 종합 점수 계산에 따라 내림차순으로 정렬한 유저의 이름 list
    """
    
    user_sum_score_dic = {}
    # 종합 점수 계산 (math*2 + eng)
    for k, math_score in user_math_score_dic.items():
        sum_score = math_score*2
        sum_score += user_eng_score_dic[k]
        user_sum_score_dic[k] = sum_score
 
    # 종합 점수에 따라 내림차순 정렬
    sorted_user = sorted(user_sum_score_dic.keys(), key=lambda x: user_sum_score_dic[x])
    return sorted_user
 
print("# Danger code")
print(get_user_score_list(user_math_score_dic, user_eng_score_dic))
 
 
# Good code
def calc_user_sum_score(user_math_score_dic, user_eng_score_dic):
    """
    input: 유저의 이름을 key로, 점수를 value로 가지는 dict형 자료형 2개
    output: 종합 점수 계산이 된 dict 자료형
    """
    user_sum_score_dic = {}
    # 종합 점수 계산 (math*2 + eng)
    for k, math_score in user_math_score_dic.items():
        sum_score = math_score*2
        sum_score += user_eng_score_dic[k]
        user_sum_score_dic[k] = sum_score
    return user_sum_score_dic
 
def get_user_score_list2(user_math_score_dic, user_eng_score_dic):
    """
    input: 유저의 이름을 key로, 점수를 value로 가지는 dict형 자료형 2개
    output: 종합 점수 계산에 따라 내림차순으로 정렬한 유저의 이름 list
    """
    user_sum_score_dic = calc_user_sum_score(user_math_score_dic, user_eng_score_dic)
 
    # 종합 점수에 따라 내림차순 정렬
    sorted_user = sorted(user_sum_score_dic.keys(), key=lambda x: user_sum_score_dic[x])
    return sorted_user
 
print("# Good code")
print(get_user_score_list(user_math_score_dic, user_eng_score_dic))
 

위의 코드를 보면 기존에 정의된 get_user_score_list함수에서는 내부적으로 종합 점수에 대한 계산이 진행되고 있다. 만약 그러한 계산 로직이 다른 곳에서도 필요하면 어떻게 될까? 따로 함수화가 되어 있지 않기 때문에 동일 로직을 중복시켜야 한다. 하지만 아래와 같이 calc_user_sum_score라는 함수를 분리해두면, 추후 동일 로직이 필요할 때 해당 함수를 이용할 수 있을 것이다.

2. YAGNI / KIS

YAGNI( You Aren't Gonna Need It)와 KIS(Keep It Simple) 또한 의미하는 바가 비슷하므로 함께 다루도록 하자. 두 약어가 의미하는 것은 '현재 주어진 문제에 적합한, 간단한 코드를 작성하라'이다.

YAGNI에서 보다 강조하는 것은, 과잉된 프로그래밍을 하지 말라는 것이다. 우리는 결론적으로 시스템에 대한 확장성과 유지보수 등을 위해 보다 좋은 코드를 작성하려고 한다. 하지만 그 목표가 코드를 작성하는 시점에 특정 미래적 상황을 예측해야 한다는 것은 아니다. 필자가 참고하고 있는 서적에서는 이렇게 이야기 한다.

유지보수가 가능한 소프트웨어를 만드는 것은 미래의 요구 사항을 예측하는 것이 아니다.

- 파이썬 클린 코드

위에서의 말대로, 우리가 확장성과 유지보수 등을 위한 소프트웨어를 만들어야 한다는 것은, 다가오지 않은 미래에 대해 특정 상황을 예측해야 한다는 것은 아니다. 오히려 그랬다면 코드적인 학습보다, 미래학자와 같은 학습을 해야하지 않을까 싶다. 

따라서, 프로그래밍 시점에서는 현재의 요구사항을 잘 해결하기 위한 소프트웨어를 작성하되, 이때에 보다 수정가능하고, 높은 응집도와 낮은 결합력을 가지는 프로그래밍을 해야한다. 미래에 ~이 필요할거야, 나중에 ~가 고려되지 않을까, 라는 생각에 현재의 요구사항을 넘어서는, 과잉 프로그래밍을 하면 안된다.

KIS에서 조금 더 강조하는 점은 현재에 선택한 솔루션이 최선의, 최소한의 솔루션이어야 한다는 것이다. 문제를 해결하는데에 있어서 화려하고 어려운 기술은 필수요소가 아니다. 항상 보다 간결하고 최소한의 솔루션으로 문제를 해결해야 한다.

단순하게 해결될 수 있는 문제를 보다 복잡하게 해결하게 되면 추후 해당하는 함수, 클래스, 데이터에 대한 수정에 있어 더 큰 어려움이 내포될 수 있다.

더군다나, 파이썬의 철학에서는 '단순한 것이 복잡한 것보다 낫다.' 라고 이야기 하고 있다.

3. EAFP / LBYL

EAFP(Easier to Ask Forgiveness than Permission)와 LBYL(Look Before You Leap)는 상대적인 의미를 지니고 있는 약어이다.

우선 EAFP는 허락보다 용서를 구하는 것이 쉽다는 말인데 이 의미는 일단 코드가 실행되도록 두고 동작하지 않을 경우를 대응한다는 의미이다. 일반적으로는 코드가 실행되도로 하고 발생할 수 있는 에러에 대해서 catch, except문을 이용해 조치하는 코드를 의미한다.

이에 반해 LBYL은 도약하기 전에 살피라는 말이며, 의미적으로는 코드가 실행되기 이전에 확인/검토를 하라는 의미이다. 간단하게는 if문 등을 이용한 체크 정도로 생각하면 된다.

아래 코드는 파일을 사용하기 이전에 LBYL에 따른 코드와, EAFP에 따른 코드를 나타내고 있다.

# LBYL
if os.path.exists(filename):
    with open(filename) as f:
        ...
        
 
# EAFP
try:
    with open(filename) as f:
        ...
        
except FileNotFoundError as e:
    logger.error(e)
    ...
 

---