시니어 개발자는 더 나은 코드를 작성하지 않는다. 그들은 코드를 더 많이 삭제한다.
Source: Dev.to
삭제 역설
경력 성장에 대해 아무도 말해 주지 않는 사실: 개발자로서 당신의 가치는 작성하는 코드 양에 역비례하게 됩니다.
- 주니어 개발자가 팀에 합류하고 바로 기여를 시작합니다. 새로운 API를 구현하고, 검증 레이어를 추가하고, 유틸리티 함수를 만들며, 포괄적인 테스트 스위트를 구축합니다. 첫 해에 50,000 라인의 코드를 프로젝트에 추가할 수도 있습니다. 모두가 감탄합니다.
- 시니어 개발자가 같은 팀에 합류합니다. 첫 달에 15,000 라인의 코드를 삭제합니다. 세 개의 전체 마이크로서비스를 제거하고, 두 개의 의존성 라이브러리를 없애며, 네 개의 유사한 함수를 하나로 통합합니다. 주니어 개발자의 코드 기여 그래프는 산봉우리처럼 보이고, 시니어의 그래프는 골짜기처럼 보입니다.
어느 쪽을 회사가 더 가치 있게 여길까요?
삭제가 생성보다 나은 이유
코드 적게 = 문제 적게
모든 코드 한 줄은 부채입니다. 깨질 수 있고, 유지보수가 필요하며, 의존성을 만들고, 미래의 개발자가 이해해야 합니다. 저는 한 프로젝트에서 3,000줄짜리 설정 시스템을 200줄로 줄였던 적이 있습니다. 버그 보고가 80 % 감소했고, 성능이 40 % 향상되었습니다. 원래 그 시스템을 만든 주니어 개발자는 기분이 상했지만, 사용자들은 매우 기뻐했습니다.
유지보수 비용은 현실이다
- 당신이 만든 그 영리한 추상화? 내년엔 누군가가 이해하려고 삼 일째를 보내게 될 겁니다.
- 비슷하지만 약간씩 다른 함수 여덟 개? 각각이 요구사항이 바뀔 때 발생할 수 있는 잠재적인 버그입니다.
- 모든 엣지 케이스를 포괄하는 종합 오류 처리? 대부분의 경우는 절대 발생하지 않지만, 추가된 복잡성 때문에 미래의 모든 개발자가 느려집니다.
인지 부하가 진짜 적이다
인간의 작업 기억은 약 일곱 개의 정보만을 동시에 유지할 수 있습니다. 당신의 코드베이스는 70만 개의 정보를 담고 있을지도 모릅니다. 불필요한 함수, 중복된 매개변수, “혹시 몰라”라는 기능 하나하나가 인지 부하를 증가시킵니다. 시니어 개발자들은 인지 부하를 줄이는 것이 기능을 추가하는 것보다 더 가치 있다는 것을 잘 알고 있습니다.
전략적 삭제의 예술
먼저 중복 코드를 삭제하세요
동일한 로직이 약간씩 변형되어 여러 번 나타나는 패턴을 찾아보세요. 저는 최근에 서로 다른 “알림 전송” 함수 12개를 하나의 설정 가능한 함수로 합쳐 400줄을 삭제했고, 버그가 줄어들고 테스트가 간소화되었습니다.
사용되지 않는 기능을 제거하세요
- 아무도 보지 않는 분석 대시보드? 삭제하세요.
- QA 팀만 테스트용으로 사용하는 API 엔드포인트? 삭제하세요.
- 2년째 켜져 있던 기능 플래그? 플래그를 삭제하고 동작을 영구화하세요.
사용되지 않는 코드는 중립이 아니라, 거짓 복잡성을 만들어 내는 활동적인 해악입니다.
조기 최적화를 없애세요
주니어 개발자들은 절대 일어나지 않을 성능 시나리오를 최적화하는 것을 좋아합니다. 제가 본 사례:
- 한 달에 한 번만 바뀌는 데이터를 위한 캐싱 레이어.
- 분당 10건의 요청이 피크인 경우를 위한 복잡한 알고리즘.
- 99.99 % 가동률을 요구하는 서비스용 정교한 장애 복구 시스템.
최적화를 삭제하고 누가 눈치채는지 확인해 보세요. 스포일러: 아무도 눈치채지 못합니다.
당신의 애착(그리고 의존성)을 없애세요
- 당신이 만든 우아한 헬퍼 라이브러리? 세 곳에서만 사용된다면 전체 모듈을 유지하기보다 20줄 정도의 코드를 복사해 쓰는 것이 나을 수 있습니다.
- 정확히 필요한 기능을 제공하는 인기 npm 패키지? 기능의 **5 %**만 사용한다면 해당 기능을 직접 구현하고 의존성을 끊는 것을 고려하세요.
삭제 본능 개발하기
- 올바른 지표를 측정하세요. 작성된 라인 대신 삭제된 코드 라인을 추적합니다.
- 새로운 기능보다 퇴역한 기능을 축하하세요.
- 올바른 질문을 하세요: “이 기능을 추가하지 않으려면 어떻게 해야 할까요?” 대신 “이 기능을 추가하려면 어떻게 해야 할까요?”
10배 규칙을 실천하세요: 작성한 각 코드 라인은 10번 읽히고, 3번 수정되며, 2번 디버깅됩니다. 그만한 가치가 있는지 확인하세요.
새로운 코드를 작성하기 전에, 30분 동안 삭제할 수 있는 기존 코드를 찾아보세요. 오래된 문제를 제거함으로써 “새로운” 문제를 해결할 수 있는 경우가 얼마나 많은지 놀라게 될 것입니다.
직관에 반하는 진실
개발자로서 가장 생산적인 일은 더 많은 코드를 작성하는 것이 아니라, 더 많은 일을 하는 적은 코드를 작성하는 것입니다. 기능을 빠르게 배포하는 가장 빠른 방법은 기능을 추가하는 것이 아니라, 기능 개발을 늦추는 장벽을 제거하는 것입니다.
시니어 개발자들은 이를 직감적으로 이해합니다. 자신들의 영리한 코드에 여러 번 좌절한 경험을 통해 단순함이 복잡함을 이긴다는 것을 알게 되었고, 충분히 많은 레거시 시스템을 유지해 오면서 코드 한 줄 한 줄이 미래 유지보수에 대한 약속이라는 것을 깨달았습니다.
다음에 새로운 기능을 구현하려고 할 때, 스스로에게 물어보세요: 대신 무엇을 삭제할 수 있을까? 미래의 당신이 감사할 것이고, 팀원들도 감사할 것입니다. 사용자들도 감사할 것이지만, 그들은 애플리케이션이 왜 갑자기 더 빠르고 안정적으로 느껴지는지 깨닫지 못할 수도 있습니다.
가장 좋은 코드는 존재하지 않는 코드입니다. 최고의 개발자는 그것을 그렇게 유지하는 사람들입니다.