우수한 프로그래머가 새로운 기술을 생각하고 배우는 원리와 방법

최근에 저는 여러 MVCPHP 프레임워크에 대해 배웠습니다. 두 개는 회사 내부에 있습니다. 처리 논리부터 서비스에서 레이아웃까지 유사하다는 것을 알았습니다. XML 또는 주석보다... 아마도 이 사고의 고리에서 더 이상 벗어날 수 없을 것 같은 느낌이 듭니다. ?

오늘날은 흥미로운 컨셉의 시대입니다. oschina에는 다양한 기술이 끊임없이 등장하고 있습니다. 어떤 기술을 배울 가치가 있나요? ?

한 친구가 관심을 갖고 Android에서 몇 가지 개발 기술을 배우고 싶다고 말했습니다. 몇 달이 지나니 작은 프로그램도 많이 만들 수 있게 됐다고 하더군요. 그런데 지금 생각해보면 기술을 익히는 것도 좋은데 취미 외에 또 뭐가 있겠습니까? 그는 "안드로이드 플랫폼을 작업에 사용하지 않으면 배워서 무슨 소용이 있느냐"고 말했다.

기술을 배우는 것은 재미있는 일인가요, 아니면 고통스러운 일인가요? 공부할 때 Hou Jie가 번역한 "간단한 언어로 배우기 MFC "를 구입한 적이 있습니다. 그 당시에는 좀 어려운 것 같아서 억지로 읽었습니다. 3분 동안 읽어 보세요. 첫째, 계속 읽을 의지가 정말 없어요. 나는 그 책에서 어떤 기쁨도 느낄 수 없었고 그 당시에는 그 책이 생동감으로 가득 차 있는 것 같았습니다.

위와 같은 이야기가 너무 많습니다. 프로그래머들은 (나를 포함하여) 열심히 공부하지만 어떤 사람들은 좋은 결과가 없고 어떤 사람들은 고통에 가득 차 있으며 어떤 사람들은 내가 그것을 배웠는지조차 모릅니다. 목적.

국내 교육 시스템이 이런 사람들을 키워왔습니다.

열심히 일하고 진취적이며 기술을 사랑하고 소프트웨어 산업에 기꺼이 참여하며 고품질 코드를 작성하려는 의지가 있으며 업계에 관심이 많으며 탄탄한 기본 지식을 배우려는 의지가 있습니다. 그들은 뜨거운 신기술에 열광하고 있습니다...

몇 년이 지나면 그들은 넓은 비전, 폭넓은 경험, 경험 있고 예리한 말과 업계 동향에 대한 좋은 이해를 갖고 있음이 분명합니다.

그러나...

생각하는 능력이 부족해요.

사고력 부족으로 인해 쉽게 다음 현상이 발생할 수 있습니다.

디자인을 못해요

문제가 발생하면 장단점을 주의 깊게 분석하지 않고 보고 배운 익숙한 프레임워크, 솔루션, 모델을 적용하고 가능한 한 현재 문제에 가장 가까운 솔루션을 찾으려고 노력합니다.

시스템 설계를 어떻게 하는지 모르는 분들도 계십니다. 나는 "비즈니스만 이해하고 기술은 이해하지 못하는" 소위 "건축가" 몇 명과 접촉했습니다. 이러한 방식으로 설계된 시스템은 기능적 요구 사항만 충족할 수 있으며 포럼의 일부 특정 문제에 대한 토론 주제는 몇 가지 기본 사항을 드러냅니다. 해설자는 "XXX대용량 솔루션", "플래시 세일 시스템의 궁극적인 아키텍처" 등 "비즈니스가 아닌 기술만 이야기한다"고 말했다. 특정 광범위한 유형의 문제에 대해 논의하고 모든 곳에서 작동하는 보편적인 솔루션을 고안합니다.

객체 지향 설계 방법을 모르고 추상화 및 분리 능력이 부족한 예가 훨씬 더 많습니다. 친구가 자기 회사에 Ruby를 작성하는 옛 직원이 있다고 하더군요. 대규모 프로젝트의 경우 코드에 God 클래스가 하나만 있어서 모든 문제가 해결되었습니다.

자신의 관점을 고집할 수 없음

이것은 인터뷰 중에 가장 쉽게 관찰할 수 있습니다. 지원자에는 갓 졸업한 졸업생과 10년 이상 근무한 숙련된 실무자가 포함됩니다. 대략적인 계획을 제시하고 어느 정도 다듬어지기 전에는 장단점을 논평하기 어렵다. 그러나 가볍게 도전하면 금세 포기하게 된다. 그의 독창적인 아이디어를 바탕으로 당신의 아이디어를 실현했습니다.

예를 들어 SNS 시스템에서 서버는 클라이언트에게 메시지를 어떻게 알리나요? 이 문제에 대한 해결책은 클라이언트 폴링, 서비스 종료 등 다양합니다holdhold 연결 푸시 등은 각각 장단점이 있습니다. 후보자는 자신의 의견을 가지고 있어야합니다.

문제에 대한 해결책을 구체화할 수 없음

말하는 사람과 행동하는 사람을 어떻게 구별하나요? 그에게 구체적인 질문을 하는 것이 가장 좋은 방법이다. 처음 일을 시작했을 때 행사나 토론에서 큰 소리로 말하는 사람들을 존경하곤 했습니다. 그러나 나중에 나는 말할 수 있는 사람이 너무 많다는 것을 점차 알게 되었습니다. 코딩에 이르기까지 디자인을 다듬는 것은 프로그래머의 진정한 테스트입니다. 물론, 소프트웨어 디자인을 하는 사람이 코딩을 잘 할 필요가 없고, 아키텍트가 수석 프로그래머일 필요도 없다고 생각한다면 :)은 할 말이 없습니다.

배울 수 있으면 매우 빠르게 성장할 수 있지만, 생각할 수 없으면 항상 남들보다 뒤처질 수 있습니다.

새로운 기술을 배우는 것에 대해 더 많이 생각해야 한다고 생각합니다. 사람마다 학습 동기가 다릅니다. 외부 세계에 의해 강요되지 않는 한, 신기술 학습에 대한 나의 견해는 다음과 같이 요약될 수 있습니다.

그것이 해결하고 싶은 문제, 소위 문제 영역이라는 것이 내가 관심을 갖는 부분인가?

운영 체제의 기본 구현을 연구하지 않았습니다. 가치가 없다는 것이 아니라 문제 도메인의 영향입니다. 이 분야에서 뭔가를 하세요).

이전 솔루션과 비교했을 때 어떤 장점이 있고 중요한가요?

이것은 경쟁입니다. 기술이 반복될 여지는 없습니다(물론 Microsoft :)는 예외입니다. ) , 인터넷에 있는 동일한 유형의 웹사이트와 마찬가지로 결국 두세 개만이 경쟁하게 됩니다. Groovy처럼 너무 좋은데 Scala로는 둘 중 하나가 죽을 것 같아요(Groovy창업자님이 Scala를 미리 알았더라면 Groovy 어떤 일이 일어났나요? 자세한 내용은 블로그를 Google에서 검색해 보세요. 구현과 효과를 살펴보면서 배우고 생각해 볼 만한 흥미로운 아이디어가 있나요?

가장 대답하기 어려운 질문입니다. 작년 초에 연락하기 시작한

Node.js를 예로 들면, 백엔드(예: 포틀릿 등) 프런트엔드에 배치할 때 백엔드는 한 가지 유형의 페이지 서비스(페이지 템플릿)와 관리하기 쉬운 여러 API 인터페이스만 유지합니다. , 이는 백엔드 시스템의 복잡성을 크게 단순화하며 이전에는 볼 수 없었던 압력을 프런트엔드로 분산시킬 수 있습니다. 이 세 가지 질문에 대해 생각해 보고 가치 있다고 생각한 후에 공부를 시작했습니다. 그렇지 않으면 나에게는 깊이 들어가고 싶지 않은 문제일 뿐이고 이해하고 싶을 뿐입니다.

새로운 기술을 배우는 방법에 대해서는 다음과 같이 말씀드리고 싶습니다.

진입점 찾기

BlueDavy

의 블로그에 나온 문장이 정말 마음에 듭니다. 이론을 이해하지 못하면 이론을 배우게 됩니다!” 결국 실전으로 내려가는 것이 가장 좋지만 원리를 소개하는 글로 시작하는 것이 익숙하다면 나쁘지 않은 선택일 수도 있습니다. 게다가 여러 인터넷 기업(

Amazon

의EC2)의 클라우드 플랫폼을 이해하는 등 현실적으로는 몇 가지 제약이 있을 것입니다. , M$의 Azure 등), 이들 기업의 직원이 아니면 입사하기 어렵습니다. 그것. 나만의 관심 장소를 찾아보세요

학습은 재미있어야 하며, 뇌가 거부하면 이 새로운 기술을 익히는 것이 쉽지 않다고 생각합니다. 관심 지점을 찾을 수 없다면 새로운 기술이 배울 가치가 있는지에 대한 이전 요점으로 돌아가는 것이 좋습니다. 관심이 없는데 왜 배우겠습니까? 시안 소프트웨어 교육

비교를 잘하세요

비교란 무엇과 비교할 것인가라는 아주 쉬운 사고방식입니다. 유사한 기술과 비교하고, 운영체제, 네트워크 등 인프라의 사례와 비교하고, 마지막으로 생활 속의 사례와 비교한다. (예를 들어

JAVANIO

구현이 좋은 예이다) . 지속적인 피드백 받기

피드백이란 무엇인가요?

HelloWorld

의 예를 만드는 것은 특정 구현 원리를 이해하고, 다른 유사한 구현을 생각하고, 깨달음을 얻는 것도 일종의 환원입니다. 학습 과정에서 지속적인 피드백을 받는다는 것은 계속해서 성취감을 얻게 된다는 의미이며, 이는 계속하려는 동기 중 하나입니다.

위 내용은 우수한 프로그래머가 새로운 기술을 생각하고 배우는 데 필요한 원리와 방법을 그 측면도 포함하여 소개하고 있으며, PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.