프로그래머의 성장 경로 - 도교와 기술을 생각하다

머리말

C국의 전문가 서클 커뮤니티에 공유를 요청한 내용은 다음과 같습니다.

자기 소개

제 이름은 Zheng Haohua이고 풀스택 엔지니어입니다. csdn 이름은 Siege Lion Baiyu입니다.

내 전문적인 경험과 경험이 그룹의 전문가만큼 풍부하지 않기 때문입니다. 오늘은 제 자신의 경험을 바탕으로 여러분과 논의할 열린 질문을 가져왔습니다. 오늘 제가 전문가 여러분과 논의하고 싶은 것은 "프로그래머의 성장 경로-도교와 기술에 대한 생각"입니다.

시작하기 전에 몇 가지 명사를 정의하고 싶습니다. 하나는 코더이고 다른 하나는 프로그래머입니다. 코드 파머는 코드를 작성하는 사람입니다. 프로그래머는 생각할 수 있는 코더입니다. 이 토론은 도교, Dao 및 Art에서 두 가지 개념을 차용합니다. 도는 이론적 문제를 해결하는 데 사용되는 방법론이고 예술은 기술적인 문제를 해결하는 데 사용되는 방법입니다.

성숙의 길

대학에 와서야 프로그래밍을 접하기 시작했는데 C언어의 시작부터 싱글칩마이크로컴퓨터, 임베디드, 사물인터넷의 서버개발, 싱글웹서비스개발, 마이크로서비스개발, 그리고 회사의 saas 플랫폼 개발에. 중간에 회사의 프로젝트 아키텍처 설계에도 참여했고, 작업 과정에서 클라우드 네이티브 관련 지식을 조금 접했습니다. 이 과정은 사실 다양한 기술을 지속적으로 학습하는 과정, 즉 실력을 쌓아가는 과정이다.

수년간의 연구 끝에 상위 레벨(여기서 상위 레벨은 컴퓨터 서비스 응용 프로그램의 계층화를 나타냄)으로 갈수록 기술 업데이트 반복이 빠를수록 학습 능력과 호기심을 유지해야 한다는 것을 알게 되었습니다. 신선한 것을 받아들이라는 명령.

천천히 나는 최종 분석에서 이러한 새로운 것들이 사람과 컴퓨터를 지원하는 도구이며 사람들의 비용 절감과 효율성 증가를 위해 제안된다는 것을 발견했습니다. 그것은 도구이기 때문에 우리가 사용하는 것입니다. 도구는 중립적이며 좋고 나쁨의 구분이 없으며 일부는 손에 적합하지 않은 무기입니다. 이것들은 예술입니다. 즉, 도구입니다. 또한 도구적 사고도 필요합니다. "먼 구세주"에서와 같이 Ding Yuanying은 도교와 예술에 대한 토론에서 " 도가 있지만 예술이 없다면 여전히 예술을 찾을 수 있습니다. 예술이 있지만 방법이 없다면 예술에서 멈추십시오 ."

기술과 도구

예술은 방법이며 반복적으로 배우고 개선할 수 있는 것입니다. 따라서 예술은 적절한 도구를 가리킨다. 개혁 초기 덩샤오핑 할아버지는 고양이가 검은색이든 흰색이든 쥐를 잡을 수 있는 고양이가 좋은 고양이라고 제안했습니다. 예술은 시간, 장소, 사람, 사물에 따라 변한다는 사실을 담고 있을 뿐입니다.

누군가가 프로그래밍 언어의 품질에 대해 논쟁하는 것을 보기 전에 나는 미소를 지으며 아무 말도 하지 않았습니다. 와우, 프론트 엔드 js는 매우 낮지 만 백엔드 java는 좀 더 하이 엔드입니다. 파이썬은 장난감일 뿐이고, 큰 프로젝트에 사용할 방법이 없다거나, 자바가 안정적이다 등등. 그들은 모두 다른 사람의 약점을 공격하기 위해 자신의 강점을 사용합니다. 매우 객관적인 이해가 없습니다.

이 때문에 프로그래밍 언어에 얽매이는 프로그래머도 있다. 모든 시나리오를 실현하기 위한 언어여야 한다고 생각합니다. 아니면 프레임워크에 얽매여 있다.분산 프레임워크를 배운 후 스프링 클라우드 시스템이 가장 좋고 원래 단일 애플리케이션이 낮다고 느낀다. 등등. 이것들은 내가 내 마음 속에 세운 모든 벽이며 나를 묶었습니다. 나는 나 자신을 도구인으로 보지 않았다. 툴맨 툴맨은 도구에 홀린 사람이 아니라 도구를 사용하는 사람이다.

그러나 그들은 각 도구가 특정 문제를 해결하기 위해 발명되었다는 사실을 잊습니다. 도구의 원래 의도를 잊고 발명되었습니다.

프로그래머라면 누구나 반복적인 작업 시나리오를 어느 정도 경험하게 될 것입니다. 이때 도구를 사용하여 자신의 반복 작업을 해결할 생각이 있습니까? 예를 들어 효율성을 개선할 수 있는 기존 도구를 찾으십시오. 또는 스크립트를 작성하여 반복적인 작업에서 벗어나십시오. 대학시절 기말고사에 대한 학교의 학사행정 결과 통보를 솔선수범할 수 없어 매일매일 보러 다녀야 했습니다. 신입생 때 어리석게도 며칠에 한 번씩 학사시스템을 확인하러 갔다. 프로그래밍을 배운 후 매일 교육행정시스템의 데이터를 크롤링하는 파이썬 스크립트를 작성했고, 데이터가 업데이트될 때마다 공식 계정을 통해 내 위챗에 정보를 적극적으로 푸시했다. 그때부터 그는 그 반에서 그 결과를 아는 첫 번째 학생이 되었습니다.

도와 생각

기술과 도구의 관계를 논하면서 현상을 통해 본질을 본다 도구 이면에는 공통점이 있고 그 이면의 공통점은 도이다. 도는 반드시 이해해야만 개선되는 사물이자 영역이며, 추상적이고 규칙적이며 비교적 안정적이다. 여기서 도는 일종의 도구적 사고라고 생각합니다.

예를 들어, 프로그래밍 언어는 모두 컴퓨터 원칙을 따르고 알고리즘 및 데이터 구조를 구현하는 데 사용할 수 있으며 다양한 프로그래밍 아키텍처에 내장될 수 있습니다. c/C++, golang, python, java 등 기본적으로 인간이 이해할 수 있는 문법을 사용하여 원하는 동작을 기계가 이해하고 실행할 수 있는 언어를 설명합니다. 예를 들어 서버 백엔드를 수행하는 것과 같은 한 가지 작업을 완료한 후. 네 가지 모두 달성할 수 있지만 실현의 난이도는 같지 않습니다. 사용법도 다릅니다. c/C++로 구현되는 실시간 서비스는 다른 언어와 비교할 수 없기 때문에 대부분의 온라인 게임 회사의 서버는 c/C++로 구현됩니다. 물론 Golang은 높은 동시성을 위해 Google에서 설계한 서버 언어이기 때문에 일부 회사는 서서히 golang으로 전환하고 있습니다. 그러나 이것이 게임의 완전한 백엔드가 C/C++라는 것을 의미하는 것은 아니며, 완전한 백엔드 서비스는 사실 실시간 게임 외에도 게임 소셜도 있습니다.게임 소셜 백엔드의 경우 서비스를 종료하려면 Java OK를 사용해야 하며 Python도 마찬가지입니다. 사실 그것들은 단지 도구일 뿐입니다.

같은 방식으로 또 다른 예를 들면 도메인 기반 디자인 DDD와 같은 것입니다.상당 수의 프로그래머는 DDD가 일종의 가식적인 접근 방식이라고 생각할 것입니다.DDD를 사용하는 것은 코드의 복잡성을 증가시키는 것 외에는 효과가 없습니다.또한 몇 가지가 있습니다. DDD는 성숙한 프레임워크가 없는 미성숙한 것으로 매우 가상적인 디자인 패턴입니다.

하지만 DDD(Domain Driven Design)는 사실 디자인 싱킹의 한 방식으로, 해결하고자 하는 문제는 전통적인 소프트웨어 디자인 방식의 커뮤니케이션 모호성으로 인해 발생하는 문제입니다.

DDD(Domain Driven Design)는 소프트웨어를 잘 만드는 방법과 객체 지향 기술을 더 잘 사용하는 방법을 알려줍니다 . DDD는 디자인 사고 방식, 즉 Tao 이기 때문에 소프트웨어 설계 및 구현 방법론의 전체 세트를 제공하며 소위 "표준"이 전혀 없습니다. DDD 구현에 대한 생각이 모두 다르고 코드 구분도 다르기 때문에 관련 소프트웨어 프레임워크가 없는 것도 이 때문이다. DDD의 설계 개념을 준수하는 한. 각 사람의 구체적인 착륙 방법은 기술의 구체화입니다. 즉, 사람마다 도에 대한 이해가 다르고 발휘되는 기술도 다르다. 동시에 DDD 방법론은 착륙 시 추적 및 코드 검토에 대한 사양을 준수하도록 요구합니다. 이를 통해 팀은 더 잘 협업하고 더 강력한 시스템을 구축할 수 있습니다.

추신

도는 사상, 사고방식, 방법론이다. 프로그래밍 세계에서는 알고리즘, 아키텍처 및 디자인 패턴입니다. 도는 예술을 인도하고 예술은 도의 담체이며 방법론의 구체적인 구현 방법입니다. 맨 처음에 저는 더 많이 배울수록 기술 업데이트가 반복적으로 빠르다는 것을 더 많이 알게 되었고 계속해서 스스로 학습해야 한다고 언급했습니다. 예술은 시대, 장소, 사람, 사건에 따라 변하는 구체적인 방법이기 때문이다. 사실 그 이면의 디자인 패턴 등은 그리 쉽게 구식이 아닙니다.

따라서 프로그래밍 과정에서 요구 사항에 직면했을 때 디자인에 더 많은 시간을 할애하고 이 요구 사항을 어떻게 수행할지 고민해야 합니다. 후속 확장 및 고 가용성에 편리합니다. 나오자마자 손으로 코드를 작성하는 대신. 어떤 사람들은 이것이 건축가가 고려해야 할 사항이 아닌가라고 말할 것입니다. 하지만 더 생각하는 것이 나쁠 것은 없다고 생각합니다. 적어도 생각할 때는 코더가 아니라 프로그래머입니다.

위는 Xiaosheng의 겸손한 의견 일 뿐이며 다른 사람들을 끌어들이는 데 사용됩니다. 전문가도 비판하고 수정하도록 초대됩니다.

뒤에 쓰여진

도움이 되셨다면 하나의 버튼과 세 개의 연속된 링크로 Siege Lion Baiyu를 지원 하고 이 기사를 더 많은 친구들과 공유하세요. 당신의 소소한 응원, 나의 무한한 창작력

추천

출처blog.csdn.net/zhh763984017/article/details/126888846