모든 개발자는 당연히 좋은 코드를 작성하고 싶어 할 것이다. 나 또한 좋은 코드를 작성하기 위해 여러가지를 찾아보고 생각해보았다. 그동안 했던 생각과 고민들을 정리해보고자 한다. 분명 좋은 코드의 정의는 어떤 프로그램을 누가 어떻게 만드는지에 따라 달라질 것이다. 그렇다면 내가 생각했을 때 좋은 코드란 무엇일까?
좋은 코드란?
모두에게 '좋은 코드'의 기준이 조금씩 다르고 정의도 다른 것 같다. 세간에서 이야기 하는 좋은 코드란 무엇일까?
- 가독성 좋은 코드
- 중복 없는 코드
- 테스트에 용이한 코드
등등 모두 맞는 말이다.
가독성 좋은 코드
한번만 코드를 짜고 다시는 보지 않을 거라면 사실 가독성은 크게 중요하지 않다. 하지만 현실은 그렇지 않다. 셀 수도 없이 많은 오류는 물론 유지보수를 해야하기 때문에 코드는 언제 누가 봐도 이해하기 쉽도록 간결하고 가독성이 좋은 코드가 좋다.
가독성에는 두가지 종류가 있다.
- 표현적 가독성 (Legibility)
- 눈에 잘들어오고 읽기 편한 코드 - 기능적 가독성 (Raedability)
-함수,변수,클래스 등이 어떤 역할을 가지고 어떤 동작을 하며 어떤 관계를 맺고 있는지 직관적으로 파악 가능한 코드
주석을 많이 사용하는 것은 좋은 것일까?
단순하게 생각해서 이해하기 쉽게 만들기 위해 기능들 마다 주석을 달아두면 좋지 않을까?
분명 주석을 다는 것은 좋은 습관이다. 하지만 주석을 사용할 때 주의해야할 점이 있다.
- 주석은 관리하기 어렵다.
- 주석은 메타데이터이기에 주석의 내용이 함수의 실제 동작과 일치한다고 맹신할 수 없다.
- 수시로 변하는 코드에 맞춰 잘못 수정 될 수 있다.
- 나한테만 쉬운 주석
- 각자 다른 환경에서 코드를 작성하고 이해하기 때문에 주석에도 한계가 존재한다.
관리가 잘 안되는 만큼 정말 필요한 부분에만 최소한으로 사용해야한다.
하지만 이해할 수 없는 코드보단 주석이 많이 달린 코드가 낫다.
중복이 없는 코드
많이들 중복 코드가 나쁘다고 말한다. 하지만 중복은 자주 일어난다. 중복을 같은 기능을 하는 여러줄의 코드로 재사용 가능하게 만드는 것이 중요하다. 물론 무조건 중복이 나쁘다는 것은 아니다.
- 무조건 중복을 피하기 위해 같은 함수를 남발하다간 오류가 생길 수 있다.
- 처음에는 같은 기능을 하는 A함수를 써도 나중에는 조금 다른 역할로의 수정이 필요해지면 오류가 날 수 있다.
테스트에 용이한 코드
테스트 코드는 중요하다. 테스트를 통해 심리적 안정감도 생기고 자신감도 생긴다. 처음에 프로그램을 설계 할 때 부터 테스트 가능성을 열어두고 코드를 서로 연결하기 전에 코드를 하나하나 테스트 해야 한다.
일관성 있는 코드
최소한의 가독성을 보장하는 방법 중 하나로 일관성을 유지하며 코드를 짜는 것이다. 여기서 일관성은 합의된 규칙을 기반으로 만들어지며 합의된 규칙은 개개인에게 동일하게 이해돼야 한다. 만약 코드의 일관성이 유지된다면 예측이 가능해진다.
- 네이밍(Naming)
- 변수명이나 함수명 등 작명을 할 때 규칙이 있으면 좋다. - 디렉터리 (Directory)
- 어디에 분리할지 규칙이 있으면 좋다.
- 아키텍처와 같은 것이 아니다.
- 페이지마다 디렉터리를 분리하면 좋다.
확장성이 좋은 코드
확장이 어려운 코드는 내부에서 많은 변경이 발생하며 이것은 코드를 읽기 어렵게 만들어 자연스럽게 생산성이 떨어진다. 확장에 너무 많이 열려있으면 내부 API를 수정하기 어려워지는 문제도 발생할 수 있다. 라이브러리의 경우 확장성이 높으면 많은 use-case를 대응할 수 있겠지만 내부적으로 큰 변화가 있을 때, Breaking Change가 생길 가능성이 높아진다. 이 또한 적정선을 찾아가는 것이 무엇보다 중요하다.
결론
코딩은 글쓰기 같다. 어떻게든 목적 달성만 하면 되지만 고치고 다듬어 가면서 완벽해진다. 초고에 배부를 수 없다.
"무엇이 좋은 코드인가?"에 대한 정답은 없다. 내가 생각하는 좋은 코드를 위해 항상 생각하며 코드를 작성하자.
