클린코드란 무엇일까?
누군가에게 "좋은 코드가 무엇이냐?"물어본다면, 프로그래밍을 모르는 사람은 그저 "문제없이 잘 돌아가는 코드"라고 말 할 수도 있고, 아는사람이라면 "깔끔하게 다른사람들도 알아볼 수 있고, 코드를 처음 보는 사람도 동작을 직관적으로 파악할 수 있도록 작성된 코드"라고 답할 수도 있을 것이다.
"클린코드"라는 용어는 2008년에 출간된 로버트 C. 마틴(Robert C. Martin)이 저술한 동명의 책 "Clean Code: A Handbook of Agile Software Craftsmanship"에서 처음 등장했다.
이 책은 SW 개발자들에게 좋은 코드 작성 습관과 원칙을 가르치는데 중점을 둔 책으로 코드의 가독성과 유지보수성을 높이기 위한 다양한 원칙과 예제를 제시하고, 개발자들이 더 나은 코드를 작성하는 데 도움을 주는 지침서로서 평가받고있다.
왜 클린코드를 유념하며 코딩해야할까?
코드작성도 서비스도 모두 1인으로 혼자 모든걸 다 기억하고 작성할 수 있다면, 굳이 클린코드를 사용할 필요는 없을 것이다. 하지만 사람이라면 본인이 작성했더라도 잊어버릴 수 있고, 이 서비스를 운영하다 3개월, 6개월, 1년이 지나 갑자기 해당 부분을 수정할 필요가 생겼을때 이해하지 못하면, 결국 다시 코드를 짜게 되는 인력난 시간낭비 등이 발생한다.
다른사람과 같이 일할 때는 더더욱 중요해진다. 본인만 알아 볼 수 있는 코드로 로직을 짜게 되면 당연히 업무에 지장이 생길 것이다.
IT서비스는 점점 방대해지고 코드의 양은 늘어나는데 기억해할 내용은 많고 인간의 뇌 활용량은 한정적이다. 이러한 상황에서 작성자에게 물어볼 필요도 없이 한 눈에 봐도 당연하게 이해되고 각자가 맡은 파트에 대해 집중할 수 있다면 시간적으로도 정신적으로 효율적으로 프로그래밍을 해나갈 수 있을 것이다.
어떠한 항목을 주의해야 할까?
그렇다면 우리는 어떠한 항목들을 주의해 가며 코드를 짜야 Clean Code를 생각할 수 있을까?
Clean Code를 검색해보면 Clean code를 위한 여러가지 작성방법 및 주의점들을 볼 수 있다. 함수나 클래스의 작명, URL의 작성법, 캡슐화, 단일책임의원칙, DRY, 함수의 인수개수 등 명확하게 "딱 이렇게만 하면된다."라고 적혀있지 않고 각자의 생각이나 착안점 등이 추가된 경우가 굉장히 많다. 어떠한 포스팅에서는 클린코드를 위한 설계적인 원칙으로 OOP의 SOLID원칙을 내세우는 경우도 있다.
따라서 간략하게 몇가지만 적어보자
-
네이밍
✨여러가지 네이밍 규칙들을 클래스, 함수, 변수, DB, 컬럼 등에 맞게 Camel, Pacal, kebab, snake를 따져서 작성하자.
✨함수명은 동사, URL은 복수명사, 변수는 들어가는 인자의 개수에 따라서 단,복수명사를 정확하게 적자. -
주석
✨왠만하면 주석이 필요없이 이해할 수 있도록 작성하고, 정말 필요할 경우에만 주석을 추가해 세부설명을 하자.
✨주석을 명확하고 간결하게 작성하고, 주석을 통해 코드의 복잡성을 가리키는 대신 코드 구조를 개선하도록하자. -
함수의 인수
✨ 함수에 전달되는 인수는 적을수록 좋다. 많아도 3개 까지만 작성하고 3개는 넘어간다면 하나의 객체로 묶어서 전달할 수 있도록 하자. -
함수의 길이
✨함수의 길이 또한 작을수록 좋다. 함수의 이름을 구분짓기 위해서 길게 쓰다보면, 함수자체를 이해하기 어려워 질 수 있고, 오탈자 등의 문제로 인한 오류가 발생할 수 있다. -
중복제거
✨중복 코드는 버그와 유지보수의 어려움의 원인이 될 수 있다. DRY원칙과 같이 Don't Repeat Yourself 반복하지 말고 시스템 내 로직은 단 한곳에서 명확하고 신뢰할 수 있도록 작성하자. -
조건문의 간소화
✨if조건의 뎁스를 줄이자. 조건의 조건의 조건이 생긴다면, 분명 줄일 수 있는 구석이 있을 것이다. 조건문의 뎁스는 많아질 수록 가독성을 해칠 수 있다. -
작은 함수
✨단일책임의 원칙과 같이 함수는 작고 명료하게 하나의 동작만 할 수 있도록 해야한다. 함수는 한가지 작업만을 수행하며, 그 작업을 잘 추상화하여 의도가 분명한 이름을 부여하자. -
단순하게 작성하자.
✨KISS(Keep It Simple, Stupid)와 같이 단순하게 작성해야 한다. 만약 가독성을 위해서 어렵고 복잡한 기술을 사용해서 10줄로 작성했다고 하자. 이 코드를 이해하고 읽는데 걸리는 시간은 해당코드를 풀어서 30줄에 작성한 코드보다 오래걸릴 것이다. -
필요없는 기능은 만들지말자.(YAGNI)
✨"나중에 필요할 것 같다."와 같은 지금은 필요없는 기능을 미래지향적으로 만들어 둠에 따라서, 코드의 가도성을 헤치고 복잡성만 들어나며, 괜한 개발비용이 발생할 수 있다. 지금 필요하고 사용하지 않는 기능에 대해서는 굳이 지금 만들어두지 말자. You Ain't Gonna Need It
