짧고 한 줄로 간략하게 정말 어려운 문제를 푸는 코드가 과연 좋은 코드일까? 복잡하게 멋진 디자인 테크닉을 사용해서 설계한 구성 요소가 많은 건 과연 좋은 코드일까? 때에 따라 다르지만 무조건 남들이 봤을 때 '똑똑한' 코드는 실무에서 '배포하기 적합한 상태의 코드'이지 않을 수도 있다. 실제 리트코드 코딩 테스트 문제를 풀면, 많은 개발자가 한 줄로 문제를 풀 수 있는 많은 트릭을 사용해서 공유한다. 과연 이런 솔루션이 실무에도 도움 되는 코드일까? 1️⃣ 코드 가독성이 중요한 이유 코드를 쉽게 적으면 많은 개발자가 쉽게 이해하고 기여할 수 있다. 쉽게 읽을 수 있는 코드베이스는 확실히 경력이 적은 주니어 개발자도 쉽게 이해할 수 있고 기능을 추가할 수 있으며, 검토자 입장에서도 리뷰하는 게 수월하다. 결론적으로 코드베이스 퀄리티가 높아지고, 그럴수록 버그를 초래할 가능성이 작아진다. 개인 경험담이지만 확실히 가독성이 떨어지는 코드는 중복성과 불필요한 복잡성이 존재하고, 새 기능 추가와 버그 고침 그리고 리펙토링이 어려워진다. 결국 한 줄 코드를 바꿔도 예기치 않는 결과로 이어진다. 2️⃣ 버그와 코드양의 상관관계 "Less code means less space for bugs to hide" 코드가 짧을수록 버그를 발견하는 것이 쉬워진다. 유저가 특정 기능을 오랫동안 사용하지 못하는 심각한 버그는 주로 코드에 존재하는 불필요한 복잡성 때문에 일어난다. 3️⃣ 피할 수 없는 복잡성 하지만 복잡성을 완전히 없앨 수 없다. 항상 주니어 엔지니어가 쉽게 구문 분석하고 기여할 수 있는 코드를 작성할 수는 없다. 때로는 비즈니스 로직이 정말 복잡하고, 때로는 쉽게 이해하기 힘든 인터페이스가 있는 API를 사용해야 하는 경우도 있다. 이 경우 단순한 것과 복잡한 것 사이에 명확한 경계를 설정해야 한다. 👉 일상에서 중요한 코드 작성은 '경험이 적은 주니어 개발자가 쉽게 코드를 읽고 이해할 수 있는가?'다. 📌 결국 상업용 코드는 무조건 한줄 '영리하고, 똑똑한' 코드가 아닌, 모두가 쉽게 이해하고 가독성이 높은 코드며, 불필요하게 설계 패턴을 사용하며 복잡성을 더하면 버그를 초래할 가능성이 높아진다. 그렇다고 복잡성을 완전히 피하는 건 불가능하므로, 최대한 심플한 구성요소와 기능은 복잡성을 제외하고, 그 외 필요한 부분에만 넣자. 복잡한 부분도 서류화, 도큐먼트 그리고 트레이닝 세션을 통해 가독성을 높이는 방법을 고려해보자. 🪴 함께 읽으면 좋은 글: 데이터베이스를 고를 때 고려해야 하는 요소 https://careerly.co.kr/comments/84381 주니어 개발자를 고용하는 데 드는 어려움 https://careerly.co.kr/comments/82474 코드 리뷰 잘하는 법 https://careerly.co.kr/comments/82185 코딩 외에 개발자에게 절대적으로 필요한 스킬 https://careerly.co.kr/comments/78115 개발자 진로에 중요한 직급별 스킬과 기대 역할 https://careerly.co.kr/comments/78043