코드를 더 좋게 만드는 필수 개발자 기술

역자의 서문 : 이 글을 읽고 나면 놀라실 수도 있고 화가 나실 수도 있습니다. 예, 우리도 놀랐습니다. 저자는 팀의 계층 구조, "추론 없이 신속하게 수행" 상태의 작업 설정에 대해 들어본 적이 없는 것으로 추정됩니다. 네 맞습니다. 좀 이상한 글이네요. 실제로 저자는 프로그래머가 시스템 아키텍트의 역할을 맡을 것을 제안합니다. 그러면 왜 아키텍트가 필요합니까? 그러나 이러한 모든 이의 제기로 인해 주요 사항, 즉 왜 우리가 이 텍스트를 가져와 번역했는지 알 수 없습니다. 그는 역할에 대해 말하는 것이 아닙니다. 이 텍스트는 전문적인 접근 방식과 인식에 관한 것입니다. 사실, 자신의 행동의 의미에 대해 생각하지 않고 단지 "시키는 대로만 하는" 한 당신은 결코 훌륭한 프로그래머가 될 수 없습니다.

불필요한 코드는 거부하세요. 당신이 해야 할 일은 세 글자를 모아서 단어를 말하는 것뿐입니다. 함께 해보자: "안돼!"

하지만 기다려. 우리는 왜 이런 일을 하는 걸까요? 결국 프로그래머의 주된 임무는 코드를 작성하는 것이다. 하지만 요청받은 코드를 작성해야 합니까? 아니요! "코드를 작성하지 말아야 할 때를 이해하는 것은 아마도 프로그래머에게 가장 중요한 기술일 것입니다." 읽기 쉬운 코드의 예술.

알림: "Habr"의 모든 독자를 위한 - "Habr" 프로모션 코드를 사용하여 Skillbox 과정에 등록할 때 10 루블 할인.

Skillbox는 다음을 권장합니다. 실기 코스 "모바일 개발자 PRO".

프로그래밍은 문제 해결의 예술이다. 그리고 당신은 이 예술의 대가입니다.
때로는 가능한 한 빨리 작업을 시작하기 위해 당면한 작업을 완료하는 것 외에는 아무것도 생각하지 않습니다. 그리고 이는 더욱 심각한 문제를 야기할 수 있습니다.

프로그래머가 눈을 감는 것은 무엇입니까?

작성하는 모든 코드는 다른 개발자가 이해할 수 있어야 하며 테스트 및 디버깅을 거쳐야 합니다.

그러나 문제가 있습니다. 무엇을 작성하든 소프트웨어가 복잡해지고 나중에 버그가 발생할 수도 있습니다.

리치 스크렌트(Rich Skrent)에 따르면, 코드는 우리의 적이다. 다음은 그가 쓴 글입니다.

“코드는 부패하기 시작하고 지속적인 유지 관리가 필요하기 때문에 좋지 않습니다. 새로운 기능을 추가하려면 기존 코드를 수정해야 하는 경우가 많습니다. 크기가 클수록 오류가 발생할 가능성이 높아지고 컴파일하는 데 더 많은 시간이 걸립니다. 그것을 알아내는 데 다른 개발자가 더 많은 시간이 걸립니다. 그리고 리팩토링이 필요하다면 분명히 변경할 가치가 있는 조각이 있을 것입니다. 코드가 크다는 것은 종종 프로젝트의 유연성과 기능성이 감소한다는 것을 의미합니다. 간단하고 우아한 솔루션은 복잡한 코드보다 빠릅니다.”

코드를 작성하지 말아야 할 때를 어떻게 알 수 있나요?

문제는 프로그래머가 애플리케이션에 필요한 기능의 수를 과장하는 경우가 많다는 것입니다. 결과적으로 많은 코드 섹션이 미완성 상태로 남아 있거나 아무도 사용하지 않지만 애플리케이션을 복잡하게 만듭니다.

프로젝트에 필요한 것과 필요하지 않은 것을 명확하게 이해해야 합니다.

예를 들어 이메일 관리라는 단 하나의 작업만 해결하는 애플리케이션이 있습니다. 이를 위해 편지 보내기 및 받기라는 두 가지 기능이 도입되었습니다. 메일 관리자가 동시에 작업 관리자가 될 것이라고 기대해서는 안됩니다.

애플리케이션의 주요 작업과 관련되지 않은 기능을 추가하려는 제안에는 단호하게 "아니오"라고 대답해야 합니다. 추가 코드가 필요하지 않다는 것이 분명해지는 순간입니다.

지원서의 초점을 절대로 잃지 마십시오.

항상 스스로에게 물어보세요:

— 이제 어떤 기능을 구현해야 합니까?
— 어떤 코드를 작성해야 하나요?

떠오르는 아이디어에 대해 질문하고 외부에서 오는 제안을 평가하십시오. 그렇지 않으면 추가 코드로 인해 프로젝트가 종료될 수 있습니다.

불필요한 것을 추가하지 말아야 할 때를 아는 것은 코드 기반을 확고하게 통제하는 데 도움이 됩니다.

경로의 맨 처음에는 프로그래머가 소스 파일을 XNUMX~XNUMX개만 가지고 있습니다. 간단 해. 애플리케이션을 컴파일하고 실행하려면 최소한의 시간이 필요합니다. 어디서, 무엇을 찾아야 할지 항상 명확합니다.

애플리케이션이 확장됨에 따라 점점 더 많은 코드 파일이 나타납니다. 그들은 각각 수백 줄의 카탈로그를 채웁니다. 이 모든 것을 올바르게 구성하려면 추가 디렉터리를 만들어야 합니다. 동시에, 어떤 기능이 무엇을 담당하고 어떤 행동이 이를 유발하는지 기억하는 것이 점점 더 어려워지고 있습니다. 버그를 잡는 데에도 시간이 더 걸립니다. 프로젝트 관리도 더욱 복잡해지고 있으며, 모든 것을 추적하려면 한 명이 아니라 여러 명의 개발자가 필요합니다. 이에 따라 금전적, 시간적 비용이 증가하고 개발 프로세스가 느려집니다.

프로젝트는 결국 거대해지며 각각의 새로운 기능을 추가하는 데 점점 더 많은 노력이 필요합니다. 아주 사소한 일에도 몇 시간을 소비해야 합니다. 기존 오류를 수정하면 새로운 오류가 나타나고 애플리케이션 릴리스 마감일을 놓치게 됩니다.

이제 우리는 프로젝트의 생명을 위해 싸워야 합니다. 왜?

사실 당신은 언제 추가 코드를 추가하면 안 되는지 이해하지 못했고 모든 제안과 아이디어에 "예"라고 대답했습니다. 당신은 장님이었고, 새로운 것을 창조하려는 욕구 때문에 중요한 사실을 무시하게 되었습니다.

마치 공포영화 대본 같죠?

계속해서 '예'라고 말하면 바로 이런 일이 일어날 것입니다. 코드를 추가하면 안 되는 경우를 이해하려고 노력하세요. 프로젝트에서 불필요한 것을 제거하면 생활이 훨씬 쉬워지고 애플리케이션 수명이 연장됩니다.

"가장 생산적인 날 중 하나는 1000줄의 코드를 삭제한 날이었습니다."
— 켄 톰슨.

코드를 작성하지 말아야 할 때를 배우는 것은 어렵습니다. 그러나 그것은 필요합니다.

네, 이제 막 개발자의 길을 시작하셨고 코드를 작성하고 싶어하신다는 걸 알고 있습니다. 좋아요, 첫인상을 잃지 마세요. 하지만 열정 때문에 중요한 요소를 놓치지 마세요. 우리는 시행착오를 통해 모든 것을 실현했습니다. 당신은 또한 실수를 하고 그로부터 배울 것입니다. 하지만 위의 내용을 통해 배울 수 있다면 작업에 대한 의식이 더욱 높아질 것입니다.

계속 창조하되 언제 거절해야 할지 알아두세요.

Skillbox는 다음을 권장합니다.

• 온라인 강좌 적용 "파이썬 데이터 분석가".
• 온라인 코스 "직업 프론트엔드 개발자".
• 실기 코스 "0에서 PRO로의 PHP 개발자".

출처 : habr.com