지속적으로 코드 예제를 찾는 것은 나쁜 개발자의 신호입니까? [닫은]


161

저는 C와 C ++에서 몇 년간의 경험을 가진 CS 학생이며, 지난 몇 년 동안 저는 앱 개발을 수행하는 Java / Objective C와 지속적으로 협력 해 왔으며 이제는 웹 개발로 전환했으며 주로 루비에 중점을두고 있습니다. 레일과 나는 (앱 개발과 마찬가지로) 다른 코드를 너무 많이 참조한다는 것을 깨달았습니다. 나는 처음부터 할 수 있어야한다고 생각하는 많은 일에 대한 Google 기능을 지속적으로 사용하며 실제로 자신감을 얻지 못했습니다.

기본 기초는 문제가 아니며, 이것을 예제로 사용하는 것을 싫어하지만 스프린트에서 java / python 모두에서 javabat를 실행할 수 있습니다-분명히 성취는 아니지만 내가 말하는 것은 기초에 대한 강력한 기반이 있다는 것입니다 내 생각 엔?

나는 일반적으로 사용해야하지만 참조 구문을 지속적으로 사용해야하는 것을 알고 있습니다. 학위를 마치 더라도이 분야에서 일자리를 찾는 데있어 견실 한 견해를 가졌기 때문에 조언과 의견이 필요합니다. 내가 묻는 주요 이유는 실제로 고용에 관한 것이 아니라 해커 톤에서 논스톱 코드를 망치지 않고 20 개의 Google / github 탭을 열어두고 거기에 앉아있는 사람이되고 싶지 않다는 것입니다. 약간의 자신감 부족으로 인해 ...

보통에서 복잡한 작업에 대한 예제를 지속적으로 작성하여 나쁜 개발자입니까?


14
그것은 내가 일하고있는 것에 달려 있으며, 내가 찾는 작업은 거의 필요하지 않습니다. 더 익숙하지 않은 것, 나는 항상 예제를 찾는다.
Jaydee

11
실제로 코드를 직접 작성하는지에 따라 다릅니다.

18
아내는 TV에서 요리 대회와 컵 케이크 챔피언십을보고 무작위 재료로 맛있는 식사를 요리 할 시간이 아주 적습니다. 많은 시간 동안 음식은 끔찍하거나 익히지 않으며 확실히 최고 품질이 아닙니다. 그들은 쇼에 좋지만 나는 오히려 내 요리사가 그의 시간을 가지고 그것을 올바르게하고 싶습니다. 해커 톤도 마찬가지입니다. 주커 버그 (Zuckerberg)와 그의 동료들은 해커 톤 (hackathon) 사람들로, 몇 명의 사용자를 확보하기 시작한 후에 다시 작성해야하는 엉뚱한 웹 사이트를 신속하게 작성했습니다. 대부분의 사람들은 오히려 당신이 처음에 그것을 올바르게 얻을 것입니다.
maple_shaft

88
상사는 항상 "프로그래머 기술의 가장 좋은 척도는 Google 검색을 잘 수행하는 능력"이라고 말합니다. 내가 아는 모든 프로그래머는 인터넷에서 예제를 찾고 있지만 나쁜 프로그래머 만 맹목적으로 붙여 넣습니다. 누군가 당신이하고 싶은 일을 이미했다면 왜 바퀴를 재발 명합니까?
SSumner

9
연구가 중요합니다. BSDD (블로그-스팸 중심 개발)
Thomas Dignan

답변:


238

맹목적으로 복사하여 붙여 넣기 : 나쁨.

더 나은 이해를 위해 문서를 찾고 코드 예제를 읽으십시오.

차라리 물건을 항상 찾는 사람과 함께 일하고 싶지만 모든 것을 알고 있지만 모르는 사람을 지나치게 신뢰하는 사람보다 모든 것이 의도 한대로 작동하는지 확인하십시오. 그러나 최악의 상황은 일이 어떻게 작동하는지 이해하지 않고 웹에서 코드를 비판적으로 복사하는 것입니다 (그리고 버그 보고서가 비가 내리기 시작하면 아무것도 올바르게 고칠 수 없습니다).


21
@NewlyInsecure Thats okay ... 나 같은 소프트웨어 개발자들은 해커 톤에가는 사람들이 말도 안된다고 생각한다. 그들 중 대부분은 훌륭한 프로그래머이지만 너무 많은 적을 마신 끔찍한 소프트웨어 개발자입니다.
maple_shaft

23
개발자는 누군가가 손 전에 뭔가를 수행하고 예제를보고 그들을 적응하는 것을 알 수있는 두뇌를 가지고있다. 개발자는 시간이 벽에 두개골을 마구 낭비하지 않습니다.
David

19
@NewlyInsecure 비교는 죽인다. 진지하게, 자신을 다른 사람들과 비교할수록, 당신은 더 낙담하고 동기 부여되지 않으며 두려워하게됩니다. 다른 사람의 행동이 아니라 진실을 바탕으로 자신의 신념을 형성하십시오. 해커 톤에있는 사람들이 더 많은 코드를 더 빨리 낼 수 있다면 누가 신경 쓰나요? 그것이 기술의 지표라고 해도 아무리 능숙하더라도 항상 당신보다 똑똑한 사람들이있을 것입니다.
Phil

5
개인적으로, 내가하고 싶은 일을 이미 어느 정도 수행하는 코드 예제를 찾으면 이해하기 위해 연구합니다. 더 큰 코드 인 경우 메모를 작성하고 특정 사례에 대한 솔루션을 의사 코드로 작성한 다음 실제 코드로 의사 코드를 구현하려고 시도합니다. 나는 여기서 핵심과 tdhammers와 David가 언급 한 것은 맹목적으로 코드를 복사하지 않는다는 것입니다. 나는 그것이 무엇을하고 있는지 이해하고 아이디어를 내 특정 솔루션에 통합하기 위해 그것을보고 있습니다.
shufler

3
@NewlyInsecure : 또한 두 가지 단점이 있습니다. 첫째, API가 예전보다 훨씬 더 크고 복잡 해져서 암기하기가 훨씬 더 어렵다는 것입니다. 두 번째는 나이인데, 지금은 없지만 당신이 그것을 알기 전에 의지입니다. 나이가 들어감에 따라 모든 것을 기억할 수 없다는 것을 알게 될 것이며, 실제로 알아야 할 것들을 위해 뇌 세포를 보존하기 시작할 것입니다. 연구를 수행하고 잊어 버린 세부 사항을 찾는 데 필요한 기술을 배양하는 것이 중요합니다.
Blrfl

110

솔루션을 유지 관리 가능한 방식으로 코딩하고 실제로 복사 / 붙여 넣기 / 수정 한 내용을 이해하면 아무런 문제가 없습니다.

나는 수석 개발자에게 왜 그가 무엇을했는지에 대해 질문 할 때마다 내부에서 죽습니다.


8
때때로 나는 내가 그다지 개발자가 아니라고 생각하면서 스스로를 시작한다. 그런 다음 그런 인용문을 읽고 자신에 대해 훨씬 나아졌습니다.
조끼

18
@TheJug, 당신은 당신이 생각하는 것 보다 더 나은 개발자이자 더 나쁜 개발자 라는 것을 기억하십시오 .
Joe

71

그냥하는 기술로 좋아 / 아웃 API 문서와 프로그램 , 코드 예제를 찾는 것은 나쁜 프로그래머의 표시이지만, 하나의 사람은 부족 유창 ...

... 나는 유창함에 대해 이야기하고 있습니다. 다만 것에 대해 할 수있는 유창하지만 뭔가.

유창한 것이 무엇인지 아십니까? 그것은 당신을 보는 누군가가 입력 할 때 코딩하는 것처럼 나타납니다 ...

  • ... 올바른 코드가 손가락에서 화면으로 흘러가는 것처럼. API 문서, 튜토리얼 및 매뉴얼을 확인하지 않는 것처럼. 실제로, 당신 그들 모두를 확인하지만, 그것은 모두 당신의 머리에 있기 때문에 보이지 않습니다. 당신은 당신의 두뇌에 필요한 모든 지식을 가지고 있습니다-충전, 적재 및 사용 준비.

유창한 지식입니다. 한 시간 동안 초보자가 필요한 일을하는 데 1 분이 걸립니다. 정말 노력할 가치가 있습니다. 승리 냄새가나요

... 연습은 유창하게 유일하게 유창하게 구할 수있는 유일한 방법입니다.


14
유창성에 대한 탁월한 지적. COBOL에 능숙합니다. 저는 IT에서 20 년 동안 휴식을 취했으며 Java를 배우기 위해 다시오고 있습니다. COBOL에서 무언가를 수행하는 방법을 본능적으로 알고 있지만 Java 유창 학습 과정의 일부는 코드 샘플을 찾고 작동 방식을 분석하고 특정 요구에 맞게 조정하는 것입니다. 새로운 VERBAL 언어를 배우면 처음에는 이탈리아어-영어 사전을 자주 참조하고 문법과 시제가 잘못되어 결국 언젠가는 원어민처럼 말합니다. 시간과 연습이 핵심입니다. 걱정하지 마세요 ... :)
dwwilson66

10
@ dwwilson66 매일 서버 수준 프로그래밍 언어, 클라이언트 쪽 스크립팅 언어, 클라이언트 쪽 마크 업 구문 및 클라이언트 쪽 스타일 구문의 네 가지 "언어"를 기억해야합니다. 난 그냥 내 머리 속에 모든 것을 유지할 수 없습니다-그것은 이탈리아어, 중국어, 영어 및 Klingon에서 동시에 대화를 개최하려고하는 것과 같습니다.
Tacroy

@Tacroy-정확히! 유창하지 않으면 도움을 줄 수있는 리소스가 필요합니다. 다른 단어만큼 유창하지 않고 가끔 한 단어 대신 전체 문구를 찾아야하는 경우 Klingon 스피커를 "낮게"만들지 않습니다.
dwwilson66

4
마지막 문장은 첨자 안에 숨겨져 있지 않아야 강조 표시해야합니다. 침수보다 유창 해지는 다른 방법은 없습니다.
jmlane

@ dwwilson66 은 Java에서 COBOL과 크게 다른 것들을 수행해야한다는 점에 주목합니다 . 개체는 카피 북과 동일하지 않습니다.

54

Kolb주기 라고 불리는 학습 이론이 있습니다 (설명한 사람 이후). 이주기의 항목은 다음과 같습니다.

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

다른 사람들은 사이클의 다른 곳에서 시작하는 것을 좋아합니다. 따라서 샘플 (반사 관찰 단계)을 찾은 다음 추상화를 통해 해당 샘플에서 큰 그림으로 운동 함으로써 학습 하는 것이 전적으로 가능합니다 .

다른 사람들은 다른 방식으로 배우게 될 것입니다. 어떤 사람들은 시도 (즉 실험)를 시작한 다음 옳고 그른 것을 반영하는 것을 좋아합니다. 요점은 이것들이 학습 문제를 공격하는 다른 방법 일 뿐이라는 것입니다.


2
흥미로운 +1. 직관적으로, 나는 배우기 위해서는 적어도 그 단계들 중 일부 단계를 거쳐야한다고 기대할 것입니다. 즉, 단지 실제 학습이 발생하는 아마 관찰하는 것만으로는 충분하지 않습니다 - 당신은 본 적이 무엇을 생각하고 그것을 밖으로 시도 할 필요가있다.
Caleb

나는 정말로 이것을 좋아한다. 나는 대부분의 언어로 반사 관찰에서 시작하지만 PowerShell에서는 보통 능동 실험에서 시작합니다
Caleb Jares

@caleb 맞습니다. 그것은 당신이 단계별로 이동하는주기이며, 네 가지를 모두 겪을 때까지 무언가를 완전히 내재화하지 않을 수도 있습니다. 그 변화가 가장 많이 시작되는 곳입니다.

39

전체 공개-저는 직장에서 사용할 수있는 다른 사전 인터넷 교육을받은 노인입니다. 나는 젊은 개발자의 기술이 정보를 유지하지 않거나 인터넷에서 얻은 솔루션을 이해하지 못하기 때문에 꾸준히 악화되는 것을 보았습니다. 20 년 전 1-2 년의 경험을 가진 사람의 능력 수준은 이제 5-7 년의 경험을 가진 사람의 능력 수준이라는 것을 알았습니다. (그렇습니다. 개인적 관찰이지만 많은 채용을 해왔으며, 그 문제에 대한 통계 자료가 없습니다. 예, 때로는 나이가 많고 불안합니다. )

모든 것을 찾는 것은 시간면에서 비효율적입니다. 또한 깊이있는 지식이없는 사람의 증상이기도합니다. 지식이 풍부한 사람들은 문제를 해결하지 않고 문제를 해결하는 방법을 모르는 사람들보다 코드를 더 빨리 작성할 수 있습니다. 따라서 지속적으로 물건을 찾지 않고도 더 많은 물건을 다루는 법을 배우는 것이 좋습니다.

이제는 절대로 물건을 찾아 보지 말라고 말하는 것이 아니라 지식을 유지하는 법을 배워야하며 거의 사용하지 않거나 정말로 새로운 문제 나 언어 또는 패러다임을 만날 때만 찾아야한다는 말입니다. 그리고 새로운 솔루션, 도구 및 언어를 따라 잡기 위해 읽지 말아야한다는 말은 아닙니다.

너무 많은 것을 찾는 개발자들에 대한 나의 진정한 관심사 (너는 반드시 그런 것은 아님)가 가지고있는 문제와 필요한 솔루션을 이해하기 위해 분석 기술을 개발하지는 않는다. 그 사람이 명확하게 이해하지 못하지만 전문가 수준에서 일하는 사람에게는 분명해야 할 오류 메시지에 몇 가지 질문이 있는지 알아보십시오. 또는 그 사람이 "작동하지 않는 이유는 무엇입니까?" 오류 메시지 또는 작동하지 않는 방법 및 코드의 구문이 정확하지 않습니다. 또는 작동해야 할 코드를 제공받은 사람들은

따라서 찾고있는 것이 언어의 핵심 기능 (BTW 데이터베이스에 액세스하는 경우 SQL을 포함해야 함)의 일부인 것이라면 6 개월 이상 사용 했는데도 찾고있는 것 같습니다. 많은. 찾고있는 것이 고급 기능, 특히 드물게 사용할 수있는 기능인 경우 제대로 수행하는 것입니다.

그러나 더 많은 정보를 유지하는 법을 배우는 방법은 무엇입니까? 먼저 코드가 깨지는 이유를 이해하십시오. 누군가가 당신에게 해결책을 제시하더라도, 왜 그것이 효과가 있고 당신의 것이 효과가 없는지 모른다면 물어보십시오. 오류 메시지를 이해하지 못하면 의미를 물어 본 후 직접 해결해보십시오.

이해하지 못하는 솔루션을 잘라내어 붙여 넣지 마십시오. 실제로 잘라내어 붙여 넣지 마십시오. 정보를 유지하려면 정보를 입력해야합니다. 실제로 물리적으로 코드를 작성하면 학습에 도움이됩니다. 그것은 잘 알려진 학습 기술입니다.

코드에 대한 이해를 일반화하는 연습을하십시오. 나는 사람들이 ABC 문제에 대한 한 달 전에 얻은 해결책이 새로운 문제 DEF에 대한 동일한 해결책이라는 것을 이해하지 못하기 때문에 시간이 지남에 따라 비슷한 질문을 반복하는 것을 보았습니다.

따라서 무언가를 연구했을 때 어떤 유형의 문제가 해결에 도움이 될지 생각하고 그에 대한 메모를 작성하십시오. 그런 다음 문제를 해결할 때 먼저 자신의 메모를 확인하여 가능한 기술을 이미 확인했는지 확인하십시오. 문제를 해결하기 위해 여러 가지 방법을 평가하는 경우 문제의 유형, 살펴본 가능한 솔루션 및 각각의 장단점을 기록하십시오. 다시 한 번 메모를하면 뇌에 대한 지식이 강화되는 데 도움이됩니다. 이미 찬반 양론의 관점에서 자신의 사고 과정을 가지고 있으며 다시 할 필요가 없습니다. 다음 유사한 문제에 대해 더 많은 가능한 기술을 찾으십시오.

그리고 다음에 배울 내용을 결정할 때 첫 30 일 분량의 또 다른 기술을 배우기 전에 주요 기술 중 하나에 대해 자세히 알아보십시오 (이는 필요한 경우 실제로 업무를 수행하기에 충분한 지식이 있다고 가정합니다. 6 가지 기술 사용-6 가지 기본 사항을 모두 숙지 한 후 심도있게 진행하십시오). 그런 다음 새로운 수준의 학습, 기본 수준에서 더 깊이 학습 한 다음 기본 수준에서 더 많은 새로운 기술을 학습하는 등의 과정을 진행하십시오. 시간이 지남에 따라이 작업을 수행하면 새로운 기술에서 원하는 것에 대한 기본 수준이 더 깊다는 것을 알게 될 것입니다.

지식을 유지하는 법을 배우는 또 다른 방법은 다른 사람에게 지식을 가르치는 것입니다. 이와 같은 장소에서 질문에 답변하고, 팀에게 교육 주제를 제시하고, 로컬 사용자 그룹에서 프리젠 테이션을하고, 블로그 항목을 작성하고, 회사에서 정보 개발자가 다른 개발자를 도울 수 있도록 위키를 유지하십시오.


11
여기에는 아주 좋은 점이 있지만, "좋은 옛날 비트"때문에 어려움을 겪고 있다고 생각합니다. 사람들은 수천 년 동안 젊은이들의 퇴행성을 퇴보 해 왔습니다. 나는 그것을지지 할 강력한 증거를 아직 보지 못했다.

4
+1 @JonofAllTrades ..man, 나는 ..FoxPro를 알고 있었기 때문에 20 년 동안 돌아가서 백만 달러를 벌 수 있기를 바랍니다. 뿐. 그러나 아닙니다. 요즘에는 정규 업무를 위해 경쟁하기 위해 작은 은하계 기술에 능숙해야합니다. Apache, IIS를 모두 설정하고 구성 할 수 있습니까? SPROC를 작성하고 최소한의 관리를 할 수있는 SQL 방언에 익숙합니까? 데이터 조작을위한 몇 가지 서버 측 언어와 하나 이상의 기능적 스크립팅 언어에 능숙하십니까? .. 웹용으로 프로그래밍하면 주요 브라우저 휴대 기기에서 작동합니까?
elrobis

이 주장은 이미 20 년 전에 존재했던 기술에만 의미가 있습니다. 그렇습니다. 오늘날의 표준으로는 불충분 한 SQL (“야드”)에 대한 지식만으로도 일자리를 얻을 수 있습니다.
prusswan

@ prusswan, 나는 전문가이며 그들이 내 경기장을 채울 수있는 것보다 더 많은 직업이 있습니다. 그러나 그것이 대답에서 말하는 것과 관련이있는 방법은 저를 넘어서는 것입니다. 내가 말하는 것은 모든 기술에서 가능합니다. 문제는 사람들이 정보를 유지하지 못하기 때문에 자신이하는 일을 배우거나 이해하지 못하는 것입니다. 우리 중 일부는 오래된 기술을 사용하지 않습니다. 신기술에 대한 지식을 구식 기술만큼이나 쉽게 유지할 수 있습니다. 그리고 보유한 지식은 다음 지식을 배우는 데 도움이되고 더 빨리 발전 할 것입니다.
HLGEM

24

코드 예제를 찾는 것은 나쁜 개발자의 징조가 아닙니다. 필요한 모든 인터페이스를 정확하게 기억하기 위해 필요한 것이 거의 없기 때문에 물건을 찾는 것이 자연스럽고 코드 예제는 일반적으로 사용하기 가장 쉬운 참조입니다.

하지 말아야 할 것은 복사 및 붙여 넣기 예입니다. 복사 및 붙여 넣기 예는 여기에서 작동하므로 작동 방식을 이해하지 않고도 여기에서도 작동해야합니다. 그것은 보통 쓸모없는 비트를 많이 가져다가 부수적으로 복사하여 결과를 유지하기가 어려워서 작성했을 때 어떻게 작동하는지 알지 못하면 6 개월 후에 알지 못하기 때문에 고치세요.

그러나 예제에서 복사하는 코드를 이해하는 한, 작업을 더 빨리 수행 할 수있는 올바른 방법이며 일반적으로 좋은 방법입니다.


2
나는 복사하는 모든 것을 살펴보고 내가 읽은 모든 것을 이해합니다. 구문과 기능 중 일부는 너무 오래 감겨 서 처음부터 완전히 터뜨릴 수는 없다고 생각합니다. json이나 데이터베이스 쿼리 등과 같은 단순하고 두 번째 특성이어야하는 것조차도 (아마도 나쁜 예). 답변 해 주셔서 감사합니다. 정말 감사합니다.
새로 불안한

2
또한 자신의 프로젝트에서 코드 예제를 복사하여 붙여 넣기 전에 두 번 생각해야합니다. 수업에서 분리하여 재사용하는 것이 더 합리적 일 수 있습니다.
stralsi

@SilviuStraliciuc : 이것은 1 줄 또는 2 줄 예에 관한 것입니다. 함수를 감싸는 것은 의미가 없습니다. 그러나 나는 일반적으로 ctrl-c + ctrl-v를 사용하는 대신 다시 입력하여 올바른 형식을 적용하고 식별자 등을 즉시 바꿉니다.
Jan Hudec

1
때로는 1 또는 2 줄 예제는 어떻게 당신이 (1 개 또는 2 라인이하고 싶어 정확히 무엇에 대해 나중에 마음을 바꿀거야 기회가 특히, 함수에 포장 이해하고 지금은 200를 찾을 수있다 코드 전체에 흩어져있는 장소 (1 줄 또는 2 줄 패턴) 적절하게 이름이 지정된 기능을 사용하면 여전히 200 곳에서 수정해야 할 문제가 있어도 해당 장소를 식별하는 것이 더 쉽습니다.
David K

14

이 답변은 꽤 좋습니다. 그러나 복사 / 붙여 넣기 또는 "기술"부족보다 훨씬 더 심각한 문제가 있습니다.

비교는 치명적입니다. 자신을 다른 사람들과 비교하고 자신의 재능이 자신을 바라 보는 방식에 더 많은 영향을 미치면, 더 많이 휘둘러 죽게됩니다. 사람들이 당신이 얼마나 재능이 있는지를 볼 까봐 해커 톤에 가지 않습니다. 그리고 당신이 재능이 없다고 생각하는 유일한 이유는 더 많은 코드를 처음부터 더 빨리 낼 수있는 해커와 비교하기 때문입니다.

"분당 코드 라인"이 기술을 측정하기위한 좋은 척도 일지라도, 항상 당신보다 더 나은 개발자가 있다는 사실을 받아 들여야 합니다 . 그리고 기술이 부족하다는 것을 다른 사람들에게 보여주는 것도 괜찮 습니다.

당신은 다른 사람만큼이나 더 나을 필요가 없습니다. 항상 어떤 식 으로든 부족하고 끊임없이 배우고 있다는 사실에 만족해야합니다. 열등한 개발자가되어서 기쁘지 않다면 결코 행복하지 않을 것입니다.

한 가지 더 : 당신이 "우수"하다고 생각하는 사람들에 의한 거부에 대한 당신의 두려움은 당신이 더 나은 개발자와 어깨를 비비고 그들로부터 배우는 것을 막는 것입니다. 그래서 당신의 두려움은 당신이 성장하는 것을 막아서 당신의 두려움을 유지합니다. 당신이 자라지 못하게합니다. 주기를 보시겠습니까? 당신은 어딘가에 사이클을 중단해야합니다.


8
좋은 대답이지만 평범함을 받아들이면 괜찮다는 의미로 읽혀서는 안됩니다. 자신의 일에주의를 기울이고 다른 사람들이 자신보다 나을 것이라고 걱정하지 말고 개선을 위해 노력하십시오.
Caleb

12

나는 그것이 당신의 마음이 어떻게 작동하는지에 달려 있다고 생각합니다. 내 기억이 찌그러지기 때문에 가능한 한 원하는 코드에 가깝게 코드를 잡고 다시 작업하여 새 작업을 수행합니다. 그것은 내가해야 할 모든 일을 상기시켜주는 예입니다. 예를 들어, 간단한 SQL을 20 년 동안 사용해 왔지만 SELECT 또는 UPDATE 문의 레이아웃을 기억할 수는 없습니다. (괄호가 필요하다고 생각하지만 어느 것을 기억할 수는 없습니다.) 반면에, 내가 기억할 수 있는 가지; 눈을 감고 Java Iterator 구현을 함께 던질 수 있습니다.

내가 복사하는 코드의 대부분은 내 자신의 코드이지만 새로운 것을 배우고있을 때 다른 코드를 복사합니다.

나는 해커 톤에 대해 모른다. 그들은 사진 기억을 가진 프로그래머의 하위 집합을 그릴 수 있습니다. 나는 그것을 시도하고 볼 것입니다. 바보처럼 보이지만 프로그래밍해서는 안됩니다.

복사하고 수정하는 모든 코드를 철저히 이해해야하지만 다른 답변을 읽을 때까지 누군가 이해하지 않고 복사 할 수는 없었습니다. (이 사이트에서 항상 새로운 악을 배우고있는 것 같습니다 ...)


Psst, SELECT에서 하위 쿼리를 수행하거나 WHERE에서 복잡한 부울 논리를 수행하지 않는 한 어느 누구도 괄호 가 필요 하지 않습니다. ;)
Izkata

2
@ 이즈 카타 : 아니요? 오래된 코드를 살펴 보겠습니다. 아, 괄호가 필요한 INSERT 문입니다.
RalphChapin 2016 년

8

... 나는 다른 코드 wayyyy를 너무 많이 참조한다는 것을 깨달았습니다. 나는 처음부터 할 수 있어야한다고 생각하는 많은 것들에 대해 지속적으로 Google 기능을 수행하며 실제로 자신감을 얻지 못했습니다.

그런 다음 중지하십시오. 잠시 다른 방향으로 향하십시오. 훨씬 적은 시간 안에 필요한 것을 정확하게 찾을 수 있다고 알고 있더라도 모든 것을 직접 구현하십시오 .

발생한 문제는 문제 해결 근육 (라틴어 이름 gluteus mojo )이 사용 중지로부터 위축되었으며, 이제 근육 이 얼마나 약한 지 알기 때문에 사용을 피하는 것입니다. 체육관에서 팔뚝을 다룰 때 근육을 만들고 토닝해야합니다. 높은 반복과 낮은 저항으로 시작하십시오-많은 쉬운 문제. 자신감을 가지면 길고 어려운 문제로 넘어갑니다.

점차적으로 모조 수익이 느껴지고 Google에 대한 의존도가 줄어들 것입니다. 그래도 그 근육을 계속 운동하고, 예전 방식으로 돌아 가지 않도록하십시오. 문제를 해결하기 위해 자신에게 도전 첫번째 이자 유일한 다음 다른 솔루션을 찾아보십시오. 때때로 당신은 다른 사람들이 같은 일을하는 더 좋은 방법을 찾았다는 것을 알게 될 것입니다.

보통에서 복잡한 작업에 대한 예제를 지속적으로 작성하여 나쁜 개발자입니까?

예제를 찾지 않고 아무 것도 할 수없는 사람은 나쁜 개발자입니다. 문제는 당신이 시도 할 때까지 당신이 할 수 있는지 아닌지를 알 수 없다는 것입니다.


7

당신은 젊고 많은 프로그래밍 언어로 일했습니다. 아마 당신은 아마 이전 언어보다 새로운 언어를 더 빨리 배우게 될 것입니다. 유창성을 개발하기에 충분히 큰 응용 프로그램에서 단일 언어로 충분한 시간을 보내지 않았습니다.

웹 그리드를 데이터베이스 테이블에 연결하는 전체 프로세스 또는 연결 문자열 형식화와 같은 작은 부분과 같은 광범위한 솔루션을 찾고 있습니까? )?

항상 다른 코드 또는 함수의 구문에 대한 참조를 찾고 있습니다. 프로그램이 많을수록 더 많은 과제와 다양한 환경 및 언어 변경이 발생합니다. 무언가를 할 때마다 전체 자습서가 필요한 경우 문제가 있습니다.


동의합니다-파일에서 읽고, DB에 연결하고, HTTP 요청을하는 등의 일반적인 활동이 많지만 구문과 접근 방식은 일반적으로 확인 해야하는 언어마다 다릅니다. 그런 다음이 기본 빌딩 블록을 함께 모아 영리한 비트 인 새롭고 유용한 무언가를 만드는 방법
Kris C

5

어쨌든 나중에 많은 정보를 잊어 버렸기 때문에 밤에 벼락치기 한 많은 정보를 유지하려는 시도로 시험을 싫어한다고 말하는 교수가있었습니다. 리소스를 아는 것이 좋으며 알 수없는 정보를 찾기 위해 올바르게 사용할 수 있습니다. 나는 일을 포함하여 내가하는 모든 일에 비슷한 원칙을 적용하고 싶습니다.

나는 당신이 가지고있는 가장 중요한 도구는 당신이 올바르게 사용하는 한 당신의 자원이라고 생각합니다. 따라서 코드를 작성할 때 기존 지식을 최대한 활용 한 다음 적절한 솔루션을 더 잘 이해하기 위해 다른 프로그래머에게 요청하거나 인터넷을 검색하여 조사합니다. 지식은 시간이 지남에 따라 쌓이고 잠시 후에 자연스럽게 기술을 더 잘 알고 이해하게됩니다. 나는 실제로 정보가 필요한지 아닌지를 끊임없이 찾고 있으며, 매일 새로운 것을 배우고 있다고 정직하게 말할 수 있습니다.


6
"저는 책에서 쉽게 찾을 수있는 것을 기억하지 않습니다." -알버트 아인슈타인, 1922.
gbjbaanb

3
@gbjbaanb Albert Einstein은 1922 년에 버전 관리를 사용 했습니까? 와우, 그는 정말 대단 했어.
svick

4

해결하려는 문제를 이해하고 해결 방법을 이해하는 경우 올바른 구문을 찾는 것이 큰 의미는 아닙니다.

나는 약 2 년 전에 졸업했고 직장을 구할 때 늑대에게 던져졌다. 이전에는 전혀 다루지 않은 언어로 작성된 큰 응용 프로그램을 배우고 유지 관리하고 업그레이드해야했습니다. 버그 리포트를 받고 코드를 살펴보고 수정 방법을 찾은 다음 해당 언어로 원하는 작업을 수행하는 방법에 대한 Google 예제를 Google에 제공해야합니다.

일을 끝내고 불필요한 이탈을 일으키지 않을만큼 충분히 이해했다면 아마 괜찮을 것입니다.


3

이 답변에 여러 번 언급 된 순수한 중요하지 않은 복사 및 붙여 넣기는 나쁩니다. 그러나 처음부터 모든 것을 쓰는 것입니다. 비즈니스의 핵심 요소가 아닌 경우 먼저 라이브러리 또는 코드 스 니펫을 찾아보십시오. 스 니펫을 찾는 예외는 문제가 매우 간단하다는 것입니다.이를 수행하는 방법에 대한 명확한 그림이 있고 라이브러리를 사용하지 않는 경우 더 이상 할 일이 없을 것입니다.

나는 일반적인 것을 쓰면 개인적으로 알고 있으며, 약간의 테스트를 거치지 않으면 서 미묘한 버그가 있거나 아마도 하나 또는 두 개의 미묘한 버그가있을 수 있습니다. 그래서 비슷한 솔루션을 찾고 수정 및 테스트하여 테스트 및 개발에 소요되는 시간을 절약하십시오. 결국 나는 작동하고, 확장 가능하며, 예산 또는 예산에 미치지 못하고 마감일을 지키는 제품을 제공 할 책임이 있기 때문입니다. 코드와 라이브러리를 재사용하는 것이 그 목표를 향한 좋은 단계입니다.


3

코드 예제를 읽고 다른 사람들이 일반적으로 개발 한 소스 코드를 읽는 것이 기술을 향상시키는 가장 좋은 방법이라고 생각합니다. 나는 그것이 당신의 두뇌에 다른 방법으로는 열리지 않았을 문을 여는 것이라고 생각합니다.

솔루션 A를 생각하고 다른 사람이 솔루션 B를 생각하면 각자 솔루션을 공유 할 때 A 또는 B보다 훨씬 나은 솔루션 C를 실현할 수 있습니다.


2
주로 솔로 개발자로서, 코드를 확인하고, 문제를 해결하고, 영감을주는 동료가 없습니다. 특정 문제를 해결하고 새로운 기술 / 모범 사례를 배우기 위해서는 인터넷상의 예가 필수적입니다.
cjmUK

3

많은 소프트웨어 개발 능력이 있다고 생각합니다. 많은 수준의 소프트웨어 개발 문서 능력 도 있기 때문 입니다. 솔직히 요즘 시스템은 1980 년대 중반에 컴퓨터 프로그래밍을 시작했을 때보 다 훨씬 복잡합니다.

그런 다음 컴퓨터가 무엇을 원하는지 알아야하고 6 인치 두께의 문서를 작성하여 컴퓨터가보다 기본적인 작업을 수행 한 방법을 알려주었습니다. 컴퓨터가 취할 수있는 형태로 원하는 것을 두는 것은 책의 색인 내용과 프로그래밍 언어 (또는 2 개 언어를 아는 문제였습니다. 실제로 4 개 또는 5 개 언어를 배우면 나머지는 방언 일뿐입니다.)

현재이 작업에는 언어, 시스템, 패러다임, 프로그래밍 모델 및 하나 이상의 API 세트가 모두 필요합니다.

따라서 어떤 수준의 기본 지식을 가진 사람은 좋은 프로그래머가 아닙니다. 그는 오늘날의 환경과 Microsoft와 같은 무관심한 회사가 실제로 자신의 기본 문서에 어떤 종류의 엄격한 적용을가했는지를 고려할 때 최고의 프로그래머입니다. 그것들의 대부분은 자체 참조 참조 자료이며 매우 나쁜 샘플 코드입니다. (내가 직면 한 두 가지 경우는 "Windows Installer"와 WMV 영화 파일을 만드는 API입니다.)

마이크로 소프트, 구글, 그리고 애플은 그 어느 정도까지도 "커뮤니티"에 의존하여 매우 부족한 부분을 보완하는 것이 중요하다. 오늘날의 환경에서 질문을받을 수 있고 확실한 답변과 피드백을 줄 수있는 사람이되는 것은 매우 중요합니다. 이것이 stackexchange.com 사이트와 같은 사이트가 그 자체로 도움이되는 이유 입니다.

따라서 샘플에 대해서는 (지능적으로 물어보십시오) 질문을하고 답변을 제공하는 사람들을 존중하십시오. 그렇게 하는 것은 "나쁜 개발자"의 표시로 보이지 않습니다 .

그리고 한 가지 더 : 나쁜 샘플을 제공한다는 것은 나쁜 개발자의 신호입니다. 나쁜 개발자를 쉽게 발견 할 수있게 해줄뿐 아니라 Google 검색을 방해합니다. 단순하고 간단한 특정 코드 샘플에 대한 확신이 없으면 '주지 마십시오.

그리고 부탁하는 사람들을 조롱하지 마십시오.


3

그것은 당신이 참조하는 것을 이해하는 데 덜 도움이되고 시설 및 메모리 문제에 더 많은 문제가 있다고 생각합니다. 만약 당신의 자신감을 사로 잡는다면 문제입니다 – 그러나 확실히 해결 될 수 있습니다!

저에게는 이런 종류의 도전이 제 삶의 여러 측면에서 나타납니다. 예를 들어, 음악을 잘 연주하려면 내가받은 악보에서 독립성을 개발해야합니다. 소책자에 코가 묻혀 있으면 어떻게 음악을 느낄 수 있습니까? 때로는 시간이 있으면 공연에 필요하지 않더라도 전체 음악을 외울 것입니다. 왜? 악보가 사라지면서 내가 맞아야하는 음악의 더 도전적이고 중요한 측면에 집중하는 것이 훨씬 쉬워졌으며, 순수한 음악 제작의 놀라운 영역에 들어가기가 훨씬 쉬워졌습니다. 그래서 나는 종종 추가 문제의 가치가 있다고 생각합니다.

프로그래밍 경험이 비슷했습니다. 열쇠는 다음과 같습니다.

  1. 언어를 연습 하십시오 – 입력하고, 실행하고, 도움이된다면 말하십시오; 반복적으로 그렇게하십시오.
  2. 시설 구축 – 서로 다른 상황에서 동일한 기능 또는 패턴을 사용하십시오. 기능을 결합하십시오. 프로그램을 만드십시오.
  3. 반복되는 사이에 충분한 시간 을 두어 물건이 실제로 장기 기억에 들어가도록하십시오.

이 원칙들은 실제로 어떤 언어를 배울 때 적용되는 것 같습니다! 예를 들어 새 단어를 기억하는 방법을 참조하십시오 . Pimsleur 방법은 이처럼 작동합니다.

필자가 정기적으로 사용하는 언어 및 기술의 거의 모든 원칙, 구문 및 공통 라이브러리는 이러한 키를 사용하여 완전히 기억할 수 있음을 발견했습니다. 그럼에도 불구하고 나는 여전히 모범과 지혜를 위해 인터넷을 계속 문지릅니다! 그러나 그 시점에서, 나는 해결하려는 문제, 취해진 다양한 접근법, 도움이되는 도구 및 덜 자주 사용되는 라이브러리에 대한 상담에 대한 유효성 검사를 찾고 있습니다. 튜토리얼과 매뉴얼에서 처음으로 언어를 배우고 깊숙이 배울 때 사용하는 것과는 매우 다른 종류의 검색입니다.

당신의 이야기에서, 당신이 겪을지도 모르는 특정 걸림돌이 있습니다.

  1. 구문에 어려움을 겪고 있다면 연습이 충분하지 않을 수 있습니다. 반복을 개발하는 대신 코드에 직접 복사하여 붙여 넣을 경우 특히 그렇습니다. – 당신이 정말 잘하는 데 도움이되는 근육 기억 . 이를 극복하기 위해 반복과 시간에 중점을 두어 원하는 영역의 시설을 개선 할 수있는 운동과 훈련을 개발하십시오. 제안 :
    • 매일 같은 언어로 간단한 프로그램을 작성하십시오.
    • 복사하여 붙여 넣는 대신 예제를 입력하십시오.
  2. 중간 규모의 문제에 대한 솔루션을 구축하는 데 어려움을 겪고 있다면 구축 경험이 충분하지 않을 수 있습니다. 이것들을보십시오 :
    • 원하는 기술이나 언어로 중간 규모 프로젝트를 시작하십시오. 또는 관심이있는 오픈 소스 프로젝트의 chunkier 기능을 사용해보십시오. 매일 조금씩 해킹하십시오. (이 큰 프로젝트를 수행 할 때 벽돌로 벽돌로 가십시오. 한 번에 전체를 구축하려고 시도하지 마십시오!)
    • 4 개의 다른 상황에서 4 일 연속으로 동일한 새로운 기능을 사용하십시오.
    • 웹 브라우저를 끈 상태에서 무언가를 코딩하도록 도전하십시오!
    • 실제로 배우고있는 내용에 메모를하십시오. 배우고있는 내용을 종합하고 관찰 내용을 적어 둡니다. (사실 내용을 적어두고 내 말로 무언가를 표현하도록 강요하면 많은 도움이됩니다.)
    • 흡수하는 기술에 대한 StackOverflow 질문에 대한 답변을 작성하고 확인하십시오. (이것은 종종 배우는 동안 약간의 명성을 얻는 이점이 있습니다. :-))
  3. 연습이 너무 얇아 질 수 있습니다. 여러 언어로 일하고있는 것 같습니다. 여기에는 많은 장점이 있지만 경험을 희석시키는 단점이 있습니다. 다섯 가지 언어로 일하면서 시간을 보내는 경우 한 언어로 같은 시간을 보내는 것보다 암기 할 수 있습니다. 더 나쁜 것은, 다른 언어들 (당신이 if, elsif, 또는 elif ??) 사이에 당신을 트립시키기 위해 많은 유사하지 않은 비슷한 인식이 있다는 것입니다. 이에 대응하려면 초점을 선명하게하십시오. 차갑게 배우고 배울 한 가지를 선택하십시오. 다음으로 넘어가십시오.

3

적절한 코드를 직접 작성하는 데 집중하면 효율성과 생산성이 향상 될 것이라고 생각합니다. 코드를 찾고, 읽거나 이해하고, 소스를 복사하고, 적절하게 수정하는 데 더 많은 시간이 걸릴 수 있습니다.

스스로 생각해 내면 특정 상황에 더 잘 적응할 수 있으며 잠시 후 이러한 솔루션을 찾는 것보다 더 빨리 나올 것입니다.

내가 보는 방식은 특정 솔루션에 대한 두 번째 의견을 원하는 것처럼 인터넷의 다른 사람들이 어떻게 하는지를 찾는 것입니다. 자신이이 일을 너무 많이하고 싶어하는 경우 동료에게 솔루션에 대한 생각을 물어 보는 것으로 생각하십시오. 15 분마다 동료에게 질문을하면 아마 짜증이 날 것입니다. 그러므로 당신은 더 적은 질문을하고 스스로 그것을 생각해 내려고 노력할 것입니다.

인터넷에서 물건을 찾아보고 싶을 때 이것을 시각화하십시오.


3

모르는 것을 배우는 가장 좋은 방법은 구글입니다! 대부분의 개발자와 동등한 수준이라고 생각합니다. 배낭에 열등감을 넣고 열린 마음으로 들어가십시오.

질문하고, Google에 대해 조사하고, 시도하고 실패하는 것을 두려워하지 마십시오. 그것은 전부 그것의 일부입니다.


3

회사 환경에서 소프트웨어를 개발하려면 상당한 양의 코드를 재사용해야합니다. API가 이미 존재하고 널리 사용되는 경우 함수 / 메소드를 다시 작성하는 이유는 무엇 입니까? 그것은 당신이 쓰는 것과 마찬가지로 효율적이며 시간이 덜 걸릴 것입니다.

물론, 소프트웨어 개발에 성공하려면 키보드를 분리해야하므로 실제로 진행중인 작업을 읽고 이해할 수 있습니다. 모든 웹 프레임 워크를 사용하십시오. 작성중인 코드를 이해하려면 아래에서 진행중인 작업을 알아야하지만 웹 프레임 워크를 처음부터 직접 작성할 필요는 없습니다.

구성 요소 기반 프레임 워크에는 특정 스타일이 필요하므로 프레임 워크 유형을 활용하는 코드를 작성해야하며 더 큰 그림을 이해하면 발생합니다. 더 큰 그림을 배우면 괜찮을 것입니다.


2

맹목적으로 코딩하는 대신 문제를 연구하는 데 아무런 문제가 없다는 것이 이미 주어진 대답에서 분명합니다. 그러나 직접 질문하지 않았기 때문에 해결되지 않은 질문은 왜 그렇게 불안한지, 그리고 무엇을 할 수 있습니까? 결국 많은 사람들이 문제를 겪고 구글에 자신의 길을 가고 자신감을 많이 가지고 있습니다 (...해서는 안되는 사람들조차도)

그래서 뭐 할까? 어쩌면 당신은 방금 수백 개의 pat을 필요로했을 것입니다. 그러나 이것이 효과가 없다면 자동화 된 테스트 및 테스트 주도 개발을 살펴 보는 것이 좋습니다. 당신이 거기 도착하면, 당신은 일 : 당신의 테스트 스위트에서 "모든 테스트를 통과"와 같은 것도 "잘하지"말한다 알고 당신이 바로 그것을 한 적이.

당신은 또한 약간의 도전을 시도해야한다 : 당신은 항상 당신이 이미 알고있는 구문을 찾고 있다고 말한다; 구문을 보지 않고 코드를 작성하도록 강요하면 곧바로 제대로 수행되고 있음을 알게 될 것입니다.


2

개발자는 "위대한"것으로 태어나지 않지만 위대함에 자동으로 경험이 없습니다. 반대로, 경험 부족이 개발자를 "나쁜"것으로 만들지는 않습니다. 훌륭한 개발자와 나쁜 개발자의 차이점은 도메인 지식이 아니라 방법론에 있습니다. 훌륭한 개발자의 특징은 의식적으로 코딩한다는 것입니다. 달리 말하면, 훌륭한 개발자는 왜 자신이 무엇을하고 있는지 항상 알고 있습니다. 개인 윤리의 관점에서 지적 용기와 정직성이 필요합니다.

시간이 걸리고 기초를 이해하는 것이 중요합니다. 더 복잡한 것들이 그 위에 쌓여 있습니다. 언어를 이해하는 데 기초가없고 무대 뒤에서 일어나고있는 일이 있다면 코딩은 단순히 해킹 일 것입니다.


1

따라서 예제가 포함 된 책을 읽고 참조하는 것은 잘못된 프로그래밍입니다. 소수의 사람들이 자신의 API를 문서화하는 것을 보는 것은 우리가 남긴 전부입니다.

나는이 질문을하는 이유가 무엇인지 모른다. 많은 코드 예제를 참조 할 때 내 상황을 읽은 후에 스스로 대답 할 수있다.

저는 16 살 때 거리에있을 때 대학에 갈 기회가 없었습니다. 어떻게 든 24 살에 통신 대학을 통해 공부하고 SCJP, SCJD, SCBCD 및 SCWCD와 같은 벤더 인증을받을 수있었습니다. 나는 때때로 어려움을 겪고 예를 들어 온라인으로 전환해야한다는 것을 인정해야한다. 모르는 사이에 나는 머리에서 뇌종양이 자랐지 만 (2010 년까지는 오렌지 크기). 5 번의 뇌 수술 후 6 주에 화학 / 방사선 요법과 10 개월의 화학 요법을 병행 한 후에도 여전히 프로필에서 볼 수있는 직접 작성된 코딩 된 사이트로 프로그래밍하고 있습니다.

예, 뇌 손상으로 많은 코드 예제가 필요합니다. 그래서 나쁜 프로그래머가됩니까?


당신은 좋은 이유가 있습니다. 물론, 자신의 이야기를 사용하여 쉽게 자신의 이야기를 사용하여 누군가가 코덱을주지 않으면 얻을 수없는 부족한 프로그래머라고 쉽게 주장 할 수 있습니다. 문제는 그것이 공정한 평가인지의 여부입니다.
cHao

1

그래서 당신은 당신이 해커 톤에 갈 것이라고 언급 한 것을 봅니다. 나는 작년 (15 세 이상)에 꽤 많이 갔으며 학습에 좋은 것으로 나타났습니다. 그리고 학습을 위해 위대한 것은 다시는 그렇게 코딩하지 않는 법을 배우는 것을 의미합니다. 나는 주로 내가가는 모든 해커 톤에서 새로운 것을 배우려고 새로운 것을 배울 수있다. 시간 제약이 크므로 찾을 수있는 모든 코드를 붙여 넣기 만하면됩니다. 테스트 할 때 엉덩이를 물게됩니다.

그러나 좋은 점이 나옵니다. A) 버그 테스트 중에 많은 것을 배우십시오. (무겁게 울음) B) 다시는 그렇게 코딩하지 말고 더 나은 코딩 방법을 배우십시오. 또한, 해커 톤에서는 여러분이 전혀 몰랐던 많은 새로운 것들을 가르쳐 줄 수있는 사람들을 만나고, 학교에서는 절대로하지 않을 일들을 할 것입니다.

제가 말하고있는 것은 카피 붙여 넣기가 나쁘다는 것입니다. 아무 것도 배우지 않을 것입니다. 그리고 카피 붙여 넣기로 저장 한 시간은 나중에 버그 테스트 중에 물릴 것이고, 심지어 당신이 쓴 것을 전혀 모릅니다. 오전 8시입니다. 모든 카페인에 연료를 공급합니다. 그러나 코드를 버그 테스트하는 한 이전에 복사 한 모든 것을 배우게 될 것입니다.


0

글쎄, 나는 나 자신을 좋은 프로그래머라고 부르지 않는다. 그러나 내가하는 일은 간단합니다. 무언가를하는 법을 모른다면 실제로 인터넷 주변의 코드 / 예제를 봅니다. 그런 다음 읽은 후에 다시 작성하고 최적화하고 원하는 코드에 가장 적합한 것을 사용하려고합니다.

참고 : 인터넷에서 코드를 읽는 다고해서 개발자가 나쁜 것은 아닙니다 . 다른 사람들이 어떻게 하는지를 보는 것이 항상 좋으며 항상 무언가를 배우게됩니다. 그러나 맹목적으로 복사하는 것은 좋지 않습니다.


-1

개발자 / 학생이 Wikipedia ..에 코드를 프로젝트에 복사 / 붙여 넣기 위해 말하기 만하면 "작업"으로 코드를 가져 오려고하면이 사람이 개발하는 유일한 기술은 'Google 방법'입니다. 삼투 과정이있을 수 있지만 전체가 아닙니다. (대학 과정에서 얼마나 많은 사람들이 이것을하는지 믿지 못할 것입니다)

그러나 다른 사람들의 코드를 분석하고 실제로 코드 자체에서 무슨 일이 일어나고 있는지 생각 하면 사람을 나쁜 개발자로 만들지 않습니다 . 그것은 그들을 결정된 개발자로 만들고 아마도 더 촉각 적이거나 시각적 인 학습 스타일을 나타낼 것입니다. 나는 모범으로 아주 잘 배웁니다. 누군가 나에게 무언가를 말하거나 설명하려고하면, 나는 보통 그들이 이야기하고있는 것을 보여달라고 부탁합니다.

코드를보고 분석하고 배우는 것은 실제로 사용 하는 언어로 읽고 배우기 때문에 시간이 지남에 따라 훌륭한 개발자 가됩니다.

나는 종종 영어를 모국어로하는 ​​것보다 컴퓨터 언어에 대해 잘 알고 있다고 농담합니다. 어떤 질문을 구걸; "Java plz로 설명해 주시겠습니까?"


-1

체스를하는 것 같아요. 우리는 조각들을 개별적으로 점검하고 규칙에 따라 움직일 수있는 곳을 추적하며, 잠재 의식이 참여할 때까지 일정 시간 동안 의식 점검을 거쳐 패턴과 영감을받은 시퀀스를 드러내야합니다.

프로그래밍으로 더 많은 조각과 규칙이있을 수 있습니다. 구문으로 종종 걸림돌이되어 '규칙'을 통해 찾기 위해 영원히 걸리는 버그에 붙어 있지만 결국 잠재 의식은 시작됩니다. 그것이 오래 지속되면 읽을 수 있습니다. 때로는 돌아와서 할 수있는 일에 감탄합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.