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

다시 한 번 안녕하세요, 여러분! 우리는 젊고 미성숙한 프로그래머가 첫 직장에서 직면할 수 있는 문제를 계속해서 고려할 것입니다. 첫 번째 부분은 여기에서 찾을 수 있습니다 . 계속합시다.

13. 코딩 스타일 지침을 준수하지 않음.

개발팀은 일반적으로 단일 코딩 스타일을 고수합니다. 즉, 개별 개발자는 자신의 코딩 스타일이 다른 개발자와 다르지 않도록 특정 서면 또는 서면 규칙을 따릅니다. 독특한 코딩 스타일로 자신을 돋보이게 하려고 하지 마십시오. 이것은 당신을 보기 좋게 만들지 않습니다. 프로젝트를 처음 접하는 경우 일반적인 코딩 스타일 지침을 정의하는 문서가 있는지 즉시 확인해야 합니다. IDE가 올바른 코딩 스타일 힌트를 제공할 수 있도록 요청하고 IDE(예: IntelliJ IDEA)로 가져와야 하는 특정 프로젝트에 대한 일부 스타일 파일이 있을 수 있습니다. 예를 들어 스타일에서는 가능한 경우 최종 수정자를 사용해야 할 수도 있습니다. 스타일 파일을 사용하면 IntelliJ IDEA가 이를 준수하지 않는 모든 변수를 노란색으로 강조 표시할 수 있습니다.

14. 실수로 인해 낙담한다

실수는 익숙해져야 하는 것입니다. 그들은 과거에도 그랬고 앞으로도 그럴 것입니다. 당신이 초심자인지 진지한 건축가인지는 중요하지 않습니다. 당신은 항상 실수를 하게 될 것입니다. 실수의 수와 심각도는 바뀔 수 있지만 경력 전반에 걸쳐 실수가 동반됩니다. 때로는 일주일 내내 뭔가를 하려고 애쓰다가 실수를 하고, 금요일 저녁이 되자 그 빌어먹을 실수를 고치지도 못한 채 구타당한 개처럼 슬그머니 집으로 돌아오는 경우가 있습니다. 그것은 형언할 수 없는 감정이지만, 낙담할 정도는 아닙니다. 결국 숙련된 개발자와 초보자 사이의 또 다른 중요한 차이점은 실수를 처리하는 방법입니다. 숙련된 개발자는 이를 마음에 새기지 않고 경험으로 여깁니다. 아무도 당신이 실수했다고 꾸짖지 않을 것입니다. 이는 정상적인 현상입니다. 모든 사람이 때때로 혼란에 빠질 때가 있습니다. 이번에도 동료에게 도움을 요청할 수 있습니다. 그리고 프로젝트 관리자(PM)와 같은 사람들도 잊지 마세요. 문제가 있으면 즉시 PM에게 연락해야 합니다. 그 또는 그녀는 문제가 있는 분야의 전문가를 찾는 데 도움을 줄 수 있습니다. 어떤 경우에도 프로젝트에서 직면하는 문제에 대해 PM에게 계속 알려야 합니다. 팀원 간의 소통과 교류 등 제반 문제를 해결하도록 돕는 것이 PM의 역할이다. 요약하자면, 실수는 발생합니다 . 실수로 인해 목숨을 잃게 놔두지 마세요. 대신, 그것을 당신과 당신의 기술에 대한 도전으로 받아들이십시오. 결국 그것은 일의 일부일뿐입니다.

15. 스레드 안전성을 구현하지 못했습니다.

좋은 것은 쉽게 만들어지지 않습니다. 모든 개발자는 모듈이든 단순한 메서드이든 특정 기능을 작성하려면 수행할 작업과 방법에 대한 계획이 필요하다는 점을 이해해야 합니다. 일반적으로 복잡한 기능을 개발할 때는 다음 절차를 따라야 합니다. 초보 프로그래머가 작성한 코드에서 발생하는 많은 오류는 이 절차의 단계와 관련됩니다. 물론, 작업을 보자마자 거침없이 빠르게 코드를 작성해야 하는 순간이 있다는 것을 배제할 수는 없습니다. 그러나 이는 일반적으로 구현이 명확하고 많은 생각이 필요하지 않은 특정 사소한 작업 및 메서드에만 적용됩니다. 위에서 언급한 개발 절차는 하위 작업으로 나눌 수 있는 복잡하고 큰 작업에 더 적합합니다. 작성하려는 내용을 명확하게 이해하지 않고 코드 작성을 시작하는 것은 좋은 생각이 아닙니다. 첫째, 모든 것을 신중하게 생각하고 계획해야 합니다. 종이 한 장과 연필을 들고 구현 아이디어를 스케치해 보는 것도 도움이 될 수 있습니다 . 저는 복잡한 기능을 계획할 때 항상 이렇게 합니다. 프로그래머는 코드를 작성하는 것보다 필요한 기능을 어떻게 구성할지 고민하는 데 대부분의 시간을 보냅니다 . 실제로 모든 것을 계획하고 생각하고 나면 코드 작성은 번거롭지 않은 순전히 기계적인 프로세스가 됩니다.

16. 과로

영화 '파이트 클럽'(1999) 중에서 아마도 모든 초보자는 밤늦게까지 일함으로써 더 많은 작업을 완료하기 시작하고 더 많은 책임을 맡게 될 것이라고 생각할 것입니다. 나도 예전에는 그렇게 생각했는데 이제는 아니다. 나는 당신이 한계에 도달하고 적절하게 생각할 수 없게 되는 시점이 온다는 것을 알아차렸습니다. 당신은 꽤 둔해지기 시작하고 정신적 안개를 경험합니다. 마음이 맑다면 10분 안에 할 수 있는 일을 하는 데는 한 시간이 걸립니다. 거의 예외 없이, 이 피로선을 넘은 후에는 극복할 수 없을 것 같은 몇 가지 문제에 직면하게 됩니다. 그런데 다음날 아침 출근하면 눈 깜짝할 사이에 문제가 해결됩니다. 그러므로 당신이 이 지점에 도달했다고 느낄 때, 늦게까지 깨어있지 마십시오. 그냥 집에 가서 푹 쉬세요. 결국, 밤늦게까지 책상에 앉아 있으면 이 고통스러운 시간 동안 특별히 뛰어난 결과를 얻지 못할 뿐만 아니라, 동시에 다음 근무일 전에 휴식을 제대로 취하지 못할 수도 있습니다. 다시 한 번 망쳐보겠습니다. 당신의 건강에 대해 생각해보십시오. 경력 초기에 이렇게 건강을 훼손할 가치가 있습니까? 나는 그렇게 생각하지 않는다. 아프기엔 아까운 시간이다. 그리고 고용주에 대해 생각해 보세요. 과로하면 자신뿐만 아니라 고용주의 상황도 악화됩니다. 피로 때문에 가장 간단한 정렬 알고리즘을 구현할 수 없는, 항상 졸린 직원이 필요한 사람은 누구입니까? 그렇습니다. 마감 기한이 촉박할 때가 있고, 모든 것이 잘못되었을 때가 있으며, 이것이 제가 개인적으로 가장 좋아하는 것인데, "어제 이게 필요해요"라고 하는 때가 있습니다. 그러나 이러한 상황은 일반적으로 드물기 때문에 일단 이러한 상황을 극복하고 나면 이러한 상황이 어떻게 발생할 수 있었는지, 그리고 앞으로 이러한 상황을 방지하는 방법을 신중하게 고려해야 합니다.

17. 영어 실력을 무시하는 것

많은 야심찬 개발자들이 기술 학습을 우선시하고 영어 학습을 미루고 있습니다. 이것은 심각한 실수입니다. 왜냐하면 프로그래머가 주니어 직위(또는 인턴십)에 완벽하게 적합하지만 영어 실력이 부족하여 일자리를 얻지 못하는 경우가 많기 때문입니다. 네, 물론 영어 없이도 지낼 수 있는 경우도 있습니다. 일반적으로 이러한 사람들은 비영어권 국가의 프로젝트를 위해 현지에서 고용됩니다. 하지만 국내 기업은 외국 기업과 동일한 임금을 지급하지 않습니다. 그리고 시간이 지나도 적절한 급여를 받는 것은 매우 매우 어려울 것입니다. 그렇기 때문에 영어를 무시하면 안 됩니다. 영어를 뒤로 미루기보다는 영어 프로젝트에 즉시 집중하기 위해 영어를 배워야 합니다. 실제로 잠시 생각해 보십시오. 영어는 현재 국제 비즈니스의 언어입니다. 어느 나라에 가더라도 영어를 알면 다른 사람들과 공통 언어를 찾을 수 있습니다. 개발 프로젝트에서도 마찬가지다. 독일, 호주, 프랑스 등 프로젝트 기반이 어디인지는 중요하지 않습니다. 모든 의사소통, 모든 작업, 문서 등은 영어로 이루어집니다. 그리고 잠시 생각해보면 이것이 매우 편리하다는 점에 동의하실 것입니다.

18. 트렌디한 기술 추구

개발자는 자신의 길을 시작할 때 종종 최신 기술을 따라잡으려고 노력합니다. 그게 옳은 일인가요? 한편으로는 그렇습니다. 최신 기술, 프로젝트 ... 하지만 이것을 최우선 순위로 삼는 것이 가치가 있습니까? 아마도 해당 분야의 전문가를 위한 "클래식 툴킷"을 추구하는 것이 더 나을 것입니다. 새로운 것은 분명 좋지만, 자신이 속한 분야의 근본적인 기술을 잊어서는 안 됩니다. 그리고 기본에 대한 약간의 경험과 깊은 지식을 얻은 후에야 새로운 것을 시도할 수 있습니다. 또한 신기술은 어떤 미묘한 면에서는 우월할 수 있지만 다른 면에서는 이점을 잃을 수도 있다는 점을 고려하십시오. 초보 개발자가 이러한 장단점을 이해할 때까지는 오랜 시간 테스트를 거친 솔루션을 사용하는 것이 좋습니다. 예를 들어, 프로그래머가 일부 데이터와 상호 작용하는 애플리케이션을 개발하는 경우 최신 NoSQL 솔루션이 유행한다는 이유만으로 서두르지 마십시오. 검증된 일반적인 SQL 데이터베이스(MySQL, PostrgreSQL 등)에는 잠재적인 문제에 대한 자세한 문서와 솔루션이 StackOverFlow에 있을 가능성이 높습니다. :)

19. 여러 가지 기술 및/또는 언어를 동시에 학습

위에서는 최신 기술을 배우려는 초보자에 대해 이야기했습니다. 그렇다면 여러 기술이나 언어를 동시에 공부하는 것은 어떨까요? 분명히, 당신은 하나 이상의 프로그래밍 언어를 알고 많은 기술을 숙달한 프로그래머에 대해 들어보셨을 것입니다. 그러나 나는 이 사람들이 프로그래밍에 전혀 익숙하지 않다는 점을 빠르게 지적할 것입니다. 이들은 다년간의 경험을 가진 사람들입니다. 그들은 원래의 기술을 숙달하고 점점 더 발전해 왔습니다. 모든 것을 한 번에 마스터하려는 초보자는 "두 마리 토끼를 쫓으면 둘 중 하나도 잡을 수 없습니다"라는 훌륭한 속담을 기억해야 합니다. 그 결과 어떤 주제도 잘 익히지 못하고 피상적으로만 배우게 될 수도 있습니다. 모든 것을 조금 아는 사람보다 한 가지 언어를 깊이 아는 전문가에 대한 수요가 더 많을 것입니다. 그러므로 많은 언어와 기술을 알고 싶다면 현명하게 접근해야 합니다. 시작하려면 깊이 배워야 하는 기본, 핵심 언어를 선택해야 합니다. 그런 다음에야 다른 분야를 공부하기 시작해야 합니다. 예를 들어, Java 전문가가 된 다음 Python을 제2언어로 배우세요. 그런 다음 프런트엔드의 반응/각도에 대해 배울 수 있습니다. 이 경우 C# 및 Java와 같이 상호 교환이 가능하지 않고 오히려 보완적인 기술에 대해 이야기하여 경력 기회를 확장합니다. 하지만 다시 한 번 반복합니다. 모든 것을 한꺼번에 배우려고 해서는 안 됩니다. 순차적으로 가셔야 합니다. 말하자면, 한 번에 한 마리의 토끼를 잡으십시오.

20. 잘못 구성된 목표

스스로 목표를 어떻게 설정하나요? 멋진 개발자가 되시나요? 이것을 꼭 기억하세요. 구체적인 목표, 즉 달성 가능한 목표를 설정해야 합니다. 내가 무슨 말을하는거야? 예를 들어, "나는 부자가 되고 싶다"라는 목표를 스스로 설정했습니다. 하지만 이 목표를 달성했는지 어떻게 알 수 있습니까? 아니면 목표 달성에 얼마나 근접했는지 어떻게 측정하나요? 글쎄, "백만 달러를 벌고 싶다"라는 목표를 세우면 좀 더 명확해지지 않나요? $10,000를 벌면 목표 달성에 $10,000 더 가까워집니다. 남은 금액은 $990,000입니다. 아직 달성해야 할 부분이 많이 남아 있지만 진행 상황을 느낄 수 있고 결승선이 어디인지 이해할 수 있으므로 계속 나아가려는 의욕이 생길 것입니다. 진로에 있어서 좀 더 구체적인 목표를 세워보는 것은 어떨까요? 예: 저는 팀 리더가 되고 싶습니다. 아니면 수석 개발자. 아니면 궁극적으로 건축가. 음, 모든 큰 작업은 작은 하위 작업으로 나누어야 합니다. 당신은 경력을 시작할 때 팀 리더가 될 수 없습니다. 가능하고 적절하다면 마감일을 설정하고 현재 단계에 집중하세요.

1. 시니어 개발자가 되는 것에 대해 이야기한다면 , 첫 번째 작은 목표는 회사에서 인턴십이나 주니어 개발자로 취업하는 것입니다.
2. 다음으로, 특정 기술에 대한 지식을 심화하기 위한 목표를 설정할 수 있습니다. Java의 경우 Oracle Level 1 자격증을 준비할 수 있습니다. 우리는 준비 기간을 설정하고 목표를 달성합니다.
3. 그런 다음, 예를 들어 영어 실력을 한 단계(예: B1에서 B2로) 향상시키겠다는 목표를 세울 수 있습니다. 학습 계획을 세우고 시간을 계획하며 목표를 향해 나아갑니다.

이것이 우리가 (소프트웨어 개발 경험을 쌓으면서) 단계적으로 최종 목표를 달성할 수 있는 방법입니다.

21. 실천이 없는 이론

새로운 기술을 연구하고 이미 알고 있는 주제에 대해 더 깊이 탐구함으로써 우리가 더 나은 전문가가 된다는 것은 부인할 수 없는 사실입니다. 그러나 여정이 시작될 때 개발자는 새로운 지식을 실제로 시험해 보지 않으면 기술 서적을 하나씩 읽어도 큰 이점을 얻지 못한다는 사실을 거의 깨닫지 못합니다. 나는 개인적으로 이것을 두 번 이상 접했습니다. 책을 읽는 데 많은 시간을 할애했지만 책에서 아무것도 연습하지 않으면 새로 습득한 지식은 거의 모두 잊어버리게 됩니다. 모든 것이 어떻게 작동하는지에 대한 일반적이고 막연한 기억만 남게 됩니다. 결과적으로는 실질적인 결과 없이 많은 시간을 낭비하게 됩니다. 왜 우리는 시간을 낭비해야 합니까? 인생은 영원히 지속되지 않습니다. 중요한 점은 새로운 기술을 배울 때 이론에 얽매여서는 안 된다는 것입니다. 읽기와 동시에 주어진 예를 작성하고 새로운 기술을 실험해 보세요. 이것이 두뇌가 정보를 유지하도록 하는 유일한 방법입니다. 그렇습니다. 새로운 자료를 더 천천히 소비하게 되겠지만, 읽은 내용을 훨씬 더 많이 흡수하게 될 것입니다. 게다가 한 가지 기술을 잘 익히면 다음 기술은 익히기가 훨씬 더 쉬워집니다(언어 학습과 마찬가지로).

22. 지나친 완벽주의

대부분의 개발자는 완벽주의자, 즉 완벽함을 위해 노력하는 사람들입니다. 이는 코드도 완벽해야 함을 의미합니다. 따라서 귀하의 코드는 작성, 테스트, 미세 조정되었으며 이제 이를 메인 브랜치에 제출할 때가 된 것 같습니다. 하지만 여전히 코드에 만족하지 못하기 때문에 이런 식으로 코드를 비틀기 시작하고 이러한 노력에 많은 시간을 소비하게 됩니다. 그리고 이 경우 시간은 고객의 돈입니다. 초보 프로그래머는 완벽함을 추구하는 데 더 취약합니다. 숙련된 개발자는 코드가 결코 완벽할 수 없으며 더 나은 코드를 작성하려고 노력해야 한다는 느낌에 익숙합니다. 그러나 동시에 그들은 "이상"에 가까워지기 위해 극단적으로 나아가지 않습니다. 따라서 행복한 매체를 달성하는 방법을 기억하십시오. 즉, 엉성한 방식이 아니고 코드로 모나리자를 재현하려고 하지 마십시오.

23. 건축에 대한 생각의 실패

다시 한 번 말씀드리지만, 지저분한 코드를 작성해서는 안 됩니다. 가독성과 성능 외에도 코드가 애플리케이션의 나머지 부분에 전체적으로 어떤 영향을 미칠 수 있는지 생각해야 합니다. 예를 들어, 코드를 확장하는 것이 얼마나 어려운지 등입니다. 문제는 경험 부족으로 인해 초보 개발자가 자신의 새로운 기능이 향후 애플리케이션에 어떤 영향을 미칠지 즉시 깨닫지 못할 수도 있다는 것입니다. 이러한 예측을 개발하려면 확실히 많은 연습이 필요합니다. 그러면 초보자는 무엇을 해야 합니까? 코드를 작성하지 않습니까? 이러한 상황에서는 다양한 프로그래밍 패러다임이 도움이 됩니다. 예를 들어 유용한 사례를 전달할 수 있는 SOLID 원칙이나 다양한 디자인 패턴이 있습니다. 이러한 패러다임 역시 주의해서 다루어야 하며 너무 멀리 취해서는 안 됩니다. 하지만 과도하게 사용하는 경우 요점을 어떻게 판단합니까? 경험이 풍부한 동료의 코드 검토가 도움이 될 것입니다. 신선하고 객관적인 시각을 확보함으로써 동료는 귀하에게 올바른 방향을 제시할 수 있습니다.

24. 임포스터 증후군

사기꾼 증후군은 개인이 자신의 성취를 개인의 자질, 능력 및 노력에 돌릴 수 없는 심리적 현상입니다. 일관된 성과에 대한 외부 증거에도 불구하고 이 증후군에 취약한 사람들은 자신이 사기이며 자신이 달성한 성공을 누릴 자격이 없다고 계속 믿습니다. 많은 개발자들이 이 증후군을 앓고 있습니다. 아마도 그것은 우리에게 새로운 지식과 기술을 향해 나아가도록 하는 끈기를 제공할 것입니다. 경험이 많고 성취도가 높은 동료를 보면 월급을 받을 가치가 없는 것처럼 불안해집니다. 저를 믿으십시오. 이것은 사실이 아닙니다. 당신보다 더 낫거나 더 나쁜 개발자가 있고 앞으로도 항상 있을 것입니다. 다른 사람은 당신을 보면서 자신은 결코 당신처럼 되지 않을 것이라고 생각하며 불안해합니다. 그리고 이것은 정상입니다. 팀의 피드백, 코드 검토 및 토론은 이러한 느낌을 극복하는 데 도움이 됩니다. 저를 믿으십시오. 외부인의 의견은 당신을 즐겁게 놀라게 할 것입니다. 그러나 당신이 진정으로 당신의 일과 직업적 발전을 소홀히 하지 않는 경우에만 가능합니다. 만약 이러한 것들을 무시한다면 당신은 잘못된 직업을 선택한 것입니다. 이 직업에서는 항상 새로운 것을 배우고 최고를 위해 노력해야 합니다. 하지만 이곳에 모인 사람들은 게으름과는 거리가 멀다고 생각합니다. 대신 이곳 사람들은 소중한 목표를 향해 씩씩하게 나아가고 있습니다. 그것이 당신을 묘사한다면, 당신은 두려워할 것이 없습니다.

25. 커밋을 거의 하지 않는다

커밋을 자주 수행하는 것을 잊지 마세요! 30분마다는 아닙니다. 일부 기능을 구현하는 데 일주일을 소비한다면 금요일 밤에 하나의 커밋을 수행하지 말고 예를 들어 5개의 커밋을 수행해야 합니다. 거의 모든 대규모 작업은 편의를 위해 더 작은 작업으로 나눌 수 있습니다. 따라서 이러한 작은 작업을 완료하고 커밋합니다. 그리고 이러한 커밋을 즉시 원격 서버로 보내는 것을 잊지 마세요. 그렇지 않으면 일주일 내내 커밋을 하고 금요일 점심 시간에 컴퓨터에 하드웨어 오류가 발생하여 일주일 내내 헛된 손실을 입을 수 있습니다! 그러나 커밋을 원격 서버에 업로드한 경우에는 마지막 커밋이 있는 분기를 다른 컴퓨터로 끌어와 작업을 계속하면 됩니다. 한 가지 더: 금요일 밤에는 라이브 프로덕션 서버에 새 기능을 제출하지 마세요. 그냥 나를 믿어. 그럴 필요는 없습니다. 예상치 못한 오류가 발견될 가능성이 높으며, 이를 수정하는 데 주말을 보내게 됩니다. 그리고 그것은 재미가 없습니다. 주말에는 쉬어야 합니다. 오늘은 여기까지인 것 같아요. PS 마지막 팁: 코드를 많이 작성하세요. PPS 엄청나게 많은 양의 코드를 작성하세요. 그것이 꼭 필요한 경험을 얻을 수 있는 유일한 방법이기 때문입니다.