본문으로 건너뛰기

Clean Code

· 약 10분
안태찬 (return)

안녕하세요 스팍스에서 활동하고 있는 안태찬입니다. 벌써 전산학부 수업을 들은지도 햇수로 3년 정도가 되지만 아직도 코딩과는 별로 친하지 않은 것 같습니다 ㅎㅎ

한때 전산학부, 또는 그 범주의 컴퓨터 공학부를 졸업한 학생들은 무엇을 배웠고, 어떤 능력을 키워야 하는가 고민을 많이 해봤고 저는 우리들이 전산학부를 졸업한다면 크게 2가지를 배우게 된다고 생각했습니다.

  • 첫번째는 컴퓨터 시스템이 돌아가는 원리를 이해하는 것입니다.
  • 두번째는 컴퓨터를 통해서 문제를 해결하는 능력, 즉 어떤 현실의 문제를 정의하고 이를 프로그래밍 할 수 있는 능력이 생기는 것입니다.

학교 수업에서는 시스템, AI 등 다양한 전산의 분야를 기초부터 배울 수 있었고 저도 학교 수업을 들으면서 위에서 말한 첫번째 내용을 배울 수 있었어서 좋았습니다.

하지만 저는 첫번째만큼이나 두번째 역시 매우 중요하게 배워야 할 교육과정이라고 생각합니다. 특히 두번째에서 문제를 잘 정의하고 이를 해결할 수 있는 방법을 제안하고 프로그래밍하는 방법에 있어서는 사람마다 자신이 원하는 스타일대로 코딩하기 때문에 그 스타일도 다양합니다. 100명의 개발자에게의 같은 기능을 하는 하나의 프로그램을 짜오라고 한다면 각기 다른 100개의 코드로 짜여진 프로그램이 완성될 것입니다.

전산학부 수업을 들으면서 과제가 나오면 코드를 깔끔하게 잘 짜고 싶었습니다. 하지만 밀려오는 시간의 압박과 과제의 난이도 때문에 항상 과제를 시간 내에 제출하기에도 벅찼고 항상 완주하는 것에 만족해야 했기에 아쉬움이 있었습니다.

어떻게 하면 코딩을 잘 짜는지, 또는 잘 쓴 코드와 그렇지 않은 코드에는 어떤 차이점이 있는지, 어떻게 하면 코딩을 훨씬 효율적으로 할 수 있을까라는 생각이 많이 들었고, 우리가 좋은 글을 작성하는 방법을 배우듯이 좋은 코드를 작성하는 방법에 대해 최소한의 기준을 알고 싶었습니다.

그러던 중 몰입캠프를 하면서 같이 했던 타 대학교 형의 소개로 "Clean Code"라는 책을 알게 되었고, 제가 평소에 코딩을 하면서 어떻게 좋은 코드일까에 대한 모호했던 기준을 정확하게 세울 수 있었습니다.

아래에는 제가 책을 읽으면서 느꼈던 좋은 코드의 기준을 몇 가지 적어봤습니다.

좋은 코드란?


개발자로 회사에 들어가서 취업을 한다면 혼자 코딩을 하는 것과 다른 점이 있습니다.

  • 같은 일을 더 적은 시간 안에 처리할수록 좋다(효율),
  • 현실의 문제는 학부 수업에서 다루는 과제보다 훨씬 복잡하고 어렵기 때문에 이를 해결하기 위한 코드의 양도 많고 복잡하다. 그래서 문제를 해결하기 위해 여러 명의 개발자들이 협업한다.

위의 관점에서 생각해볼 때 제가 생각하는 좋은 코드는 아래와 같습니다.

  • 같은 기능을 수행할 때 더 짧고 간단한 코드
  • 3자가 읽기 쉽고 고치기 쉬운 코드

의미있는 이름


  • 의도를 분명히 밝히기
    변수명을 지을 때 a, b 이렇게 짓는 것보다 그 변수가 담고 있는 의미를 나타내는 적절한 이름을 붙여줄 때 코드를 이해하기 훨씬 쉬울 것입니다.

  • 의미있게 구분하기
    data, information 등 의미가 모호할 수 있는, 널리 쓰이는 단어(불용어)는 변수명으로 지양합니다.

  • 검색하기 쉬운 단어를 사용하기
    단어의 길이가 길더라도 의미를 명확하게 전달할 수 있다면 긴 단어가 짧은 단어보다 좋습니다.
    코드에서 상수를 사용하는 것보다 반드시 변수에 저장하고 적절한 이름을 붙여줍니다.

  • 일반적으로 통용되는 변수명의 규칙
    클래스 이름은 명사, 메소드 이름은 동사를 사용합니다.
    get, set, is를 사용합니다. camelCase 문법 또는 경우에 따라 _를 사용하고, 전체 코드를 통일합니다.

함수


프로그래밍을 하는 것은 함수를 짜는 것과 같습니다. 그렇다면 기능을 구현하기 위해서 함수를 몇 개까지 만들고, 이를 어떻게 구별하면 좋을까요?
이 책에서 말하고자 하는 함수에 관한 가장 중요한 규칙은 "하나의 함수는 하나의 일만 수행해야 한다" 입니다.

  • 단일책임원칙(SRP, single responsible principle) 하나의 함수는 반드시 하나의 기능을 수행해야 합니다. 특정 기능에 문제가 생겼을 때 우리는 해당 함수만 고치면 됩니다.

  • 함수의 인수
    함수의 인수는 0개, 1개, 2개 순으로 적을수록 좋습니다. 3개 이상은 지양합니다. 3개 이상이면 독자적인 클래스를 생성하는 것도 고려해보면 좋습니다.
    함수의 인수로 boolean 타입은 피합니다.
    아무래도 함수의 인수가 적을수록 해당 함수의 input을 파악하는 데 시간이 적게 걸리다보니 빠르게 코드가 읽혀집니다. boolean 타입의 경우, 참, 거짓에 따라 다른 기능을 수행하기 때문에 지양하는 것이 좋습니다.

  • 명령과 조회 분리하기
    함수는 무언가를 조회하거나, 명령하는 것 둘 중 한가지만 수행해야 합니다.

  • 함수 형식
    함수 안의 줄 수는 작을 수록 좋으며, 들여쓰기 레벨로 최대 2단 정도까지 있는 것이 바람직합니다.

주석


주석은 가능한 안 쓰는게 좋습니다. 주석이 없이도 제 3자가 알아보기 쉽도록 깔끔하게 코드를 적는 것이 더 중요합니다.

좋은 주석

  • 코드로 표현하지 못하는 정보를 제공하는 주석
  • 의도를 설명하는 주석
  • 결과를 경고하는 주석
  • 중요성을 강조하는 주석

나쁜 주석

  • 코드로 설명할 수 있는데, 코드를 설명하는 주석
  • 주석으로 처리한 코드
    특히 코드를 작성하는 과정에서 주석으로 처리한 코드를 지우지 않는 경우가 많은데, 이 경우에 주의합니다.
  • 이력을 기록하는 주석

이외에도...


이외에도 visual studio code 에디터를 사용한다면 clean code를 위해서 아래의 extension을 추천합니다.

  • Code prettier
  • ESLint

코드의 형태와 문법적 오류를 자동으로 잡아주는 extension으로 clean code 작성에 유용할 것입니다.

읽어주셔서 감사합니다!