초보 프로그래머가 저지르는 일반적인 실수 분석, pt. 1

안녕, 세상! 알아야 할 모든 것을 배우고 마침내 인턴 또는 주니어 개발자로 일하게 되면 긴장을 풀 수 있을 것입니다. 아니요. 당신을 위한 모든 것이 이제 막 시작되었습니다... 당신은 새롭고 이해할 수 없는 많은 것들에 둘러싸여 있습니다. 게이트에서 바로 그것을 망치지 않는 방법은 무엇입니까? 그것이 오늘 우리가 이야기할 내용입니다. 이 기사에서는 일반적인 신인 실수를 분석하고 내 경험을 바탕으로 이를 피하는 방법에 대한 조언을 제공하고자 합니다. 이제 더 이상 고민하지 않고 시작하겠습니다.

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

우리는 모두 인간입니다. 우리 모두는 특히 경험이 많은 새로운 동료의 눈에 어리석게 보일까봐 두려워합니다. 개발자가 첫 직장을 맡을 때 그들은 종종 이러한 두려움에 이끌려 무거운 마음으로 스스로 물러나 모든 것을 스스로 알아 내려고 노력합니다. 또한 경험이 많은 동료들에게 둘러싸일 수 있으며, 그 동료들은 그에게 가장 유망한 방향을 제시할 수 있으므로 더 많은 실수와 불필요한 "머리 부딪힘"을 방지할 수 있습니다. 그러니 기억하세요. 질문하는 것을 두려워하지 마세요. 당신은 초보자이고 모두가 이것을 완벽하게 잘 이해합니다. 당신이 묻는다면 아무도 당신을 막대기로 때리지 않을 것입니다. 아마도 그 반대도 일어날 것입니다. 동료들과 더 빨리 친구가 되고 그들과 더 활발한 의사소통을 즐기기 시작할 것입니다. 나' 더 말씀드리자면, 다양한 기술적인 문제에 대해 더 많이 묻고 논의할수록 더 빨리 초라한 초보의 껍질을 벗고 해당 분야의 전문가로 성장할 수 있을 것입니다. 그리고 조언 하나 더. 낯선 사람이 되지 마세요스택오버플로 . 특히 이 리소스에 대한 질문에 대해 이야기하고 있습니다. 한편으로는 귀하의 질문에 대한 답변을 얻는 데 시간이 걸립니다. 그러나 다른 한편으로는 문제를 해결하기 위한 여러 접근 방식을 빠르게 배우고 약간 다른 각도에서 볼 수 있습니다. 또한 댓글/답변을 작성하고 다른 개발자의 StackOverflow 질문에 대한 명확한 질문을 작성하면 실용적인 이점이 있다는 점에 주목하고 싶습니다. 카르마 부스트는 말할 것도 없고 문제에 대해 토론하고 더 깊이 파고들 수 있는 기회를 얻게 됩니다.

2. 스스로 정보를 찾으려 하지 않는다

이 실수는 이전 실수의 반전으로 간주될 수 있습니다.여기서 나는 당신이 만나는 모든 문제나 딸꾹질에 대해 동료와 지인을 괴롭히기 시작할 때를 의미합니다. 질문하는 것은 좋지만 지나치게 질문하지 마십시오. 그렇지 않으면 사람들이 당신을 짜증나게 할 수도 있습니다. 무언가에 대해 혼란스럽다면 가장 먼저 할 일은 최고의 검색 엔진인 Google에서 검색 기술을 연습하는 것입니다. 다른 사람은 이미 이해할 수 없는 오류 및 기타 문제의 압도적 다수를 경험했습니다. 그리고 당신이 당신의 질문을 구글링하고 비슷한 문제에 대해 잘 알고 있고 당신의 작업에 적용할 수 있는 철저한 답변을 이미 받은 사람들의 수를 보면 상당히 놀랄 것입니다. 그렇기 때문에 동료들이 "Google it"이라고 대답하는 것을 자주 듣게 될 것입니다. 두목' 이 답변에 기분이 상하지 마십시오. 귀하의 동료는 귀하의 작업 분야의 모든 미묘함을 전달해야 하는 개인 교사가 아닙니다. 끝없이 펼쳐지는 인터넷이 당신의 멘토가 될 것입니다. 때때로 프로그래머는 다음과 같이 불리기도 합니다.Google 검색에서 블랙 벨트를 가진 사람 . 따라서 "딸꾹질"이 발생하면 먼저 문제를 Google에 검색합니다. 솔루션을 찾을 수 없는 경우(드문 경우이지만 발생함) 그제서야 동료에게 묻기 시작합니다. 즉각적인 질문은 과속 방지턱이나 이해할 수 없는 오류 메시지를 만났을 때 무엇을 하느냐보다 문제를 해결하기 위해 어떤 접근 방식을 선택해야 하는지에 대한 조언을 얻기 위한 것입니다. 결국, 그들은 당신이 선호하는 접근 방식 이상을 볼 수 있고 주어진 접근 방식이 장기적으로 어디로 이어질지 즉시 예측할 수 있습니다.

3. 맹목적으로 복사하여 붙여넣기

그러나 인터넷 검색 문제와 그 솔루션에는 함정이 있습니다. 예를 들어 맹목적으로 복사하여 붙여넣기 .일반적으로 StackOverflow에서 유사한 문제(정확히 동일하지는 않을 수 있음) 및 관련 솔루션을 찾을 때 발생합니다. 세부 사항을 더 자세히 살펴보지 않고 이 솔루션을 잡고 복사하여 붙여넣습니다. 그런 다음 귀하 또는 귀하의 동료가 귀하의 코드에서 이상한 버그나 잘못된 동작을 발견합니다. 그리고 아무도 그들이 어디에서 왔는지 즉시 추측할 수 없습니다. 물론 결국에는 복사된 코드가 있는 곳을 찾게 될 것이고, 당신은 당신의 솔루션에 대해 절대 칭찬받지 못할 것입니다. 따라서 StackOverflow(또는 다른 곳)에서 미리 만들어진 솔루션을 찾으면 먼저 무엇을, 어떻게, 왜를 철저히 이해해야 합니다. 관련 기능을 Google에서 검색하고 관련 문서를 읽을 수 있습니다. 그리고 이를 완료한 후에만 프로젝트에 추가해야 합니다.

4. 잘못된 솔루션 고수

솔루션을 작성할 때 때때로 솔루션이 계속해서 점점 더 복잡해지고 결국 막다른 골목에 도달하는 것을 발견하게 될 것입니다. 그런 다음 더 적합한 다른 대안을 찾는 대신 어떻게든 작동하도록 솔루션을 더욱 정교하게 만들려고 합니다. 어쩌면 당신은 많은 시간과 노력을 투자한 것처럼 느껴져서 무슨 일이 있어도 포기하지 않고 기존 접근 방식으로 문제를 해결하기로 결정했을 것입니다. 이것은 올바른 태도가 아닙니다. 적어도 프로그래밍에서는. 다른 접근 방식을 빨리 시도할수록 결국 더 많은 시간을 절약할 수 있습니다. 따라서 현재 접근 방식에 투자한 시간에 관계없이 실험하고 다른 접근 방식을 시도하는 것을 두려워하지 마십시오. 또한 다양한 접근 방식을 시도하고 주제에 대해 더 깊이 파고들면

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

소프트웨어 개발 프로젝트 작업은 일반적으로 특정 작업을 수행하는 것으로 귀결됩니다. 예를 들어 Jira 에서. 이러한 작업이 항상 명확하고 자세하게 설명되는 것은 아닙니다. 작업 설명은 일반적으로 단순한 인간이기도 한 팀 리더가 작성합니다. 그들은 무언가를 추가하는 것을 잊거나 귀하가 이것 또는 저 기능에 익숙하지 않다는 사실을 설명하지 못할 수 있습니다. 또는 프로젝트에 대한 액세스 권한이 없을 수도 있습니다(예: 데이터베이스, 로그 서버 등에 대한 액세스 권한). 이제 작업을 받고 몇 시간 이상 연구했지만 여전히 당황하여 화면을 응시하고 있습니다. 계속해서 이를 이해하려고 시도하는 대신 작업을 만든 사람에게 설명이나 지침을 요청하기 시작해야 합니다. 예를 들어 팀이 커뮤니케이션에 사용하는 앱(예: Microsoft Teams)에서 작업에 대해 질문하거나 직접적인 의견을 제시할 수 있습니다. 한편으로 개인 메시지에 질문을 작성하면 그 사람이 질문을 즉시 볼 수 있기 때문에 더 빨리 답변을 얻을 수 있습니다. 반면에 Jira에서 질문을 함으로써 당신이 무엇인가를 하고 있다는 증거, 즉 문제를 분석하고 있다는 증거를 확립하게 됩니다. 이 프로세스를 가속화할 수 있는 방법이 있습니다. Jira의 댓글에 질문을 한 다음 DM에 댓글에 대한 링크를 드롭하고 살펴보도록 요청하세요.

6. 팀장에게 비현실적으로 높은 기대를 걸기

다시 말하지만 이것은 이전 요점의 반대편입니다. 팀장은 개발팀의 책임자입니다. 일반적으로 팀 리더는 대부분의 시간을 다양한 종류의 커뮤니케이션에 사용합니다. 그러나 그 또는 그녀는 또한 프로그래밍에 대한 모든 것을 잊지 않기 위해 코드를 작성합니다. 아시다시피 팀 리더의 삶은 매우 바쁩니다. 재채기가 필요할 때마다 팀 리더의 소매를 잡아당기는 것은 당연히 기분 좋은 일이 아닙니다. 팀의 모든 구성원이 많은 질문으로 리드를 공격한다고 상상해보십시오. 그것은 누군가를 미치게 만들 수 있습니다, 그렇죠? 그리고 질문이 많으면 팀 리더가 답변하는 데 많은 시간을 할애해야 합니다. 팀 리더에게 전달되는 질문의 수를 줄이기 위해 수행할 수 있는 작업:

• 맹점의 수를 줄이기 위해 프로젝트 문서를 더 자세히 살펴보십시오.
• 질문을 다른 팀원에게 전달하십시오. 그들 중 한 명이 기능을 작성했을 가능성이 높기 때문에 리드만큼 또는 그 이상으로 이 기능에 익숙할 수 있습니다.

또는 IDE에서 특정 줄의 코드가 마지막으로 변경된 사람과 시간에 대한 주석을 볼 수 있습니다. 당신의 질문에 가장 적합한 사람이 누구인지 정확히 알아낼 수 있는 방법입니다. 이미 알고 계시겠지만, 팀 리더에게 질문할 때는 동료에게 질문할 때와 마찬가지로 행복한 매체를 찾으려고 노력해야 합니다. 질문하는 것을 두려워하지 말고 너무 많이 질문하지도 마세요. 그들의.

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

코드 리뷰공통 애플리케이션(예: 마스터 또는 개발과 같은 공유 분기)에 코드를 제출하기 전에 발생하는 단계입니다. 이 검사는 작업에 관여하지 않은 개발자가 수행하며, 개발자의 새로운 눈은 처음 코드를 작성할 때 발견되지 않은 코드 스타일의 오류, 부정확성 또는 결함을 감지할 수 있습니다. 비판이 있는 경우 코드의 특정 부분에 대한 주석으로 남습니다. 이 경우 코드를 작성한 개발자는 검토에서 식별된 오류를 수정해야 합니다(또는 검토자와 자신의 결정을 논의하여 수정 사항이 옳다고 확신시킬 수 있음). 그런 다음 검토자가 더 이상 의견이 없을 때까지 검토를 위해 코드를 반복해서 제출합니다. 검토자는 코드가 커밋되기 전에 "게이트웨이" 역할을 합니다. 문제는 많은 초보 프로그래머가 코드 검토를 비판과 비난으로 인식한다는 것입니다. 그들은 코드 리뷰를 좋아하지 않고 두려워합니다. 그렇게 해서는 안 됩니다. 코드 리뷰는 우리가 코드를 개선할 수 있게 해주는 것입니다. 결국, 우리는 우리가 잘못하고 있는 것과 주의를 기울일 가치가 있는 것에 대한 중요한 정보를 얻습니다. 각 코드 검토를 학습 곡선의 일부로 생각해야 합니다. 누군가 당신의 코드에 댓글을 달면 그 사람은 경험과 모범 사례를 당신과 공유하고 있는 것입니다. 저는 개인적으로 코드 리뷰를 받지 않고 좋은 프로그래머가 될 수 있다고 생각하지 않습니다. 코드의 품질과 숙련된 외부인이 실수를 지적할지 여부조차 알지 못하기 때문입니다. 코드 리뷰를 좋아하고 두려워하지 않습니다. 그렇게 해서는 안 됩니다. 코드 리뷰는 우리가 코드를 개선할 수 있게 해주는 것입니다. 결국, 우리는 우리가 잘못하고 있는 것과 주의를 기울일 가치가 있는 것에 대한 중요한 정보를 얻습니다. 각 코드 검토를 학습 곡선의 일부로 생각해야 합니다. 누군가 당신의 코드에 댓글을 달면 그 사람은 경험과 모범 사례를 당신과 공유하고 있는 것입니다. 저는 개인적으로 코드 리뷰를 받지 않고 좋은 프로그래머가 될 수 있다고 생각하지 않습니다. 코드의 품질과 숙련된 외부인이 실수를 지적할지 여부조차 알지 못하기 때문입니다. 코드 리뷰를 좋아하고 두려워하지 않습니다. 그렇게 해서는 안 됩니다. 코드 리뷰는 우리가 코드를 개선할 수 있게 해주는 것입니다. 결국, 우리는 우리가 잘못하고 있는 것과 주의를 기울일 가치가 있는 것에 대한 중요한 정보를 얻습니다. 각 코드 검토를 학습 곡선의 일부로 생각해야 합니다. 누군가 당신의 코드에 댓글을 달면 그 사람은 경험과 모범 사례를 당신과 공유하고 있는 것입니다. 저는 개인적으로 코드 리뷰를 받지 않고 좋은 프로그래머가 될 수 있다고 생각하지 않습니다. 코드의 품질과 숙련된 외부인이 실수를 지적할지 여부조차 알지 못하기 때문입니다. 다시 잘못하고주의를 기울일 가치가있는 것. 각 코드 검토를 학습 곡선의 일부로 생각해야 합니다. 누군가 당신의 코드에 댓글을 달면 그 사람은 경험과 모범 사례를 당신과 공유하고 있는 것입니다. 저는 개인적으로 코드 리뷰를 받지 않고 좋은 프로그래머가 될 수 있다고 생각하지 않습니다. 코드의 품질과 숙련된 외부인이 실수를 지적할지 여부조차 알지 못하기 때문입니다. 다시 잘못하고주의를 기울일 가치가있는 것. 각 코드 검토를 학습 곡선의 일부로 생각해야 합니다. 누군가 당신의 코드에 댓글을 달면 그 사람은 경험과 모범 사례를 당신과 공유하고 있는 것입니다. 저는 개인적으로 코드 리뷰를 받지 않고 좋은 프로그래머가 될 수 있다고 생각하지 않습니다. 코드의 품질과 숙련된 외부인이 실수를 지적할지 여부조차 알지 못하기 때문입니다.

8. 난해한 결정을 내리는 경향

다양한 작업/문제에는 종종 여러 가지 솔루션이 있을 수 있습니다. 그리고 사용 가능한 모든 솔루션 중에서 초보자는 가장 복잡하고 난해한 솔루션을 사용하는 경향이 있습니다. 그리고 그것은 의미가 있습니다. 초보 프로그래머는 어제 많은 다른 알고리즘, 패턴 및 데이터 구조를 배웠기 때문에 그들의 손이 그들 중 일부를 구현하기 위해 근질근질합니다. 날 믿어, 내가 그랬으니까 무슨 말인지 알겠어 :) 오랫동안 어떤 기능을 구현하는 상황이 있었어. 그것은 매우 매우 복잡한 것으로 밝혀졌습니다. 그런 다음 수석 개발자가 내 코드를 다시 작성했습니다. 물론, 나는 그가 무엇을 어떻게 바꾸었는지 매우 흥미로웠다. 나는 그의 구현을 보았고 그것이 얼마나 간단했는지에 놀랐습니다. 그리고 3배 적은 코드가 있었습니다. 또한 놀랍게도 이 기능에 대한 자동화된 테스트는 제거되거나 변경되지 않았습니다! 즉, 일반적인 논리는 동일하게 유지되었습니다. 이것으로부터 나는 다음과 같은 결론에 도달했습니다.가장 독창적인 솔루션은 항상 간단합니다 . 이 깨달음 이후 코딩이 훨씬 쉬워졌고 코드 품질이 훨씬 더 높아졌습니다. 그렇다면 디자인 패턴과 멋진 알고리즘을 적용하는 것이 언제 가치가 있느냐고 묻습니다. 그것들을 적용하면 가장 간단하고 가장 컴팩트한 솔루션이 될 것입니다.

9. 바퀴의 재창조

휠은 오래 전에 발명된 내구성 있는 솔루션입니다. 이 안티 패턴에서 개발자는 이미 해결된 문제에 대해 자신의 독점 솔루션을 구현합니다. 때로는 이러한 기존 솔루션이 프로그래머가 제시하는 것보다 낫습니다. 일반적으로 바퀴를 재발명하면 시간을 낭비하고 생산성이 저하됩니다. 찾은 솔루션이 최고가 아닐 수도 있고 전혀 찾지 못할 수도 있기 때문입니다. 즉, 우리는 우리 자신의 독립적인 솔루션을 만들 가능성을 배제할 수 없습니다. 만약 우리가 만들었다면 남은 것은 복사 및 붙여넣기 프로그래밍뿐입니다. 프로그래머는 기성 솔루션을 사용하든 맞춤형 솔루션을 생성하든 문제를 유능하고 신속하게 해결하기 위해 발생하는 특정 프로그래밍 작업에 따라 적절하게 안내를 받아야 합니다. 한편으로는, 대학과 온라인 과정에서 우리는 바퀴를 재발명하는 데 도움이 되도록 고안된 것처럼 보이는 다양한 종류의 작업으로 폭격을 받습니다. 그러나 언뜻 보면 여기의 진정한 목적은 알고리즘 사고를 개발하고 언어 구문을 더 깊이 숙달하는 것입니다. 이러한 작업은 또한 알고리즘과 데이터 구조를 더 잘 이해하는 데 도움이 되며 필요한 경우 보다 정교한 상대를 구현하는 기술을 제공합니다(이는 때때로 필요하지만 매우 드뭅니다). 실생활에서는 대부분의 경우 자신의 바퀴를 발명할 필요가 없습니다. 귀하의 요구를 충족하는 바퀴가 오랫동안 사용되어 왔기 때문입니다. 아마도 귀하의 경험 부족으로 인해 필요한 기능 구현의 존재에 대해 알지 못할 수 있습니다. 여기에서 이 기사의 첫 번째 요점, 즉, 경험 많은 동료에게 도움을 요청하십시오. 그들은 귀하를 안내하거나(예: Google 검색에서 올바른 방향으로 안내) 특정 구현(예: 일부 라이브러리)을 제안할 수 있습니다.

10. 테스트 작성 실패

모든 초보자는 쓰기 테스트를 싫어합니다. 그런데 왜 여기서 뉴비를 뽑아야 할까요? 노련한 개발자도 테스트 작성을 좋아하지 않지만 테스트가 필요한 이유를 더 잘 이해합니다. 당신이 완전히 친환경적일 때 당신은 왜 그것들을 써야 하는지 의아해할 것입니다. 모든 것이 작동하므로 실수가 있을 수 없습니다. 그러나 변경 사항이 시스템의 다른 곳에서 손상되지 않도록 어떻게 보장합니까? 득보다 실이 많은 변경 사항을 적용하면 동료가 고마워하지 않을 것입니다. 이것은 테스트가 우리를 구출하는 곳입니다. 애플리케이션의 코드가 테스트에 의해 더 많이 커버될수록 더 좋습니다(이를 코드 커버리지 또는 테스트 커버리지라고 함). 응용 프로그램의 테스트 범위가 양호하면 모든 테스트를 실행하여 코드에 의해 손상될 위치를 찾을 수 있습니다. 그리고 위의 예에서 말했듯이, 수석 개발자가 코드를 리팩터링했을 때 테스트는 실패하지 않았습니다. 일반적인 논리가 바뀌지 않았기 때문입니다. 테스트를 사용하여 특정 기능의 논리가 변경되었는지 여부를 보여줍니다. 따라서 테스트 작성을 좋아하지 않더라도 확실히 유용하고 시간을 투자할 가치가 충분히 있습니다.

11. 과도한 댓글

많은 개발자들이 완벽주의에 시달립니다. 초보자도 예외는 아닙니다. 그들은 때때로 모든 사람과 모든 것에 대해 언급하기 시작할 때 이러한 성향의 한 측면만을 나타냅니다. 코드가 너무 명확하기 때문에 불필요한 주석을 만드는 것조차:

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

불필요한 주석이 코드를 어지럽히고 읽기 어렵게 만들기 때문에 모든 초보 프로그래머가 코드에 주석을 다는 것이 항상 좋은 것은 아니라는 사실을 즉시 깨닫는 것은 아닙니다. 코드가 변경되었지만 이전 주석이 업데이트되지 않으면 어떻게 될까요? 그러면 그들은 우리를 오도하고 혼란스럽게 할 것입니다. 그럼 도대체 왜 그런 댓글을 다는 걸까요? 일반적 으로 잘 작성된 코드는 주석을 달 필요가 없습니다 . 코드의 모든 내용이 이미 명확하고 읽기 쉽기 때문입니다. 주석을 작성해야 한다면 이미 코드의 가독성을 손상시켰고 어떻게든 상황을 해결하려고 노력하고 있는 것입니다. 가장 좋은 방법은 처음부터 읽기 쉬운 코드, 즉 주석이 필요하지 않은 코드를 작성하는 것입니다. 또한 메서드, 변수 및 클래스에 대한 올바른 명명 규칙을 따라야 할 필요성을 언급하지 않을 수 없습니다. 내 규칙은 다음과 같습니다. 최고의 주석은 주석이 없거나 응용 프로그램의 기능을 명확하게 설명하는 올바른 이름입니다.

12. 잘못된 이름 지정

초보자는 클래스, 변수, 메서드 등의 이름을 빠르고 느슨하게 지정합니다. 예를 들어 이름이 목적을 전혀 설명하지 않는 클래스를 생성합니다. 또는 x 와 같은 짧은 이름으로 변수를 선언합니다 . 그들은 n 과 y 라는 두 개의 변수가 더 있을 때x가 무엇을 담당하는지 기억하는 것이 매우 어려워집니다. 이 상황에 직면하면 코드에 대해 신중하게 생각하고 현미경으로 코드를 분석하고(아마도 디버거 사용) 무슨 일이 일어나고 있는지 이해하기 위해 기능을 연구해야 합니다. 여기서 위에서 언급한 올바른 명명 규칙이 도움이 됩니다. 올바른 이름은 코드 가독성을 향상시켜 코드에 익숙해지는 데 필요한 시간을 줄입니다. 이름이 해당 기능을 대략적으로 설명할 때 메서드를 사용하는 것이 훨씬 더 쉽기 때문입니다. 코드의 모든 것은 이름(변수, 메서드, 클래스, 개체, 파일 등)으로 구성되므로 올바르고 깔끔한 코드를 만들 때 이 점이 매우 중요합니다. 예를 들어 변수가 존재하는 이유, 변수가 하는 일, 그리고 그것이 어떻게 사용되는지. 변수에 대한 가장 좋은 설명은 좋은 이름을 지정하는 것임을 한 번 이상 언급하겠습니다. 주석과 올바른 이름 지정에 대한 더 깊은 연구를 위해 시대를 초월한 고전을 읽는 것이 좋습니다."Clean Code: A Handbook of Agile Software Craftsmanship" 저자 Robert Martin . 참고로 이 기사의 첫 번째 부분(나의 반성)은 끝났습니다. 계속하려면...