성숙한 개발자가 알아야하는 4가지 코딩 규칙
내가(저자) 코딩을 시작할 때, 스스로에게 말했다.
- 개발자가 되려면 넌 천재가 되어야해
- 너는 코딩을 매일 매일 해야해.
- 너는 혁신적인 프로젝트를 하게 될거야.
- 코딩은 재밌어
하지만 시간이 흐른 후 다 거짓말이라는 것을 깨달았다.
젊은 개발자로서 복잡한 소프트웨어 개발을 경험하는 것은 도전적이고 그것이 우리 개발자들이 집착하는 이유이다.
여기 4개의 실상을 보여주겠다.
코드를 라이브러리로 끄집어내지 마라.
많은 글들에서 개발자들에게 반복하지 말라고 하기 때문에 개발자들은 라이브러리로 만드는 것에 집착한다.
하지만 그러면 의존성이 증가하고 유지보수하는데 많은 시간을 허비할 것이다.
언제 사용할지 모르는 라이브러리라면 만들지 마라.
의미를 담은 이름 사용(Using the domain language)
내가 막 개발을 하기 시작했을 때는 잘 몰라서,
도서관리 프로그램을 만들 때 add_book
, find_book_by_title
and list_all_books
같은 함수 이름 대신 평범한 이름을 사용했고 이름을 그렇게 짓는 것은 시간 낭비라고 생각했다.
그래도 아무 문제 없었다. 하지만 버그를 수정하면서 나는 문제를 깨달았다.
예를 들어 나는 이런 식으로 함수를 선언했다.
def calculate(a, b):
이러면 코드의 의미를 해석하기 위해 전체 코드를 다 봐야한다. 실제로 나는 의미를 추적하기 위해 펜과 종이를 사용해야 했다.
대신 이렇게 작성했다면 이해하기 쉬웠을 것이다.
def calculate_sum_and_average(first_number, second_number):
함수 작성에 한단계 추상화만 사용해라
다른 개발자의 코드를 볼 때 마다 몇몇 개발자들이 한단계 추상화를 사용하지 않는 문제를 본다.
이런 코드를 예로 들면
#Function to calculate area
def calculate_rectangle_area(length, width):
return length * width
# Function to ask the user for dimensions
def get_and_calculate_rectangle_area():
length = float(input("Enter the length of the rectangle: "))
width = float(input("Enter the width of the rectangle: "))
area = calculate_rectangle_area(length, width)
print(f"The area of the rectangle is: {area}")
def main():
print("Welcome to the Rectangle Area Calculator")
get_and_calculate_rectangle_area()
get_and_calculate_rectangle_area
함수는 입력도 받고 계산도 한다.
이러면 코드가 복잡해진다.
대신 이렇게 하면 main 함수가 전체 흐름을 관장하고 get_and_calculate_rectangle_area
는 한가지 일만 해서 추상화 단계가 낮아진다.
def main():
print("Welcome to the Rectangle Area Calculator")
length = float(input("Enter the length of the rectangle: "))
width = float(input("Enter the width of the rectangle: "))
area = calculate_rectangle_area(length, width)
print(f"The area of the rectangle is: {area}")
프로그래밍에 정해진 답은 없다
라이브러리로 만들지 말라고 했는데 단순화하라고 하면 상충되는 소리라고 생각할 수 있을 것이다.
첫번째는 코드를 라이브러리로 빼지 말고 프로젝트에 두라는 말이고, 함수를 작게 한가지 일만 하게 하라는 말이다.
절대 라이브러리를 만들지 말라는 말이 아니다. 라이브러리로 만들거면 그 코드가 현재 프로젝트만을 위한 코드가 아니라고 확신해야 한다.
만약 라이브러리로 만들어서 유지보수가 더 쉬워진다면 그렇게 하면 되는 것이다.
프로그래밍은 변화의 연속이다. 새로운 프레임워크, 방법 들이 계속해서 나오고 있다.
최선이라고 생각한 방법이 다른 문제에서는 최악일 수도 있다.
따라서 어떤 방법이 고객의 요구에 맞는지 생각해야한다. 여러 방법을 동원해야 해결되는 문제도 있을 것이다.