코딩은 쉽다고 합니다. 자전거를 타는 것과 마찬가지라고요. 사실 프로그래밍은 실제로 오토바이와 같습니다. 매우 강력하고 빠른 오토바이죠. 코딩은 라이딩과 마찬가지로 안장에 앉아 있어야 하고, 우승하려면 두 배로 노력해야 합니다. 사실 라이더와 코더는 초보자 실수를 공유합니다. 초보자는 종종 빠르고 강력한 도구와 혁신적인 기술에 집중하는 경향이 있으며, 이것만이 진정한 마스터를 정의한다고 믿습니다. 이러한 사고방식은 부분적으로 "더닝-크루거 효과" 때문인데, 초보자는 자신의 직업의 복잡성과 중요성을 파악하지 못합니다. 다행히도 경험을 통해 가장 열렬한 초보자조차도 프로그래밍의 예술에는 최적의 알고리즘을 선택하는 것 이상이 포함된다는 것을 깨닫게 됩니다. 이 글에서는 프로그래머에게 진정으로 중요한 것이 무엇이고, 신규 개발자와 노련한 개발자가 소프트웨어를 만들고 코드를 작성할 때 기억해야 할 사항에 대한 생각을 공유하고자 합니다. 성능보다 가독성이 더 중요하지만 항상 그런 것은 아닙니다. 일반적인 초보 모터사이클 운전자는 무엇부터 시작할까요? 숫자와 가젯입니다. 1/4마일에서 이론적인 밀리초를 갉아먹을 수 있는 파워, 토크, 성능 부품... 마치 MotoGP 스타팅 그리드에 오르려는 것처럼요. 그러는 동안, 그들의 주요 과제는 안전하게 라이딩하는 법을 배우는 것입니다. 마찬가지로, 초보 개발자는 종종 불필요한 코드 성능에 집착합니다. Python에서 `dict()` 또는 `{}` 중 어느 것이 더 효율적인지, 또는 성능을 저하시킬 가능성이 있음에도 불구하고 프레임워크를 사용하는 것의 장단점에 대해 논쟁하는 기사는 이러한 집착을 부추깁니다. 프로그래밍 언어의 복잡성을 이해하는 것은 유익하고 때로는 필수적이지만(예: 비행기, 주식 거래 로봇 또는 의료 기기용 소프트웨어) 우리가 매일 만드는 대부분의 프로그램에는 항상 필수적인 것은 아닙니다. 성능이 중요한 소프트웨어를 작업하는 경우에도 코드의 어느 부분에 고성능이 필요하고 어느 부분에 필요하지 않은지 아는 것이 필수적입니다. 그러나 항상 중요한 것은 코드 가독성입니다. 수많은 연구와 설문 조사에 따르면 개발자는 코드를 쓰는 것보다 코드를 읽고 이해하는 데 더 많은 시간을 할애한다는 것이 확인되었습니다. 예를 들어, 연구 IDE에서 소요되는 시간의 4%만이 코드 편집에 사용된다는 것을 발견했습니다. 250,000명 이상의 개발자를 대상으로 실시한 설문 조사에 따르면 응답자는 하루에 약 52분만 코드를 적극적으로 작성하는 데 사용한다고 밝혔습니다. 나머지 시간은 프로젝트를 논의하고 계획하는 데 사용되며, 약 41분은 IDE와 프로젝트 문서에서 코드를 읽는 데 사용됩니다. "나는 당신이 지난 여름에 한 일을 알고 있습니다 - 개발자들이 시간을 보내는 방식에 대한 조사" 글로벌 코드 타임 보고서 대부분의 경우, 우리의 목표는 복잡한 지원이 필요 없고 경쟁적인 환경에서 번창할 수 있는 유지 관리 가능한 제품을 만드는 것입니다. 이는 성능을 완전히 무시할 수 있다는 것을 의미하지 않습니다. 유지 관리 가능성과 성능이 공존하는 균형을 찾아야 합니다. 고성능 코드가 필요한 경우 프로젝트 출시 후 느린 섹션을 최적화할 수 있습니다. 컴파일러와 인터프리터는 진화하지만 코드는 동일하게 유지된다는 점도 명심하세요. 한 컴파일러 버전에 맞게 작성된 엄청나게 최적화된 마법의 코드 조각이 다른 버전에서는 무의미한 실패작이 될 수 있습니다. 게다가 미래의 개발자(또는 여러분)도 그 코드로 작업해야 할 것입니다. 그렇다면 성능을 위해 가독성을 희생해야 할 때는 언제일까요? 가독성보다 성능을 우선시해야 할 시기를 파악하려면 애플리케이션의 병목 현상을 정확히 파악해야 합니다. : 프로파일링을 통해 특정 중요 코드 섹션이 성능에 상당한 영향을 미치는 것으로 밝혀진 경우, 이러한 조각을 최적화하면 가독성을 낮출 수 있습니다. 애플리케이션 프로파일링 : 높은 부하를 시뮬레이션하면 실제 문제가 되기 전에 성능 병목 현상을 파악하는 데 도움이 될 수 있습니다. 부하 테스트 : 사용자 피드백을 수집하면 성과가 낮은 영역을 파악할 수 있습니다. 사용자 피드백 분석 : 실행 로그와 메트릭을 분석하면 애플리케이션의 실제 운영 중에 문제가 있는 영역을 식별할 수 있습니다. 이 단계에서는 부적절한 API 사용으로 인한 성능 문제 등 예상치 못한 문제가 발견될 수 있습니다. 로깅 및 모니터링 : 일부 도구는 코드 검토 중에 성능 개선을 제안할 수 있습니다. 작업 검토 중에 이러한 도구를 자동으로 실행하는 것은 좋은 관행입니다. 정적 코드 분석 도구 이러한 팁은 애플리케이션의 약점을 파악하는 데 도움이 되어 필요한 최적화에 집중할 수 있습니다. 제 개인적인 경험에 따르면 이러한 최적화는 이국적인 언어 구성 요소를 포함할 가능성이 적고 데이터베이스 상호 작용이나 외부 API 사용을 최적화하는 것이 더 가능성이 높습니다. 문서화는 수행된 작업을 이해하는 데 도움이 됩니다. 도로에서 운전할 때 가장 중요한 안전 기술 중 하나는 예측 가능하고 마찬가지로 다른 사람의 의도를 읽는 것입니다. 코딩에서는 라이딩과 마찬가지로 다른 사람의 마음을 직접 읽을 수 없습니다. 두 바퀴로 운전할 때는 미묘한 움직임을 알아차리고 다른 사람이 다음 순간에 무엇을 할지 예측해야 합니다. 프로그래머는 텔레파시를 대체할 강력한 도구인 서류 작업을 보유하고 있지만 항상 사용하는 것은 아닙니다. 대부분의 개발자는 문서화가 프로젝트에 필수적이라는 데 동의합니다. , 응답자의 90.36%가 기술 문서를 정기적으로 사용합니다. 그러나 그들은 종종 거기에서 모든 답을 찾을 수 없으며 대신 Stack Overflow(82.56%)와 다양한 블로그(76.69%)로 향합니다. 또 다른 연구에서는 개발자들은 하루 중 1-2%를 문서화 작업에 사용하고, 응답자의 10.3%는 부실하거나 오래된 서류로 인해 많은 시간을 낭비하고 있는 것으로 나타났습니다. Stack Overflow 개발자 설문 조사 2023 Microsoft Research: 소프트웨어 개발자의 일상 생활 문서는 Confluence와 같은 시스템의 자세한 프로젝트 설명부터 코드 주석, 자동 또는 반자동으로 생성된 프로젝트 설명 웹사이트에 이르기까지 다양한 형태를 취할 수 있습니다. 심지어 프로젝트 루트 디렉토리에 있는 README 파일처럼 간단할 수도 있습니다. 형식에 관계없이 문서를 만드는 과정은 단순히 제품이 작동하는 방식에 대한 정보를 전달하는 것을 훨씬 넘어섭니다. 이 과정을 , 이는 종종 API와 전반적인 아키텍처의 개선으로 이어질 수 있습니다. 저는 제가 만든 기능을 문서화하는 동안 종종 작업하기 어려울 수 있다는 것을 깨달았고, 이를 해결할 방법을 찾았습니다. 통해 우리는 우리가 한 일을 다시 생각하게 되고 문서 유지 관리에는 항상 상당한 노력이 필요하다는 것을 기억하는 것이 중요합니다. 특히 프로젝트가 자주 변경되는 단계에 있는 경우 더욱 그렇습니다. 이러한 경우 모든 위험을 평가하고 어떤 논리를 문서화할지 신중하게 고려해야 합니다. 프로젝트가 성숙한 상태에 도달한 경우 좋은 문서는 어려움보다 더 많은 이점을 가져다줍니다. 새로운 개발자는 더 빨리 탑승하고 모멘텀을 얻을 수 있고, 오랜 직원은 특정 기능의 작동 방식을 빠르게 파악할 수 있습니다. 또한 여러 팀이 있는 대규모 프로젝트에서 좋은 검색 기능이 있는 문서는 기능 중복을 방지할 수 있습니다. 자신이 무엇을 하고 있는지 다른 사람들에게 말하는 것은 부끄러운 일이 아닙니다. 방향 지시등을 사용하는 것은 예측 가능한 라이더가 되는 가장 기본적인 형태입니다. 마찬가지로 코드 주석은 아마도 다른 사람에게 무엇을 하고 있는지 알리는 가장 쉽고 직접적인 방법일 것입니다. 그리고 방향 지시등을 사용하는 것과 마찬가지로, 덜 멋지다는 것은 아닙니다. 주석이 불필요하다는 일반적인 믿음이 있다는 것을 알고 있습니다. 왜냐하면 코드는 자체적으로 설명되어야 하기 때문입니다. 하지만, 아뇨, 저는 그것에 전적으로 동의하지 않습니다. 양질의 코드는 종종 좋은 변수 및 함수 명명, 명확한 구조 및 깨끗한 코드 원칙을 고수함으로써 직관적으로 이해할 수 있습니다. 그러나 그러한 경우에도 잘 생각된 주석은 귀중한 정보를 제공할 수 있습니다. 주석은 이해하기 위해 추가적인 맥락이 필요한 복잡한 알고리즘이나 솔루션과 관련하여 중요한 역할을 합니다. 주석은 코드 자체에서 항상 명확하게 드러나지 않는 접근 방식의 설명할 수 있습니다. 이는 코드가 성능에 최적화되었지만 의도와 논리가 즉시 명확하지 않은 경우 특히 중요합니다. 주석은 선택한 알고리즘이 올바른 방향으로 움직이는지 다시 고려하는 데 도움이 될 수도 있습니다. "이유"를 주석은 복잡한 비즈니스 로직이나 프로젝트별 요구 사항에서 생명줄이 되며, 이는 새로운 팀원이나 장기 프로젝트 지원의 경우 명확하지 않을 수 있습니다. 주석은 팀 내에서 지식을 유지하고 개발자 간에 프로젝트를 이전하는 것을 더 쉽게 해줍니다. 물론, 주석이 명백한 것을 말하거나 오래되고 오해의 소지가 있는 과도한 주석은 피하는 것이 필수적입니다. 주석의 목적은 명확성을 보장하고 코드에 대한 이해를 지원하는 것이지 불필요한 정보로 코드를 어지럽히는 것이 아닙니다. 테스트: 코드 이해 및 검증을 위한 도구 좋아요, 이제 우리가 마침내 타는 법을 배웠고 이제 진짜 경주로에서 운을 시험하고 싶다고 상상해보세요. 글쎄요, 우리는 곧 진짜 경주가 단순히 '금속까지 페달을 밟는 것'에 관한 것이 아니라는 것을 알게 될 것입니다. 그것은 당신의 습관과 경주 조건에 맞게 기계를 훈련하고 테스트하고 미세 조정하는 것을 포함합니다. 코드에도 동일하게 적용됩니다. 실제 스핀을 시작하기 전에 철저히 시도하고 테스트하고 필요한 경우 수정해야 합니다. 따라서 최대한의 책임감을 가지고 코드 테스트에 접근하는 것이 중요합니다. 테스트는 종종 버그를 찾는 도구로 간주되지만 그 역할은 더 광범위합니다. : 테스트를 통해 제품이 사용자에게 도달하기 전에 오류와 예상치 못한 동작을 식별하여 품질을 향상하고 사용자 문제를 줄입니다. 오류 및 결함 감지 : 테스트 시나리오를 만들려면 코드의 구조와 기능에 대한 심층적인 이해가 필요하며, 이를 통해 프로그램의 논리와 상호 작용을 더 잘 이해할 수 있습니다. 코드 이해 : 테스트는 함수 및 메서드에 대한 사용 사례로 활용될 수 있으며, 프로젝트 기능에 대한 정보를 찾는 데 도움이 되고 실제 사용 사례를 제공하여 새로운 전문가에게 도움을 줄 수 있습니다. 문서 보충 자료 효과적인 테스트는 고품질, 신뢰할 수 있고 이해하기 쉬운 코드를 생성하는 데 필수적입니다. 그러나 문서화와 마찬가지로 테스트는 특히 프로젝트 초기 단계에서 리소스 집약적일 수 있습니다. 테스트의 필요성과 시간 및 리소스 제약 사이의 균형을 맞추는 것이 필수적입니다. 복잡한 코드에 대한 절대적인 테스트 커버리지는 단순히 달성할 수 없다는 것도 분명합니다. 따라서 개발자는 핵심 기능과 중요한 코드 섹션의 테스트를 우선시해야 하며, 끝없는 테스트 주기를 피하기 위해 언제 중단해야 할지 알아야 합니다. 친구를 사랑하듯이 코드를 사랑하고 소중히 여기세요 마지막으로, 적절한 유지관리 없이는 어떤 오토바이도 신뢰할 수 없습니다. 라이딩의 이 측면을 소홀히 하는 사람들이 꽤 있지만, 그들은 우리가 절대 참여하고 싶지 않은 이야기(재밌는 것부터 무서운 것, 슬픈 것까지)를 만들어냅니다. 프로그래밍 세계에서, 오토바이와 마찬가지로, 코드 유지관리는 단순히 권장사항이 아니라 필수사항이며, 특히 장기 프로젝트의 경우 더욱 그렇습니다. 유지관리와 업데이트가 부족하면 제품이 노후화되고 보안이 취약해집니다. 코드가 최신 컴파일러 및 인터프리터와의 호환성을 위해 업데이트되지 않으면 업데이트가 점점 더 어려워질 수 있습니다(실제로 그럴 것입니다). 데스크톱 또는 모바일 애플리케이션을 개발하는 경우 제품이 새 OS 버전에서 작동하지 않을 수 있습니다. 웹사이트의 경우 오래된 도구와 기술로 인해 작동하지 않을 수 있습니다. 가장 간단한 문제는 만료된 보안 인증서 또는 갱신을 위한 오래된 소프트웨어일 수 있습니다. 정기적인 업데이트와 리팩토링도 코드 가독성을 유지하는 데 중요합니다. 이를 통해 프로젝트를 관리하기 쉽게 유지하고 향후 변경 사항과 기능 추가를 간소화할 수 있습니다. 간단히 말해서, 코드를 사랑하고 시간을 투자하세요. 하지만 지나치게 하지 마세요. 그렇지 않으면 "제로 정리"의 주인공처럼 될 겁니다. 행운을 빕니다!
