초보 프로그래머의 일반적인 실수 분석: 1부

안녕, 세계! 필요한 모든 것을 배우고 마침내 인턴이나 후배로 채용된 후에는 아마도 긴장을 풀 수 있을 것입니다. 그렇죠? 아무리 그렇더라도! 모든 것이 이제 막 시작되었습니다... 주변에는 새롭고 이해할 수 없는 것들이 많이 있는데, 문 밖에서 바로 이렇게 망치지 않는 방법은 무엇입니까? 그것이 오늘 우리가 이야기할 내용입니다. 이 글에서는 초보자들이 흔히 저지르는 실수를 살펴보고 이를 피하는 방법에 대한 내 경험을 바탕으로 몇 가지 팁을 제공하고 싶습니다. 이제 더 이상 고민하지 않고 시작해 보겠습니다.

1. 경험이 많은 동료에게 도움을 요청하는 것에 대한 두려움

우리는 모두 인간이고, 특히 새롭게 합류하고 경험이 많은 동료의 눈에 바보처럼 보일까 봐 두려워합니다. 개발자들은 일단 첫 직장을 구하고 나면 이러한 두려움에 굴복하고 위로할 수 없을 정도로 스스로 물러나 모든 것을 스스로 해결하려고 노력합니다. 동시에, 사람은 더 경험이 많은 동료들에게 둘러싸여 있을 수 있으며, 그 동료들은 처음에 그를 가장 올바른 길로 안내할 수 있으며, 이는 더 많은 실수와 불필요한 "충돌"을 피하는 데 도움이 될 것입니다. 그러므로 질문하는 것을 두려워하지 마십시오. 귀하는 초보자이며 모든 사람이 이것을 완벽하게 이해합니다. 당신이 물어 보면 아무도 당신을 막대기로 때리지 않을 것입니다. 아마도 그 반대일 수도 있습니다. 동료와 더 빨리 친구가 되고 더 적극적으로 소통하기 시작할 것입니다. 더 말씀드리자면, 다양한 기술적인 문제에 대해 더 많이 질문하고 논의할수록 더 빨리 초심자의 입장에서 벗어나 해당 분야의 전문가로 성장할 수 있습니다. 그리고 조언 하나 더. StackOverFlow 를 무시하지 마세요 . 이러한 맥락에서 나는 이 리소스에 대해 질문하는 것을 의미합니다. 한편으로는 귀하의 질문에 대한 답변을 얻는 데 시간이 걸립니다. 그러나 다른 한편으로는 현재 문제를 해결하기 위한 여러 가지 접근 방식을 즉시 배우고 약간 다른 관점에서 볼 수도 있습니다. 또한 댓글-답변을 작성하고 다른 개발자의 StackOverFlow에 대한 질문에 대한 질문을 명확하게 하는 것 외에도 카르마에 대한 장점이 있다는 점에 주목하고 싶습니다. 이 문제를 더 깊이 논의하고 이해할 수 있는 기회가 있다는 것입니다.

2. 혼자서 정보를 찾으려고 하지 마세요

아마도 이 오류는 이전 오류의 반대면일 것입니다. 모든 문제나 문제에 대해 동료나 지인을 끌어당기기 시작할 때를 의미합니다. 질문하는 것은 좋지만 질문을 너무 멀리해서는 안 됩니다. 그렇지 않으면 지루해질 수 있습니다. 이해할 수 없는 점이 나타나면 가장 먼저 해야 할 일은 최고의 검색 엔진인 Google에 검색 기술을 적용하는 것입니다. 누군가는 이미 이해할 수 없는 오류와 기타 문제의 대다수를 경험했습니다. 그리고 구글에 검색해 보면 비슷한 문제에 대해 잘 알고 있고 업무에 사용하기에 적합한 포괄적인 답변을 이미 받은 사람들의 수가 많은 것을 보면 꽤 놀랄 것입니다. 이를 바탕으로 동료가 "Google it"이라는 질문에 대답하는 것을 자주 들을 수 있습니다. 결국 당신의 동료는 당신의 업무 분야의 모든 복잡성을 전달해야 하는 개인 교사가 아니기 때문에 이 답변에 기분이 상해서는 안 됩니다. 인터넷의 끝없는 확장은 그러한 멘토링에 도움이 될 것입니다. 때때로 프로그래머는 Google 검색에서 검은 띠를 가진 사람으로 불리기도 합니다 . 따라서 문제가 발생하면 먼저 Google에서 문제를 검색하고 해결책을 찾지 못한 경우(드물지만 발생하는 경우) 동료에게 물어보기 시작합니다. 어떤 종류의 결함이나 이해할 수 없는 오류가 있을 때가 아니라 문제 해결 방법을 선택할 때 즉시 물어볼 가치가 있습니다. 결국, 그들은 당신의 것 너머를 볼 수 있고 이 접근 방식이나 저 접근 방식이 장기적으로 어떻게 될지 즉시 알 수 있습니다.

3. 블라인드 복사-붙여넣기

하지만 인터넷 검색을 통해 문제와 그에 따른 해결책에는 함정이 있습니다. 예를 들어, 숨은 복사-붙여넣기 입니다 . 이는 일반적으로 유사한 문제(그러나 정확히 동일하지는 않음)를 발견하고 그 아래에 예를 들어 StackOverFlow에 해결책이 있을 때 발생합니다. 너무 자세히 설명하지 않고 이 솔루션을 직접 복사하여 붙여넣으세요. 그러다가 귀하 또는 귀하의 프로젝트 동료가 이상한 버그나 기능의 잘못된 동작을 발견하게 됩니다. 그리고 그 누구도 다리가 어디서 왔는지 전혀 모릅니다. 그러면 물론 이 코드가 있는 장소를 찾을 수 있으며 이 결정에 대해 결코 칭찬을 받지 못할 것입니다. 따라서 StackOverFlow(또는 다른 곳)에서 기성 솔루션을 찾으면 먼저 해당 솔루션이 무엇인지, 방법 및 이유를 자세히 분석해야 합니다. 아마도 이 기능을 구글에 검색해 관련 문서를 살펴보세요. 그 후에야 프로젝트에 구현하십시오.

4. 잘못된 해결책을 던지는 것

솔루션을 작성하다 보면 점점 복잡해져서 결국 막다른 골목에 도달하는 경우가 있습니다. 그리고 더 실행 가능한 다른 대안을 찾는 대신 이 접근 방식을 사용하여 어떻게든 이 문제를 해결하기 위해 문제를 점점 더 복잡하게 만들려고 노력하고 있습니다. 아마도 당신은 단순히 당신이 소비한 에너지와 시간에 대해 안타까워서 결정을 내릴 것입니다. 무슨 일이 있어도 포기하지 말고 이 방법으로 문제를 해결하십시오. 이것은 전적으로 올바른 접근 방식이 아닙니다. 적어도 프로그래밍에서는요. 다른 접근 방식을 빨리 시도할수록 더 많은 시간을 절약할 수 있습니다. 따라서 이 방법에 많은 시간을 투자했음에도 불구하고 다른 접근 방식을 실험하고 시도하는 것을 두려워하지 마십시오. 또한, 여러 가지 접근 방식을 시도하고 이 분야를 더 잘 연구하게 되므로 이는 경험의 포인트가 될 것입니다.

5. 현재 업무에 대해 질문하는 것에 대한 두려움

프로젝트 작업은 일반적으로 일부 작업(작업)을 완료하는 것으로 귀결됩니다. 예를 들어 Jira 에서는 . 그리고 이러한 작업이 항상 자세하고 명확하게 설명되는 것은 아닙니다. 일반적으로 팀 리더가 작성하며, 그럴 경우 이들도 사람입니다. 그들은 또한 당신이 이 기능이나 그 기능에 익숙하지 않다는 사실을 고려하지 않거나 무언가를 추가하는 것을 잊을 수도 있습니다. 아니면 프로젝트에 대한 액세스 권한이 없습니다(예: 데이터베이스, 로그 서버 등에 대한 액세스 등). 그리고 이제 과제를 받고 두 시간 이상 연구한 후에도 여전히 당황한 채 앉아서 화면을 바라보고 있습니다. 그리고 이것을 아무 소용 없이 계속 알아내는 대신, 이 작업의 작성자에게 유도/명확한 질문을 시작해야 합니다. 팀 내 커뮤니케이션(예: Microsoft Teams)에 사용하거나 이 작업에서 직접 댓글로 사용하는 애플리케이션에서라고 가정해 보겠습니다. 한편, 개인 메시지에 질문을 쓰면 상대방이 질문을 바로 볼 수 있기 때문에 답변이 더 빨라질 가능성이 높습니다. 반면에 Jira에서 질문을 하면 문제를 분석하고 있다는 증거가 됩니다. 이 프로세스의 속도를 높일 수 있는 방법이 있습니다. Jira에서 댓글로 질문을 하고, 보기 요청과 함께 비공개 메시지로 이 댓글에 대한 링크를 보내세요.

6. 팀장에게 너무 많은 것을 기대한다

다시 말하지만, 이것은 이전 요점의 반대 측면입니다. 팀 리더는 개발팀의 책임자입니다. 일반적으로 이러한 팀원의 대부분의 시간은 다양한 유형의 커뮤니케이션에 소비됩니다. 동시에 그는 모든 것이 무엇인지 잊지 않도록 코드도 작성합니다. 글쎄, 아시다시피 이것은 매우 바쁜 캐릭터입니다. 그리고 재채기를 할 때마다 지나치게 경련을 일으키는 것은 분명히 그를 행복하게 만들지 않을 것입니다. 모든 팀원이 그에게 수많은 질문을 쏟아부었다고 상상해 보세요. 그럼 미쳐버릴 수도 있지, 그렇지? 그리고 귀하의 질문이 많기 때문에 그가 오랫동안 귀하에게 대답할 것이라는 것은 놀라운 일이 아닙니다. 팀 리더에게 보내는 질문 수를 줄이기 위해 무엇을 할 수 있습니까?

• 사각지대를 줄이기 위해 이 프로젝트의 문서를 더 깊이 연구하세요.
• 다른 팀원들에게 질문을 해보세요. 그들 중 한 명이 해당 기능을 작성했을 가능성이 높기 때문에 그들은 이 기능에 대해 주연만큼 또는 그 이상으로 익숙할 가능성이 높습니다.

또는 IDE에서 특정 줄의 코드를 누가, 언제 마지막으로 변경했는지에 대한 주석을 볼 수 있습니다. 이런 식으로 우리는 누가 이 질문을 하는 것이 가장 정확한지 알아낼 것입니다. 이미 이해하셨겠지만, 팀 리더에게 질문할 때나 동료에게 질문할 때 황금률을 유지해야 합니다. 질문하는 것을 두려워하지 말고 너무 많은 숫자로 괴롭히지 마십시오.

7. 코드 리뷰에 대한 두려움

코드 검토 또는 코드 검토는 코드를 일반 애플리케이션(예: 마스터 또는 개발자)에 업로드하기 전 단계입니다. 이 점검은 해당 작업과 관련이 없는 개발자가 수행하며, 개발 초기 단계에서 간과되었던 코드 스타일의 오류, 부정확성 또는 단점을 새로운 시각으로 발견할 수 있습니다. 주석이 있는 경우 코드의 특정 섹션에 주석으로 남습니다. 이 경우, 이 작업을 수행한 개발자는 리뷰에 따라 오류를 수정해야 합니다(또는 리뷰어와 자신의 결정을 논의하여 결정의 정확성을 확신시킬 수도 있음). 그런 다음 검토를 위해 다시 보내는 등의 작업을 검토자가 코멘트가 없을 때까지 계속합니다. 검토자는 코드를 업로드하기 전에 "필터" 역할을 합니다. 그래서 많은 초보 프로그래머들은 코드 리뷰를 비판과 비난으로 인식합니다. 그들은 그녀를 감사하지도 않고 두려워하는데, 그것은 잘못된 것입니다. 코드를 개선할 수 있는 것은 코드 검토입니다. 결국 우리는 우리가 무엇을 잘못하고 있는지, 무엇에 주의를 기울여야 하는지에 대한 중요한 정보를 받습니다. 각 코드 리뷰를 학습의 일부로 살펴보고 개선하는 데 도움이 될 수 있는 것이 필요합니다. 어떤 사람이 귀하의 코드에 댓글을 남길 때, 그는 자신의 경험과 모범 사례를 귀하와 공유합니다. 나로서는 코드 리뷰를 받지 않고서는 좋은 프로그래머가 될 수 없습니다. 외부 경험자 입장에서는 자신의 코드가 얼마나 좋은지, 거기에 실수가 있는지 알 수 없기 때문이다.

8. 해결책을 난해하게 만드는 경향

다양한 작업/문제에는 여러 가지 솔루션이 있을 수 있습니다. 그리고 사용 가능한 모든 솔루션 중에서 초보자는 일반적으로 가장 복잡하고 "난해한" 솔루션을 사용합니다. 그리고 그것은 사실입니다. 초보 프로그래머가 어제 다양한 알고리즘, 패턴, 데이터 구조를 연구했다면 그 중 하나를 구현하려고 손이 가렵습니다. 예, 말하자면 제 자신을 선언하고 싶습니다. 저를 믿으세요. 저도 그랬고 제가 무슨 말을 하는지 압니다. :) 저는 하나의 기능을 작성하는 데 오랜 시간을 소비했는데 결과적으로 매우 복잡해졌던 상황이 있었습니다. 그런 다음 Senior+ 수준의 개발자가 다시 작성했습니다. 물론 나는 그가 무엇을, 어떻게 바꾸었는지 알고 싶었습니다. 나는 그의 구현을 보고 그것이 얼마나 단순해졌는지에 놀랐습니다. 그리고 코드는 3배나 줄어들었습니다. 동시에 이 기능에 대한 테스트는 변경되지 않았으며 실패하지도 않았습니다! 즉, 일반적인 논리는 동일하게 유지됩니다. 이를 통해 저는 다음과 같은 결론에 도달했습니다. 가장 독창적인 솔루션은 항상 단순합니다 . 이 깨달음 이후 코드 작성이 훨씬 쉬워졌고 눈에 띄게 더 높은 수준이 되었습니다. 그렇다면 언제 패턴과 알고리즘을 사용할 가치가 있는지 물어보시나요? 그러면 그것들을 사용할 때 가장 간단하고 컴팩트한 방법이 될 것입니다.

9. 자전거의 발명

이 개념은 바퀴의 발명으로도 알려져 있습니다. 그 본질은 개발자가 솔루션이 이미 존재하는 문제에 대해 자신의 솔루션을 구현하고 프로그래머가 발명한 것보다 몇 배 더 낫다는 사실에 있습니다. 일반적으로 자신의 자전거를 발명하면 시간이 낭비되고 개발자 작업의 효율성이 저하됩니다. 최고와는 거리가 먼 솔루션을 찾지 못하거나 전혀 찾을 수 없기 때문입니다. 동시에 우리는 독립적인 결정의 가능성을 버릴 수 없습니다. 프로그래머는 기성 솔루션을 사용하거나 자신의 솔루션을 발명하여 유능하고 시기적절하게 문제를 해결하기 위해 앞에 나타날 수 있는 작업을 올바르게 탐색해야 합니다. 한편으로, 대학과 강좌에서 우리는 자전거를 만드는 데 도움이 되는 다양한 종류의 작업에 둘러싸여 있습니다. 그러나 이것은 언뜻보기에 불과합니다. 사실, 이것의 목적은 알고리즘적 사고를 개발하고 언어 구문에 대한 더 깊은 숙달을 하는 것입니다. 또한 이러한 작업은 알고리즘/구조를 더 잘 이해하는 데 도움이 되며, 필요한 경우 고급 아날로그를 구현하는 기술을 제공합니다(그러나 이는 거의 필요하지 않습니다). 실제 생활에서는 대부분의 경우 우리의 요구를 충족시키는 유사품이 오랫동안 존재했기 때문에 자신의 바퀴를 만들 필요가 없습니다. 아마도 귀하의 경험으로 인해 귀하는 필요한 기능 또는 해당 기능의 구현이 존재하는지 알지 못할 것입니다. 여기에서 이 기사의 첫 번째 요점, 즉 경험이 많은 동료에게 도움을 요청해야 합니다. 이들은 귀하에게 안내를 제공하거나(예: Google에 어떤 방향을 제시할지 조언) 특정 구현(특정 라이브러리)을 제안할 수 있습니다.

10. 테스트를 작성하지 마세요

모든 초보자는 테스트 작성을 좋아하지 않습니다. 초보자는 어떻습니까? 초보자가 아닌 사람도 테스트 작성을 좋아하지 않지만 테스트가 필요한 이유를 더 잘 이해합니다. 당신이 완전히 녹색일 때 당신은 생각합니다: 왜 그것을 쓰는가? 모두 작동하며 오류가 없습니다. 하지만 변경 사항으로 인해 시스템의 다른 부분이 손상되지 않는다고 어떻게 확신할 수 있습니까? 동료들은 이익보다 더 많은 것을 파괴하는 변화를 추진한다면 그것을 감사하지 않을 것입니다. 테스트가 구출되는 곳입니다. 테스트를 통해 응용 프로그램이 더 많이 다루어질수록 더 좋습니다(적용률이라고도 함). 애플리케이션이 테스트를 통해 잘 다루어지면 모든 테스트를 실행하여 변경 사항으로 인해 손상될 수 있는 부분을 찾을 수 있습니다. 그리고 위의 예에서 말했듯이 기능을 리팩토링할 때 테스트가 실패하지 않은 것은 일반적인 논리가 변경되지 않았기 때문입니다. 즉, 테스트를 통해 특정 기능의 논리가 변경되었는지 여부도 확인할 수 있습니다. 따라서 테스트 작성을 좋아하지 않더라도 테스트를 통해 얻을 수 있는 이점은 의심할 여지가 없으며 시간을 투자할 가치가 있습니다.

11. 과도한 댓글

많은 개발자들이 완벽주의로 인해 어려움을 겪고 있으며, 초보자도 예외는 아닙니다. 그러나 때때로 이러한 욕구의 부작용은 그들이 모든 사람과 모든 것에 대해 언급하기 시작한다는 것입니다. 필요하지 않은 것조차도 너무 명백하기 때문에:

Cat cat = new Cat(); // cat Object

모든 초보 프로그래머가 코드에 주석을 다는 것이 항상 좋은 것은 아니라는 사실을 즉시 깨닫는 것은 아닙니다. 왜냐하면 코드가 훨씬 더 복잡해지고 읽기 어려워지기 때문입니다. 코드가 변경되었는데 코멘트가 없다면 어떻게 될까요? 그는 우리를 속이고 우리를 혼란스럽게 할 것이라는 것이 밝혀졌습니다. 그렇다면 왜 그런 의견이 있습니까? 일반적 으로 잘 작성된 코드에는 주석이 필요하지 않습니다 . 코드 안의 모든 내용이 이미 명확하고 읽기 쉽기 때문입니다. 주석을 쓴다면 이는 이미 코드의 가독성을 망쳤으며 어떻게든 상황을 원활하게 하려고 노력하고 있다는 의미입니다. 가장 좋은 방법은 주석으로 보완할 필요가 없는 읽기 가능한 코드를 처음에 작성하는 것입니다. 또한 메소드, 변수, 클래스의 올바른 이름 지정, 즉 나 자신이 준수하는 규칙에 대해 언급하지 않을 수 없었습니다. 가장 좋은 의견은 주석이 없다는 것이며, 그 대신 이를 명확하게 설명하는 올바른 이름 지정입니다. 또는 애플리케이션의 해당 기능.

12. 잘못된 이름

종종 초보자는 클래스, 변수, 메서드 등의 이름을 위조합니다. 예를 들어 이름이 목적을 전혀 설명하지 않는 클래스를 만드는 경우입니다. 또는 x 와 같은 짧은 이름으로 변수가 생성되고 , n 및 y 라는 두 개의 변수가 더 생성되면 x 가 수행하는 작업을 기억하기가 매우 어려워집니다 . 그러한 경우, 코드에서 무슨 일이 일어나고 있는지 간단히 이해하려면 코드에 대해 신중하게 생각하고 현미경으로(아마도 디버거를 사용하여) 이 기능을 연구해야 합니다. 여기서 위에서 언급한 코드의 올바른 이름이 도움이 됩니다. 올바른 이름은 코드의 가독성을 높여서 이름이 해당 기능을 대략적으로 설명하는 방법을 사용하는 것이 훨씬 쉽기 때문에 익숙해지는 데 드는 시간을 절약합니다. 코드에서 모든 것은 이름(변수, 메소드, 클래스, 파일 객체 등)으로 구성되며, 이 점은 정확하고 깔끔한 코드를 작성할 때 매우 중요합니다. 이름은 의미(예: 변수가 존재하는 이유, 기능 및 사용 방법)를 전달해야 한다는 점을 기억할 가치가 있습니다. 그리고 변수를 설명하는 가장 좋은 설명은 변수의 정확한 이름이라는 점을 계속해서 언급할 것입니다. 주석과 올바른 이름 지정에 대한 더 깊은 연구를 위해서는 시대를 초월한 고전인 “클린 코드. 생성, 분석 및 리팩토링”, Robert Martin . 이로써 이 글의 첫 번째 부분(반성)이 끝났습니다. 계속…