저는 C와 C ++에서 몇 년간의 경험을 가진 CS 학생이며, 지난 몇 년 동안 저는 앱 개발을 수행하는 Java / Objective C와 지속적으로 협력 해 왔으며 이제는 웹 개발로 전환했으며 주로 루비에 중점을두고 있습니다. 레일과 나는 (앱 개발과 마찬가지로) 다른 코드를 너무 많이 참조한다는 것을 깨달았습니다. 나는 처음부터 할 수 있어야한다고 생각하는 많은 일에 대한 Google 기능을 지속적으로 사용하며 실제로 자신감을 얻지 못했습니다.
기본 기초는 문제가 아니며, 이것을 예제로 사용하는 것을 싫어하지만 스프린트에서 java / python 모두에서 javabat를 실행할 수 있습니다-분명히 성취는 아니지만 내가 말하는 것은 기초에 대한 강력한 기반이 있다는 것입니다 내 생각 엔?
나는 일반적으로 사용해야하지만 참조 구문을 지속적으로 사용해야하는 것을 알고 있습니다. 학위를 마치 더라도이 분야에서 일자리를 찾는 데있어 견실 한 견해를 가졌기 때문에 조언과 의견이 필요합니다. 내가 묻는 주요 이유는 실제로 고용에 관한 것이 아니라 해커 톤에서 논스톱 코드를 망치지 않고 20 개의 Google / github 탭을 열어두고 거기에 앉아있는 사람이되고 싶지 않다는 것입니다. 약간의 자신감 부족으로 인해 …
보통에서 복잡한 작업에 대한 예제를 지속적으로 작성하여 나쁜 개발자입니까?
답변
맹목적으로 복사하여 붙여 넣기 : 나쁨.
더 나은 이해를 위해 문서를 찾고 코드 예제를 읽으십시오.
차라리 물건을 항상 찾는 사람과 함께 일하고 싶지만 모든 것을 알고 있지만 모르는 사람을 지나치게 신뢰하는 사람보다 모든 것이 의도 한대로 작동하는지 확인하십시오. 그러나 최악의 상황은 일이 어떻게 작동하는지 이해하지 않고 웹에서 코드를 비판적으로 복사하는 것입니다 (그리고 버그 보고서가 비가 내리기 시작하면 아무것도 올바르게 고칠 수 없습니다).
답변
솔루션을 유지 관리 가능한 방식으로 코딩하고 실제로 복사 / 붙여 넣기 / 수정 한 내용을 이해하면 아무런 문제가 없습니다.
나는 수석 개발자에게 왜 그가 무엇을했는지에 대해 질문 할 때마다 내부에서 죽습니다.
답변
그냥하는 기술로 좋아 / 아웃 API 문서와 프로그램 , 코드 예제를 찾는 것은 나쁜 프로그래머의 표시이지만, 하나의 사람은 부족 유창 …
… 나는 유창함에 대해 이야기하고 있습니다. 다만 것에 대해 할 수있는 유창하지만 뭔가.
유창한 것이 무엇인지 아십니까? 그것은 당신을 보는 누군가가 입력 할 때 코딩하는 것처럼 나타납니다 …
- … 올바른 코드가 손가락에서 화면으로 흘러가는 것처럼. API 문서, 튜토리얼 및 매뉴얼을 확인하지 않는 것처럼. 실제로, 당신 은 그들 모두를 확인하지만, 그것은 모두 당신의 머리에 있기 때문에 보이지 않습니다. 당신은 당신의 두뇌에 필요한 모든 지식을 가지고 있습니다-충전, 적재 및 사용 준비.
유창한 지식입니다. 한 시간 동안 초보자가 필요한 일을하는 데 1 분이 걸립니다. 정말 노력할 가치가 있습니다. 승리 냄새가나요
… 연습은 유창하게 유일하게 유창하게 구할 수있는 유일한 방법입니다.
답변
Kolb주기 라고 불리는 학습 이론이 있습니다 (설명한 사람 이후). 이주기의 항목은 다음과 같습니다.
Concrete experience -> Reflective observation
^ |
| v
Active experimentation <- Abstract conceptualisation
다른 사람들은 사이클의 다른 곳에서 시작하는 것을 좋아합니다. 따라서 샘플 (반사 관찰 단계)을 찾은 다음 추상화를 통해 해당 샘플에서 큰 그림으로 운동 함으로써 학습 하는 것이 전적으로 가능합니다 .
다른 사람들은 다른 방식으로 배우게 될 것입니다. 어떤 사람들은 시도 (즉 실험)를 시작한 다음 옳고 그른 것을 반영하는 것을 좋아합니다. 요점은 이것들이 학습 문제를 공격하는 다른 방법 일 뿐이라는 것입니다.
답변
전체 공개-저는 직장에서 사용할 수있는 다른 사전 인터넷 교육을받은 노인입니다. 나는 젊은 개발자의 기술이 정보를 유지하지 않거나 인터넷에서 얻은 솔루션을 이해하지 못하기 때문에 꾸준히 악화되는 것을 보았습니다. 20 년 전 1-2 년의 경험을 가진 사람의 능력 수준은 이제 5-7 년의 경험을 가진 사람의 능력 수준이라는 것을 알았습니다. (그렇습니다. 개인적 관찰이지만 많은 채용을 해왔으며, 그 문제에 대한 통계 자료가 없습니다. 예, 때로는 나이가 많고 불안합니다. )
모든 것을 찾는 것은 시간면에서 비효율적입니다. 또한 깊이있는 지식이없는 사람의 증상이기도합니다. 지식이 풍부한 사람들은 문제를 해결하지 않고 문제를 해결하는 방법을 모르는 사람들보다 코드를 더 빨리 작성할 수 있습니다. 따라서 지속적으로 물건을 찾지 않고도 더 많은 물건을 다루는 법을 배우는 것이 좋습니다.
이제는 절대로 물건을 찾아 보지 말라고 말하는 것이 아니라 지식을 유지하는 법을 배워야하며 거의 사용하지 않거나 정말로 새로운 문제 나 언어 또는 패러다임을 만날 때만 찾아야한다는 말입니다. 그리고 새로운 솔루션, 도구 및 언어를 따라 잡기 위해 읽지 말아야한다는 말은 아닙니다.
너무 많은 것을 찾는 개발자들에 대한 나의 진정한 관심사 (너는 반드시 그런 것은 아님)가 가지고있는 문제와 필요한 솔루션을 이해하기 위해 분석 기술을 개발하지는 않는다. 그 사람이 명확하게 이해하지 못하지만 전문가 수준에서 일하는 사람에게는 분명해야 할 오류 메시지에 몇 가지 질문이 있는지 알아보십시오. 또는 그 사람이 “작동하지 않는 이유는 무엇입니까?” 오류 메시지 또는 작동하지 않는 방법 및 코드의 구문이 정확하지 않습니다. 또는 작동해야 할 코드를 제공받은 사람들은
따라서 찾고있는 것이 언어의 핵심 기능 (BTW 데이터베이스에 액세스하는 경우 SQL을 포함해야 함)의 일부인 것이라면 6 개월 이상 사용 했는데도 찾고있는 것 같습니다. 많은. 찾고있는 것이 고급 기능, 특히 드물게 사용할 수있는 기능인 경우 제대로 수행하는 것입니다.
그러나 더 많은 정보를 유지하는 법을 배우는 방법은 무엇입니까? 먼저 코드가 깨지는 이유를 이해하십시오. 누군가가 당신에게 해결책을 제시하더라도, 왜 그것이 효과가 있고 당신의 것이 효과가 없는지 모른다면 물어보십시오. 오류 메시지를 이해하지 못하면 의미를 물어 본 후 직접 해결해보십시오.
이해하지 못하는 솔루션을 잘라내어 붙여 넣지 마십시오. 실제로 잘라내어 붙여 넣지 마십시오. 정보를 유지하려면 정보를 입력해야합니다. 실제로 물리적으로 코드를 작성하면 학습에 도움이됩니다. 그것은 잘 알려진 학습 기술입니다.
코드에 대한 이해를 일반화하는 연습을하십시오. 나는 사람들이 ABC 문제에 대한 한 달 전에 얻은 해결책이 새로운 문제 DEF에 대한 동일한 해결책이라는 것을 이해하지 못하기 때문에 시간이 지남에 따라 비슷한 질문을 반복하는 것을 보았습니다.
따라서 무언가를 연구했을 때 어떤 유형의 문제가 해결에 도움이 될지 생각하고 그에 대한 메모를 작성하십시오. 그런 다음 문제를 해결할 때 먼저 자신의 메모를 확인하여 가능한 기술을 이미 확인했는지 확인하십시오. 문제를 해결하기 위해 여러 가지 방법을 평가하는 경우 문제의 유형, 살펴본 가능한 솔루션 및 각각의 장단점을 기록하십시오. 다시 한 번 메모를하면 뇌에 대한 지식이 강화되는 데 도움이됩니다. 이미 찬반 양론의 관점에서 자신의 사고 과정을 가지고 있으며 다시 할 필요가 없습니다. 다음 유사한 문제에 대해 더 많은 가능한 기술을 찾으십시오.
그리고 다음에 배울 내용을 결정할 때 첫 30 일 분량의 또 다른 기술을 배우기 전에 주요 기술 중 하나에 대해 자세히 알아보십시오 (이는 필요한 경우 실제로 업무를 수행하기에 충분한 지식이 있다고 가정합니다. 6 가지 기술 사용-6 가지 기본 사항을 모두 숙지 한 후 심도있게 진행하십시오). 그런 다음 새로운 수준의 학습, 기본 수준에서 더 깊이 학습 한 다음 기본 수준에서 더 많은 새로운 기술을 학습하는 등의 과정을 진행하십시오. 시간이 지남에 따라이 작업을 수행하면 새로운 기술에서 원하는 것에 대한 기본 수준이 더 깊다는 것을 알게 될 것입니다.
지식을 유지하는 법을 배우는 또 다른 방법은 다른 사람에게 지식을 가르치는 것입니다. 이와 같은 장소에서 질문에 답변하고, 팀에게 교육 주제를 제시하고, 로컬 사용자 그룹에서 프리젠 테이션을하고, 블로그 항목을 작성하고, 회사에서 정보 개발자가 다른 개발자를 도울 수 있도록 위키를 유지하십시오.
답변
코드 예제를 찾는 것은 나쁜 개발자의 징조가 아닙니다. 필요한 모든 인터페이스를 정확하게 기억하기 위해 필요한 것이 거의 없기 때문에 물건을 찾는 것이 자연스럽고 코드 예제는 일반적으로 사용하기 가장 쉬운 참조입니다.
하지 말아야 할 것은 복사 및 붙여 넣기 예입니다. 복사 및 붙여 넣기 예는 여기에서 작동하므로 작동 방식을 이해하지 않고도 여기에서도 작동해야합니다. 그것은 보통 쓸모없는 비트를 많이 가져다가 부수적으로 복사하여 결과를 유지하기가 어려워서 작성했을 때 어떻게 작동하는지 알지 못하면 6 개월 후에 알지 못하기 때문에 고치세요.
그러나 예제에서 복사하는 코드를 이해하는 한, 작업을 더 빨리 수행 할 수있는 올바른 방법이며 일반적으로 좋은 방법입니다.
답변
이 답변은 꽤 좋습니다. 그러나 복사 / 붙여 넣기 또는 “기술”부족보다 훨씬 더 심각한 문제가 있습니다.
비교는 치명적입니다. 자신을 다른 사람들과 비교하고 자신의 재능이 자신을 바라 보는 방식에 더 많은 영향을 미치면, 더 많이 휘둘러 죽게됩니다. 사람들이 당신이 얼마나 재능이 있는지를 볼 까봐 해커 톤에 가지 않습니다. 그리고 당신이 재능이 없다고 생각하는 유일한 이유는 더 많은 코드를 처음부터 더 빨리 낼 수있는 해커와 비교하기 때문입니다.
“분당 코드 라인”이 기술을 측정하기위한 좋은 척도 일지라도, 항상 당신보다 더 나은 개발자가 있다는 사실을 받아 들여야 합니다 . 그리고 기술이 부족하다는 것을 다른 사람들에게 보여주는 것도 괜찮 습니다.
당신은 다른 사람만큼이나 더 나을 필요가 없습니다. 항상 어떤 식 으로든 부족하고 끊임없이 배우고 있다는 사실에 만족해야합니다. 열등한 개발자가되어서 기쁘지 않다면 결코 행복하지 않을 것입니다.
한 가지 더 : 당신이 “우수”하다고 생각하는 사람들에 의한 거부에 대한 당신의 두려움은 당신이 더 나은 개발자와 어깨를 비비고 그들로부터 배우는 것을 막는 것입니다. 그래서 당신의 두려움은 당신이 성장하는 것을 막아서 당신의 두려움을 유지합니다. 당신이 자라지 못하게합니다. 주기를 보시겠습니까? 당신은 어딘가에 사이클을 중단해야합니다.