July 11, 2022
이 글은 좋은 코드에 대해 고민하는 글이며 jbee님 블로그 글을 읽고 고민한 내용과 함께 재구성한 글입니다.
좋은 코드는 가독성 좋은 코드, 테스트하기 좋은 코드, 중복 없는 코드 등 주관적인 의견을 내세웁니다. 이 글에서는 이에 대해 고민합니다.
가독성이 좋은 코드가 좋은 코드일까요?
함께 개발하기 위해서는 내 코드가 잘 읽혀야 팀원이 문제없이 내 코드를 만질 수 있습니다. 팀원 없이 혼자 개발하면 가독성이 필요 없을까요? 아닙니다. “미래의 나”와 “현재의 나”도 함께 개발하고 있습니다. 가독성이 나쁜 코드는 미래의 내가 해석하기 힘듭니다. 따라서 가독성이 좋은 코드는 최소한 현재의 팀원과 미래의 나에게 도움을 줍니다.
가독성을 높이려면?
작성자에게 익숙한 언어를 사용한다면 읽기 쉬운 코드를 작성할 수 있습니다. 따라서 주석을 작성하는 것이 가독성에 도움이 될 수 있습니다. 하지만 주석은 관리하기 어렵습니다. 주석은 기본적으로 메타데이터이기 때문에 함수의 실제 동작과 일치하는 것을 보장할 수 없습니다.
필자는 평소에 주석을 작성하면 코드와 주석을 둘 다 읽게 되는 경우가 많았습니다. 코드를 읽기 좋게 만들고 주석을 최소화하는 것을 지향하고 있습니다. 이를 위해 코딩 컨벤션을 많이 정해두고 코드를 작성합니다. “컨벤션을 숙지한다면” 읽기 수월해지는 것이 목적입니다.
테스트에 용이한 코드가 좋은 코드일까요?
필자는 테스트에 용이한 코드를 선호합니다. 테스트에 용이하다는 의미는 함수에 필요한 변수와 함수의 반환값을 명확히 설명할 수 있고 각 테스트가 독립적인 것이기 때문입니다. 테스트에 용이해지면 자연스럽게 가독성이 좋아지고 유지보수에 용이해집니다. 또한 테스트 코드가 존재한다면 코드 수정의 자신감도 상승하게 됩니다.
테스트에 용이해 지려면?
관심사 분리를 노력해야 합니다. 객체지향 원칙을 지키며 객체 간 영향을 줄이는 것이 한 방법이 되겠죠. 함수의 기능이 명확해야 하고 순수해야하며 …
중복이 없는 코드가 좋은 코드일까요?
개발자는 본능적으로 중복코드를 없애고 싶어합니다. 유사한 기능을 새로 개발할 때 노력이 줄어들며 중복된 코드를 수정할 때에도 적은 노력으로 변경할 수 있습니다. 하지만 오히려 여기저기서 사용하고 있는 코드라면 수정하기 부담스러울 수 있습니다.
제가 생각하는 여러 좋은 코드에 대해 작성해 봤습니다. jbee님 블로그에는 좋지 않은 코드의 생산 원인과 더불어 추가적인 고민을 합니다. 제 글에서는 흔히들 당연히 여길 수 있는 가독성이 좋은 코드, 테스트하기 좋은 코드, 중복없는 코드가 좋은 코드라는 사실에 대해 고민했습니다. 저는 테스트하기 좋은 구조로 작성하는 방법을 고민하며 유지보수에 대한 고민, 가독성에 대한 고민, 코드 중복에 대한 고민을 모두 할 수 있었습니다. 좋은 코드의 요소들은 독립적인 것이 아니라 서로가 얽혀있으며 핵심은 “혼자 + 한번에” 개발하는 앱이 없다는 것입니다. 언젠가 기술이 발전해 카카오톡 같은 앱 정도는 5분이면 혼자 만들고, 유지보수 할 필요 없이 완벽할 수 있다면 빨리 만들 수 있는 짧은 코드가 좋은코드가 아닐까요?