커피 브레이크 #43. 꿈의 직업을 얻지 못하게 만드는 6가지 프로그래밍 실수 처음으로 오픈 소스 소프트웨어에 기여하는 방법

꿈의 직업을 얻지 못하게 만드는 6가지 프로그래밍 실수

출처: Medium 프로그래머로 일자리를 찾으려면 Git 저장소가 필요합니다. 채용 담당자가 가장 먼저 살펴보는 사항 중 하나입니다. 저장소가 긍정적인 인상을 주려면 최근 변경된 프로젝트가 포함되어 있어야 합니다. 지금까지 작성한 모든 코드 줄이 아닌 자랑스러운 프로젝트만 표시하세요. 이것이 저장소 작업의 기본입니다. 조만간 누군가가 귀하의 코드를 보고 귀하가 회사에 적합한지 확인할 것이라는 점을 기억하십시오. 이것은 당신에게 결정적인 순간이 될 것입니다. 몇 분 후에 채용 담당자가 귀하를 인터뷰에 초대할지 여부를 결정할 것입니다. 그리고 여기에는 좋은 소식과 나쁜 소식이 모두 있습니다. 나쁜 소식은 단순한 실수가 취업 가능성을 해칠 수 있다는 것입니다. 좋은 소식은 사람들이 일반적으로 코드를 깊이 파고들고 싶어하지 않는다는 것입니다. 코드와 아키텍처에 대한 일반적인 이해가 필요합니다. 따라서 천재가 될 필요는 없습니다. 단지 좋은 프로그래머가 되기만 하면 됩니다. 초보자들이 저지르는 흔한 실수는 다음과 같습니다. 이를 피하면 면접 기회가 극적으로 늘어날 것입니다.

오래된 댓글

프로그래머는 댓글에 대해 서로 다른 의견을 가지고 있습니다. 어떤 사람들은 그들을 사랑하고 다른 사람들은 그들을 싫어합니다. 우리는 코드에 주석을 달 만한 가치가 있는지, 어떤 경우에 주석을 달아야 하는지에 대해 공통된 결론을 내릴 수 없습니다. 하지만 모두가 한 가지에 대해서는 만장일치로 의견을 같이 합니다. 의견이 있으면 코드와 일치해야 한다는 것입니다. 코드를 설명하기 위한 주석이 있습니다. 코드가 복잡하거나 명확하지 않은 경우 독자가 코드를 이해하는 데 도움이 필요합니다. 또한 코드를 변경할 때 설명도 변경해야 합니다. 이렇게 하지 않으면 귀하의 의견은 더 이상 유용하지 않습니다. 나쁜 댓글은 댓글이 없는 것보다 훨씬 나쁩니다. 설상가상으로 코드에서 주석이 강조 표시됩니다. 최신 IDE는 읽기 쉽도록 주석을 다른 색상으로 강조 표시합니다. 주석을 추가하면 코드에 "읽어주세요" 기호가 표시됩니다. 이렇게 하면 주석과 코드 사이의 불일치를 쉽게 감지할 수 있습니다. 댓글을 현명하게 선택하고 코드와 함께 업데이트하는 것을 잊지 마세요. 이렇게 하면 그들은 당신에게 잘 봉사할 것입니다.

동일한 사용 사례를 가진 라이브러리와 언어의 조합

1차 면접을 앞두고 채용 문제를 해결해야 했습니다. 간단한 웹 앱이었기 때문에 코드를 작성하고, 몇 가지 복잡한 질문을 구글링했더니 앱이 준비되었습니다. 인터뷰 중에 채용 담당자는 코드 전반에 걸쳐 jQuery 코드와 일반 JavaScript를 혼합한 이유를 물었습니다. 내 대답은? “음...” 솔직히 말하면 Stack Overflow에서 몇 가지 코드 조각을 붙여넣었습니다. 나는 그것에 대해 많이 생각하지 않았습니다. 코드가 작동했기 때문에 계속 진행했습니다. 이 오류는 새로운 개발자들 사이에서 매우 일반적입니다. 우리는 직장에서 문제를 해결하는 데 너무 집중한 나머지 그것을 어떻게 하는지에 주의를 기울이지 않습니다. 이 함정에 빠지는 초보자 중 하나가 되지 마십시오. 각 코드 줄을 검토하고 해당 코드를 왜 거기에 넣었는지 확인하세요.

코드 반복

Don't Repeat Yourself(DRY)는 프로그래밍 교리입니다. 반복되는 코드에 대한 추상화를 만드는 것이 프로그래밍의 핵심입니다. 네, 처음에는 어려울 수 있습니다. 문제를 해결하고 싶을 때는 가능한 모든 방법으로 해결합니다. 그런 다음 다른 작업으로 넘어가면 반복적인 코드가 그대로 유지됩니다. 스스로 규칙을 만들어서 이러한 습관을 없앨 수 있습니다. 기능을 개선할 때마다 코드를 다시 읽고 이를 변경하기 위해 할 수 있는 일이 있는지 확인하세요. 코드의 첫 번째 버전은 일반적으로 잘못되었으며 이를 개선할 수 있다는 점을 기억하세요. 중복된 코드를 발견하면 시간을 내어 연구해 보세요. 이렇게 하면 코드를 다시 작성하는 가장 좋은 방법(예: 루프 사용 또는 새 함수 생성)을 알아낼 수 있습니다. 매번 이렇게 정리하면 더욱 안정적이고 우아한 코드가 완성될 것입니다.

처리되지 않은 오류

항상 완벽하게 작동하는 의미 있는 애플리케이션을 만드는 것은 거의 불가능합니다. 데이터베이스를 채우거나 API를 호출하는 경우 오류가 발생합니다. 처리되지 않은 오류로 인해 개별 기능의 실행이 중단될 뿐만 아니라 전체 애플리케이션이 중단될 수도 있습니다. 가능한 오류를 예상하는 것은 유능한 프로그래머의 표시입니다. 외부 데이터에 액세스하거나 업데이트할 때마다 최악의 시나리오에 대비해야 합니다. 애플리케이션을 다루기 어렵게 만들지 않는 방식으로 잠재적인 문제에 플래그를 지정합니다. 이렇게 하면 코드를 읽는 독자(그리고 아마도 여러분)가 오류를 빠르게 찾을 수 있습니다. 또한 응집력 있는 코드를 작성할 수 있다는 점을 채용 담당자에게 보여줄 것입니다.

일관성 부족

일관성은 고품질 소프트웨어의 특징입니다. 코드를 더 쉽게 읽고 유지 관리할 수 있습니다. 통일된 스타일로 작성된 코드는 예측 가능성이 더 높으며 프로그램 성능을 평가하기가 더 쉽습니다. 더 높은 수준의 추상화에서는 일관성을 달성하기가 어렵습니다. 이를 익히는 데는 수년이 걸리므로 가능한 한 빨리 이 기술을 배우기 시작해야 합니다. 하나의 언어만 사용하여 제목을 만드는 것을 잊지 마세요. 아마도 영어여야 하지만 개인 프로젝트에서는 항상 동일한 언어라면 어떤 언어로든 변수와 함수의 이름을 지정할 수 있습니다. 일관성이 있다면 탭을 사용하든 공백을 사용하든 상관없습니다. 스타일 가이드를 만들거나 선택하고 항상 이를 준수하세요. Prettier 와 같은 도구도 사용해야 합니다 . 일관된 방식으로 코드 형식을 유지하는 것이 정말 도움이 됩니다. 어떤 도구와 스타일을 사용하든 일관되게 사용하세요. 일관된 스타일로 나쁜 코드를 작성하더라도 일반적으로 수정하기가 훨씬 쉽기 때문에 일관되지 않은 좋은 코드보다 낫습니다.

도구에 대한 오해

일반적인 프로젝트에서는 아마도 일부 외부 라이브러리를 사용해야 할 것입니다. 많은 프로그래머는 라이브러리가 모든 프로젝트에서 사용되기 때문에 거의 자동으로 설치합니다. 외부 라이브러리는 반복되는 문제를 해결하는 입증된 방법이기 때문에 훌륭합니다. 그러나 새로운 개발자는 자신이 어떤 라이브러리를 사용하고 있는지 이해하지 못하고 결국 다른 라이브러리 위에 하나의 라이브러리를 추가하거나 일부 기존 기능을 다시 구현하게 되는 경우가 많습니다. 프로젝트에 라이브러리를 설치할 때마다 문서를 읽거나 적어도 보십시오. 사용할 수 있는 방법과 속성을 확인하고 라이브러리가 해결해야 하는 문제와 다른 도구를 사용해야 하는 문제를 이해했는지 확인하세요. 이렇게 하면 작업에 적합한 도구를 선택하고 선택 사항을 설명할 수 있습니다.

처음으로 오픈 소스 소프트웨어에 기여하는 방법

출처: Jamestucker.dev 얼마 전 Evan Yu( Vue.js 제작자 )가 작업 중인 새 저장소에 대한 트윗을 보고 관심을 갖게 되었습니다. 나는 그것에 기여하고 싶다고 결정했습니다! 문제는 제가 이전에 오픈 소스 프로젝트에 기여한 적이 없고 어디서부터 시작해야 할지 몰랐다는 것입니다. 하지만 그렇게 어려울 수는 없겠죠? 저장소에 들어가자마자 나는 즉시 얼어붙었습니다. “도대체 어떻게 해야 하지?” 나는 속으로 생각했다. PR(풀 요청, 병합 요청)을 하면 전문가가 내 코드를 조각조각 찢을 것입니다. 나는 개발 세계에서 항상 오픈 소스를 제대로 사용하는 방법을 모르는 사람으로 알려질 것입니다. 그리고 내 경력은 끝날 것입니다. 다행스럽게도 나는 다른 사람의 저장소에 대한 첫 번째 기여는 가능한 한 신중해야 한다고 저자가 조언한 기사(어디인지 기억나지 않음)를 읽었습니다. 이는 오타를 수정하는 것만큼 간단한 것일 수 있습니다. 그래서 나는 그렇게 했습니다. 나는 저장소 문서를 읽고, 몇 가지 오타를 발견하고, PR을 열었고, 그런데 보라, Evan이 내 변경 사항을 승인했습니다. 저는 공식적으로 Vue 기여자입니다! 어쩌면 이것을 내 트위터 자기소개에 넣어야 할까요?

"좋네요. 그런데 어떻게 시작하나요?"

자, 시작해 보겠습니다. 변화를 만들기 위해 취할 수 있는 단계를 보여 드리겠습니다.

1. 프로젝트 찾기

영감을 얻으려면 가장 좋아하는 기술이나 도구에 대해 생각해 보세요. JavaScript로 작업하고 Gatsby를 많이 사용한다고 가정해 보겠습니다 . 그들의 저장소를 확인해 보세요 ! 내 저장소 중 하나에 기여할 수도 있습니다. 내 프론트엔드 프로젝트 목록 은 다음과 같습니다 . 마음에 드는 내용이나 유용하다고 생각되는 내용이 있으면 추가해 주시면 좋겠습니다! 마지막으로 Awesome First PR Opportunities는 초보자를 위한 오픈 소스 프로젝트의 거대한 저장소입니다. 22개 언어로 된 프로젝트가 있습니다!

2. 어떻게 기여할 수 있는지 결정하세요

프로젝트를 확인해 보세요. 읽어보기를 읽어보세요. 다양한 폴더와 파일을 스캔하세요. 코드베이스의 구조를 이해합니다. 이렇게 하면 오타를 쉽게 찾아서 수정할 수 있어요! 그런 다음 프로젝트의 이슈 섹션을 살펴보세요. 여기에서 이전에 발견된 버그 또는 제안된 기능 목록을 찾을 수 있습니다. 다행히도 많은 프로젝트에는 초보자를 대상으로 한 문제가 포함되어 있습니다. 첫 번째 기여는 최대한 미묘해야 한다고 생각합니다. 그러나 빨리 인정받고 싶다면 그것은 당신에게 달려 있습니다. 프로젝트에 추가할 수 있는 항목을 찾으면 이를 분기해야 합니다.

3. 프로젝트 포크 생성

포크(프로젝트 포크)는 자신의 Github 저장소에 정확한 복사본을 생성합니다.

4. 프로젝트를 로컬에서 복제

그런 다음 프로젝트 URL을 사용하여 프로젝트를 로컬 폴더에 복제합니다.

git clone <project-url>

여기에서 URL을 찾을 수 있습니다. 이제 프로젝트가 컴퓨터에 있으므로 편집기에서 엽니다. 변경하는 데 시간이 걸릴 것이라고 생각되면 프로젝트 사본을 원본과 동기화하여 항상 변경 사항을 알 수 있도록 하세요. 이에 대한 정확한 Git 명령은 여기에서 찾을 수 있습니다 .

5. 변경 사항에 대한 새 분기를 만듭니다.

이제 변경/수정을 할 시간입니다! 변경 사항을 적용할 새 분기를 만듭니다.

git branch <branch-name>

원하는 대로 부를 수 있지만 내 경험에 따르면 원래 프로젝트에서 분기 이름을 지정하는 패턴을 볼 수 있습니다. 이 경우 기존 템플릿을 따르는 것이 좋습니다. 오타를 수정하기 위한 좋은 브랜치 이름은 patch/typo-fix 입니다 . git checkout <branch-name> 을 사용하여 이 분기로 전환할 수 있습니다 . 이제 변경하세요!

6. PR 열기(병합 요청)

따라서 눈에 띄는 오타를 수정했거나 깨진 링크를 업데이트했습니다. 당신은 당신의 일에 자부심을 느낍니다. 당신은 코딩하고 삭제하고 Netflix를 시청할 수 있는 신화적인 개발자 중 한 명이라는 사실을 전 세계에 알리고 싶습니다. git push -u Origin <branch-name> 을 사용하여 변경 사항을 분기된 Github 저장소에 푸시하세요 . 포크된 Github 저장소로 이동하여 PR(풀 요청)을 엽니다. 참고: 이전에 끌어오기 요청을 한 번도 해본 적이 없다면 Kent Dodds의 동영상을 시청하여 수행 방법을 알아보세요. 브랜치가 소스 리포지토리의 마스터 브랜치를 가리키는지 확인하세요. 이제 PR에 세부정보를 추가할 준비가 되었습니다. 헤드라인이 PR의 내용을 명확하게 전달하는지 확인하세요. 설명 추가: 기존 문제를 해결하는 경우 해당 문제에 대한 링크를 포함해야 합니다. 설명이 끝나면 검토를 위해 PR을 제출하세요. PR 승인 권한이 있는 사람은 며칠 내에 신청서를 검토하고 다음 중 하나를 수행할 것입니다.

1. 변경사항을 즉시 병합합니다.
2. 변경을 요청하는 메시지가 표시됩니다.
3. PR을 종료합니다.

저장소 작성자는 정규직 업무나 다른 프로젝트로 인해 바쁠 수 있으므로 기다려 주시기 바랍니다.

훌륭해!

이제 귀하는 오픈 소스 프로젝트의 기여자가 되었습니다! 느낌이 어떤가요? 나만의 Node.js 경쟁자를 만들 준비가 되셨나요? 간단한 기여를 통해 향후 오픈 소스 작업에 대한 전망이 덜 위압적이기를 바랍니다. 오픈소스 기여에 대한 자세한 내용은 오픈소스 가이드를 확인하세요 .