면접을 준비하다 개발 자체에 대한 고민이 생겼습니다.
도대체 개발이 뭐지? 좋은 코드가 뭐지? 라는 식의 의문이 많이 들었습니다.
그래서 이를 해소해야만 다음 스텝으로 넘어갈 수 있을 것 같아 이번 포스팅에선 개발자들의 일반 상식에 대해서 알아보도록 하겠습니다.
좋은 코드란?
이 말은 개발 이전, 스타트업 현직자 인터뷰를 다닌 시절부터 시작하게 됩니다. 현직 개발자, CTO님을 만나 이야기 나누며 계속해서 들었던 말이기도 합니다.
그들이 말했던 좋은 코드란 무엇이고, 어떤 환경이 좋은 환경일까요? 좋은 코드란 말은 유니콘 처럼 지금 여러 곳에서 들려오고 이습니다. 모두가 말하는 좋은 코드의 기준이 다르고, 경험에 따라 또는 프로젝트에 따라 달라지기도 합니다. 그러니 세상에서 말하는 좋은 코드에 대한 기준은 너무나도 많습니다.
그렇다면 명확한 기준이 세워져 있다면 좋은 코드라고도 생각할 수 있겠네요!
- 가독성이 좋은 코드
- 중복이 없는 코드...
이런 코드가 좋은 코드라고 말하곤 합니다.
특히 1번 같이 가독성이 좋은 코드는 책까지 나올 정도로 수 많은 관심이 쏠려 있습니다. 제가 처음에 개발을 시작할때만 하더라도 이 말이 뭔가 했습니다.
읽기 좋은 코드
"읽기 좋으려면 주석으로 어떤 기능을 하는지 모두 달아두면 되겠네?"
이런식으로 생각했습니다. 아주 건방진 생각일 수도 있겠지만, 가독성이라는 문제 해결을 위해선 가장 간편한 방법이 아닌가 싶었거든요!
아무튼 이렇게 주석을 달아두게 된다면 관리가 어렵다는 사실을 프로젝트를 진행하며 알게 됐습니다. 결국 메타데이터다 보니까 언제 작성된 것인지 파악하기도 어렵고, 누군가가 수정하거나 기능을 바꿔두고 깜빡하고 글을 바꾸지 않았을 수 도 있으니까요!
그리고 실제 함수가 작동하는 방식과는 다르게 주석이 적혀있을 수 도 있기 때문에, 오히려 잘못된 주석으로 인해 뜻을 이해하기 어려워질 수 있습니다.
읽기 쉽다고 끝은 아니다
그럼 코드의 가독성을 챙긴다면 괜찮을까요? 물론 이런 이분법적 사고는 좋지 못합니다. 읽기 쉽다는 것은 코드를 이해하는 것을 포함합니다. 어떤 방식으로 작동하는지 이해할 수 있다면 협업 시에도 다른 사람들이 작업을 이어가기 간편합니다.
즉 읽기 쉽다면 협업에 용이하기에 좋은 코드라고 말할 수 있습니다.
중복이 없는 코드
단순 반복을 최소화 하는 것도 중요합니다. 서로 다른 두 함수가 같은 로직을 수행한다면 에러가 발생했을때, 두 함수를 모두 건드려야합니다.
해당 로직을 추출해서 각각 함수에 주입하기만 해준다면, 에러가 발생해도 함수를 건드리지 않고 추출하는 로직만 수정하면 관련 로직을 사용하는 모든 함수를 컨트롤 할 수 있습니다.
그렇다면 이런 사실을 알고 있음에도 불구하고, 어째서 좋지 못한 코드가 생산되는 걸까요?
제 프로젝트 경험으로 이해해봤을 땐, 급급하게 문제를 해결하려거나 한 코드를 오래 붙잡고 있을때 안 좋은 코드를 작성 한 것 같습니다.
응급처치를 한 코드
중복으로 빼뒀지만 사용하는 곳에서 다른 로직을 추가해줘야 할 때를 종종 마주합니다. 이 때 수정으로 인한 Side effect가 두려워 함수에 입력을 추가하던가 옵션 값을 추가하여 내부에서 억지로 틀어막은코드가 됩니다.
이렇게 응급처치가 몇 번 이뤄지면 누구도 알아보기 어려운 함수가 탄생합니다.
기술에 대한 무지
응급처치가 무조건 나쁘다는 말이 아닙니다. 당장 문제 해결을 하는 데에 이만큼 빠른 대응이 없습니다. 특히 기한이 정해져있는 프로젝트 같은 경우에는 더욱이나 말이죠. 다만 이런 응급처치한 코드들은 언젠가 더 큰 리스크로 돌아옵니다.
마찬가지로 잠시 기술에 대해 명확히 알지 못한 체로 문제 해결하려 한다면, 코드를 유지보수 하는데 더 큰 비용이 들어가기 때문에 적정선을 찾는 것 또한 중요합니다.
좋은 코드에 대해서 알아봤으니 다음엔 현대에서 중요시하게 여겨지는 패러다임에 대해서 알아보도록 합시다.
