드루팔, 국내 오픈소스 환경 살펴보기 위해 thinkphp와 비교-ThinkPHP-php.cn

오늘은 ThinkPHP와 Drupal을 비교하여 국내외 소프트웨어 산업 현황과 국내 오픈소스 환경을 살펴보겠습니다!

드루팔, 국내 오픈소스 환경 살펴보기 위해 thinkphp와 비교

주거, 결혼, 의료, 교육, 노인요양은 각각 큰 산입니다. "돈 버는 것"이 최우선이어야 합니다. 누가 돈을 벌 시간이 있습니까? 그래서 단 두 명의 핵심 개발자가 만든 ThinkPHP는 많은 사람들의 희망이 되었습니다. 반면, 오픈소스 소프트웨어 커뮤니티 모임에서 우리는 50대들의 모습을 자주 볼 수 있습니다. 여전히 눈에 미소를 짓고 있는 60대. 라이트는 삶의 의미를 찾고 자신의 삶의 축적을 오픈소스에 투입하여 세상을 밝게 변화시킬 수 있다는 꿈을 꿉니다. 그리하여 드루팔은 모두의 칭찬을 받고 빠르게 별의 바다를 향해 항해하게 되었다. 이 글은 같은 글을 읽는 사람들이 어디로 가야 할지 고민하면서 슬픈 이야기를 전하고 있습니다.

ThinkPHP와 Drupal을 비교하여 중국과 외국 소프트웨어 산업의 현황을 살펴보세요

ThinkPHP와 Drupal(중국어로는 "물방울"로 번역됨)에 대해 이야기하면 많은 개발자들이 궁금해하겠지만, Drupal의 관점에서 보면 중국과 외국 소프트웨어 생태계의 발전, 이것은 실제로 토론을 위한 좋은 출발점입니다. 이 기사에서는 다양한 측면에서 두 시스템을 비교하지만 비교가 이 기사를 작성하는 주요 목적은 아닙니다. 중국과 외국 소프트웨어 산업의 차이점과 그로 인해 발생하는 몇 가지 생각은 개발자가 경력을 계획하는 데 도움이 되고 IT 의사 결정자에게 의사 결정 기반을 제공합니다.

두 시스템 모두 오픈 소스, 무료 PHP 애플리케이션입니다. 먼저 간략한 소개를 하겠습니다.

ThinkPHP:

제품 포지셔닝: PHP 개발 프레임워크, 개발자는 이를 기반으로 자신의 애플리케이션 시스템을 계속 개발하고 구축할 수 있습니다.

개발 조직: 국내 "Shanghai Dingxiang Information Technology Co., Ltd."에서 개발

설립자: Liu Chen, 정보가 많지 않음, Baidu Query는 오픈 소스 소프트웨어 수석 컨설턴트, 수석 PHP 프로그래머, Kanyun CEO 등 15년 이상의 인터넷 제품 개발 및 관리 경험, 주요 연구 분야는 웹 애플리케이션 아키텍처 및 개발, 제품 사용자 경험 디자인, 국내 오픈 소스 업계에 전념

개발 시기: 2006년 초 탄생

오픈 소스 프로토콜: Apache 2

공식 웹사이트 주소: http://www.thinkphp.cn/

사용자 그룹: 중국 국내 중소기업은 국내 개발자계에서 높은 평판을 얻고 있습니다. 공식 웹사이트는 스스로를 "가장 영향력 있는 PHP 프레임워크이자 선구자"라고 표현합니다. in China” "

유명 사례: 56 Group, Lenovo Question Bar, CYTS Happy Travel, Pocari Sweat, Starbucks, Metersbonwe's Bangou Mall, TCL 온라인 몰, Sina WeChat, Aoxing, China Cheyou Technology 등

팀 규모: 있음 공식 데이터는 아니지만 프레임워크의 각 파일에는 작성자 정보가 있습니다. 이 통계에 따르면 두 명의 주요 개발자를 포함하여 총 7명이 있습니다(코드의 90% 이상 기여). 이 데이터에는 개발자가 포함되지 않습니다. Qicchacha 플랫폼에서 Dingxiang Company의 쿼리 결과에 따르면, 회사 규모는 50명 미만이고 피보험자 수는 3명입니다. 시스템 파일: 현재 버전 6.0.7을 기준으로 계산되었습니다. 초기 설치 파일 수 569개, 2.41MB 공간 차지

Drupal: 제품 포지셔닝: APP의 백엔드에 사용되는 완전한 백엔드 시스템(백엔드 데이터 및 제어 센터), 미니 프로그램, 웹 사이트, 사물 인터넷 등 개발

개발 조직: Drupal 재단이 조직하고 전 세계 200개 이상의 국가에서 공동 구축한 비영리 오픈 소스 커뮤니티

창립자: 원래 Drupal이 시작함 벨기에의 Dries Buytaert는 2008년 대학 박사 학위 논문인 "Java 응용 프로그램" "성능 분석 및 최적화 분석 기술"을 발표했으며 Java의 발명가인 James Gosling은 그의 박사 학위 방어 위원회의 회원입니다. //dri.es/about

개발 시기: 2000년 최초 탄생

오픈 소스 계약: GPL 2.0

공식 웹사이트 주소: https://www.Drupal.org/

사용자 그룹: 기업, 정부 기관 , 대학, 개인 등 전 세계 500대 기업의 시장 점유율 80% 이상, 유명한 IDE: phpstorm이 새로운 Drupal 프로젝트를 직접 통합합니다

유명 사례: 국내: Huawei, JD. com, Baidu, Tencent, Tsinghua, Peking University, Guizhou Municipal Government Station Group, Zhenkongfu 등 외국: Tesla, Google, Honda, Qualcomm, UN, 유럽 연합, Harvard University, MIT, Disney, NASA, Pfizer Pharmaceuticals,

팀 규모:

핵심 개발자가 1,800명 이상인 세계에서 가장 크고 활동적인 오픈 소스 커뮤니티를 보유하고 있습니다. 2,000명 이상의 주 기여자(코드, 문서, 디자이너 등)가 120,000명 이상 있습니다. 중국 하위 커뮤니티의 사람들이며, 주요 자동차 회사인 Acquia에는 1,100명이 넘는 직원이 있습니다. 현재 매주 평균 약 1,300개의 코드 제출이 생성됩니다.

시스템 파일: 현재 9.1.7 버전 기준, 초기 설치된 파일 수는 18,770개, 71.2MB의 공간을 차지합니다

ThinkPHP와 Drupal을 사용하는 이유:

하나는 중국에서 인기 있는 프레임워크이고, 다른 하나는 국제적으로 인기가 있는 완전한 백엔드 시스템입니다(또한 세계에서 가장 강력하고 유연한 시스템이기도 하며 규모로 판단하면 그렇지 않습니다). 시장 포지셔닝 측면에서는 비교할 수 없지만, 이를 탐구하는 것은 중국과 외국 소프트웨어 생태계를 이해하는 데 큰 의미가 있습니다. 게다가 ThinkPHP가 할 수 있는 모든 것을 Drupal이 할 수 있다고 직접 말씀드리면 어떨까요? , 더 우아하고 간결합니까? 이제 상황이 흥미로워지고 있습니다. 계속하겠습니다.

보통 Drupal을 사용하는 국내 개발자들은 다년간의 경험을 가진 개발 베테랑들이죠. 시대에 따라 단계별로 ThinkPHP를 알고 있거나 이해하고 있어야 하지만, ThinkPHP를 사용하는 개발자들은 반드시 이해하지 못할 수도 있습니다. Drupal에서 ThinkPHP를 사용하는 개발자가 ThinkPHP를 선택하는 이유는 일반적으로 프레임워크가 기본 PHP보다 공통 기반을 더 많이 제공하고 Imperial CMS와 같은 보조 시스템 개발에 비해 유연하고 자유롭기 때문입니다. 기능을 마음대로 구현할 수 있지만 Drupal 앞에서는 상황이 달라져 개발자가 보물을 찾은 것 같은 느낌을 받을 수 있습니다. 여기서는 Drupal 시스템 전체가 내장되어 있음을 간략하게 소개해야 합니다. 레이어:

하단 레이어:

인기 있는 Symfony 프레임워크를 기반으로 하는 프레임워크 레이어입니다. Symfony는 PHP의 업계 표준이자 또 다른 유명한 PHP인 Laravel의 많은 부분이라고 할 수 있습니다. Symfony 프레임워크를 기반으로 하거나 Symfony에서 나온 것입니다. Symfony 프레임워크 개발자는 Drupal 개발을 빠르게 시작할 수 있습니다. Symfony 프레임워크의 저자인 Fabian은 그의 유명한 작품 중 하나인 Twig 템플릿 엔진입니다. Drupal은 Symfony의 가장 유명한 예이기도 합니다. 공식 웹사이트에는 Drupal이 먼저 나열되어 있으며 Drupal 커뮤니티도 Symfony 코드 기여에 참여하고 있습니다.

두 번째 계층:

은 데이터 계층으로, 위쪽으로 다양한 데이터를 제공합니다. 데이터베이스 캡슐화는 이 계층에 속합니다. ThinkPHP의 ORM 개념과 모델 개념은 매우 유사합니다.

세 번째 레이어:

애플리케이션 레이어 개발자는 이 레이어에서 다양한 비즈니스 로직을 처리합니다.

여기서 개발자가 Drupal을 사용할 때 반드시 레이어별로 호출할 필요는 없지만 특정 레이어를 직접 향하므로 프레임워크 레이어를 향해 직접 개발할 때 ThinkPHP 개발자가 ThinkPHP 프레임워크를 직접 사용하는 것처럼 전체 시스템을 프레임워크로 사용할 수 있습니다. 이것이 바로 ThinkPHP가 할 수 있는 모든 것을 Drupal이 할 수 있는 이유입니다. 차이점은 Drupal이 Symfony 프레임워크를 사용한다는 점입니다. 여담이지만 ThinkPHP는 Symfony의 영향을 많이 받았으며 심지어 Symfony 프레임워크의 일부를 직접 채택하기도 했습니다. "표절"이라는 단어를 사용할 필요가 없습니다. 그리고 "학습"을 사용하면 주요 프로세스는 거의 동일하지만 성숙도와 세부 사항에 큰 차이가 있습니다.

In 인류의 조상들이 밧줄을 묶어 숫자를 세던 시절, 하나의 과일은 과일이고, 물고기는 물고기다. 불의 사용에 이어 숫자와 수학의 발명 등, 시간과 공간 속에서 인간은 끊임없이 세계를 탐색하고 추상화해 왔으며, 이를 통해 오늘날의 문명이 탄생했다고 할 수 있다. 추상화 정도가 높을수록 그 의미는 더욱 강해지고 본질에 더욱 직접적으로 다가갑니다.

많은 훌륭한 작품은 축적하는 데 막대한 인력과 시간이 필요한데 ThinkPHP와 Symfony, ThinkPHP와 Drupal 간의 축적 격차는 얼마나 큽니까? 여기서 제가 직접적이고 단호하게 말씀드릴 수 있는 것은 초등학교와 대학교, 중학교와 고등학교 사이에 격차가 있다는 것입니다. 가장 큰 이유는 커뮤니티 규모와 생태, 시간 때문입니다. ThinkPHP와 Symfony는 둘 다 프레임워크이며 가장 직접적인 경쟁자입니다. ThinkPHP가 존재하려면 독립적인 혁신의 길이 필요하지만 이는 개발자로서 매우 당황스러운 일입니다. 심포니에 대해서? 같은 수준의 CI 프레임워크(CodeIgniter)는 완전히 독립적으로 발전해왔습니다. 많은 글로벌 순위에서 ThinkPHP의 그림자를 볼 수 없습니다. 그러나 중국에서는 많은 채용 정보에서 ThinkPHP의 그림자를 볼 수 있습니다. 이상한 현상 ThinkPHP는 완전히 국산 제품이기 때문에 주석 문서까지 중국어로 되어 있습니다. 이 글에서는 ThinkPHP를 중국과 외국 소프트웨어의 현황을 연구하는 출발점으로 삼았습니다.

좋은 시스템이란 무엇인가요? 우리에게 필요한 것은 무엇입니까?

일을 잘하려면 먼저 도구를 갈고 닦아야 합니다. 아래에서는 ThinkPHP와 Drupal을 비교해 보겠습니다.

완성도 :

소위 완전성이란 모든 상황을 완전히 고려하여 설계된 도구 또는 구성 요소라고 생각할 수 있습니다. 예를 들어 PHP에서 기본적으로 제공하는 문자열 차단 기능은 UTF-8 문자를 자르고 잘못된 문자를 생성하며, 차단 기능을 설계하면 이 기능이 작동하지 않을 뿐만 아니라 영어 단어도 잘리지 않고 HTML에서 태그도 잘리지 않도록 고려됩니다. 그러면 도구가 PHP 기본 기능보다 더 완벽해질 것입니다. 만족할 수 없는 열이 있다는 것을 알게 되면 완성도를 높이기 위해 이를 개선해야 합니다. Drupal의 많은 부분의 디자인은 "완전"합니다. Drupal은 계속 탐색하고 발전하지만 이 정도의 완성도는 ThinkPHP를 훨씬 뛰어넘습니다. 예를 들어 Drupal의 라우팅 시스템은 도메인 이름, 프로토콜, HTTP 방법, 데이터 형식, 옵션 등을 기반으로 자연스럽게 라우팅을 지원할 수 있으며 모두 일치할 때 우선순위 분류가 있는데 ThinkPHP에서는 이러한 기능을 완전히 사용할 수 없습니다. 이 구성 요소 디자인의 완성도는 거래의 본질에 대한 깊이 있는 이해와 많은 양의 개발 경험에 달려 있습니다.

표준화:

표준화는 대규모 협업을 위한 전제 조건입니다. 시스템 계층 구조, 시스템 간 통신, 분리된 구성 요소 등은 모두 표준화와 분리될 수 없습니다. Drupal은 자체 시스템이 아닌 완전히 RFC 문서를 지향합니다. . 의견이나 RFC에 대한 참조는 IT 인터넷의 초석입니다. 이는 사용자가 종종 무시하는 경우가 있지만 매우 중요합니다.

정직성:

개발된 구성 요소를 함께 모아 모두가 사용하면 완성도가 높아집니다. 그러면 사람들이 스스로 바퀴를 재발명할 필요가 없으며 결국 정직성이 촉진됩니다. 완성도 향상 Symfony와 Drupal은 구성요소와 모듈 형태로 무결성 문제를 해결합니다.

낮은 결합도:

각 구성 요소에 개발 및 개선을 위한 더 많은 공간을 제공하기 위해 시스템 설계의 구성 요소를 최대한 분리해야 하며, 불량 구성 요소도 쉽게 모듈식으로 교체할 수 있습니다. 연결을 위한 설계 코어는 모듈식입니다. 사용자는 기능 부족과 업그레이드 방해를 방지하기 위해 사용자 공간의 모든 코어 파일을 직접 수정할 수 있습니다.

경계를 마스터하세요:

좋은 시스템은 적절한 제어가 가능한 시스템일 수밖에 없지만 이는 실제로 약간 어렵고 자비로운 사람들은 서로 다른 의견을 가지고 있습니다. 일반적으로 일반적인 방향이나 백본 시스템은 다음과 같습니다. 간단합니다. 예를 들어 ThinkPHP는 라우팅 매개변수를 기반으로 라우팅 컨트롤러 결정을 지원합니다. 즉, Route::get(':action/blog/:id', 'Blog/:action');이지만 Drupal은 지원합니다. 이를 허용하지 않으면 구현이 유사합니다. 즉, 효과는 라우팅 수준에서 구현되지 않고 컨트롤러 수준에서 구현되어야 합니다. 이로 인해 라우팅 시스템이 더 간결해지고 시스템 아키텍처가 더 명확해집니다. Drupal 시스템의 백본은 매우 간단하고 깔끔합니다. 세부적인 기능을 원할 때 먼저 해당 큰 지류를 입력한 다음 다른 세부 지류를 입력하는 것과 같습니다. 하지만 당신은 어떤 방식을 선호하시나요?

단순함:

간단하려면 시스템에 명확한 프로세스, 통일된 호출 및 일관된 규칙이 있어야 합니다. 추가 항목은 허용되지 않거나 최대한 피해야 합니다. 새로 온 사람이 배우고 추적하고 문제를 해결하는 것이 매우 편리합니다.

활력:

시스템의 활력도 지속가능성에 있습니다. 생태계와 개발자는 시스템의 자양분입니다. 이에 대해서는 아래에서 다루겠지만 여기서는 생략하겠습니다.

ThinkPHP와 Drupal의 비교:

ThinkPHP와 Drupal을 비교하면 일반적으로 ThinkPHP는 추상화가 부족하고 축적이 부족한데 비해 Drupal은 수년간 경험한 것입니다. 어른들은 더 많은 것을 알고, 사물 뒤에 있는 일반적인 원리를 알고, 더 나아가 건물을 짓는다고 가정합니다. ThinkPHP는 콘크리트, 벽돌, 철근 등과 같은 기본적인 건축 자재를 제공합니다. 개발자는 건축 방법, 설계 방법을 탐구해야 합니다. Drupal은 기본 자재를 제공할 뿐만 아니라 시공팀과 디자인 연구소도 함께 제공하는 경우가 많습니다. 건물이 어떤 느낌과 기능을 갖기를 원하는지(어떤 것을 접하게 되는지)만 말하면 됩니다. 요구 사항은 일반적으로 다른 사람들이 직면하여 설치할 수 있는 많은 기여 모듈을 형성합니다.) 물론 관심이 있는 경우 구성 프로세스에 참여하여 맞춤형 결과를 얻을 수도 있습니다.

이 장에서는 기술 아키텍처 수준에서 두 가지를 비교합니다. 개발자가 아니거나 특정 기술에 관심이 없다면 이 장을 바로 건너뛰고 다음 장으로 넘어가세요. 다음은 ThinkPHP 6.0의 최신 버전입니다. .7 및 Drupal 9.1.7은 제한된 공간으로 인해 비교를 위해 몇 가지 중요한 콘텐츠만 선택합니다:

이벤트:

ThinkPHP에서는 이벤트가 원래의 동작과 Hook 메커니즘을 대체하도록 배치되어 있습니다. 작성자가 이벤트와 Hook의 본질적인 차이점을 인식하지 못하고 있는 것을 볼 수 있습니다. 동일한 점은 타사 코드가 현재 개입하는 데 사용된다는 것입니다. 그러나 이러한 일반적인 전제 하에서 Hooks는 참여에 중점을 두고 이벤트는 알림에 중점을 둡니다. ThinkPHP는 이를 혼동하는 반면, Drupal은 ThinkPHP의 "개념에 대한 이해가 부족합니다. "이벤트"는 또한 구현 문제로 이어집니다. 느슨하고 복잡하며 중대한 기능적 결함이 있습니다. 예를 들어 ThinkPHP 이벤트에는 우선 순위 개념이 없으며 이는 주문 요구 사항이 있을 때 중요합니다. 동시에 이벤트가 없습니다. 예를 들어 ThinkPHP에서는 이벤트 클래스 구현이 필요하지 않습니다. 실제로 이벤트를 처리하려면 매개변수를 전달해야 하며 처리 결과를 이벤트 소스로 피드백해야 합니다. ThinkPHP는 매우 기본적이며 Drupal은 이벤트 디스패처 서비스를 사용하여 모든 이벤트를 처리하는데 이는 구독자에게 매우 중요하며 리스너에 대한 특별한 제한이 없으며 시스템 어디에서나 이벤트 관련 로직을 처리하기만 하면 됩니다. 이벤트 디스패처 서비스를 만나보세요

미들웨어:

ThinkPHP와 Drupal에는 "미들웨어"라는 개념이 있지만 둘 다 위치가 매우 다릅니다. ThinkPHP에서 미들웨어로 구현되는 기능은 Drupal의 이벤트 디스패처에서 처리됩니다. 예를 들어 ThinkPHP 문서에는 미들웨어가 주로 애플리케이션의 HTTP 요청을 가로채거나 필터링하는 데 사용된다고 언급되어 있습니다. 이는 Drupal의 경우입니다. 요청 이벤트를 디스패칭하는 것도 라우팅 미들웨어 및 컨트롤러 미들웨어와 동일합니다. Drupal의 미들웨어의 주요 기능은 HTTP 처리 코어를 1개에서 다중으로 변경하는 것입니다. Drupal의 논리적 아키텍처는 ThinkPHP보다 훨씬 우아하고 명확합니다. 이는 ThinkPHP가 이벤트 메커니즘을 충분히 이해하지 못하기 때문에 발생합니다. 시스템 구조가 지저분하고 향후 업그레이드에 부담을 줍니다

항목 파일:

두 개 두 사용자의 항목 파일은 매우 간단하며 로직은 비교적 유사합니다.

1 Drupal이 직접 주입합니다. 요청 객체를 엔트리 파일의 프로세싱 코어에 집어넣는 것으로 말 그대로 "모든 웹 시스템은 요청을 "응답형 시스템"으로 변환한다"는 개념을 구현한 것으로 ThinkPHP의 HTTP 서비스의 실행 메소드도 사용 가능하지만 입구에는 반영되지 않는다. 그러나 본질적인 차이점은 없습니다. ThinkPHP에는 "하위 요청" 기능, 즉 시스템이 실행되는 동안 처리를 위해 자체적으로 요청을 제출하는 기능이 부족하다는 점입니다. 이 기능은 시스템 아키텍처에 큰 영향을 미칩니다(시스템 전체에 걸쳐 기본 요청의 환경 상태에 영향을 주지 않는 것 외에도 하위 요청도 성능을 고려해야 합니다.). 이 점이 가장 좋습니다. Drupal의 시스템 아키텍처는 ThinkPHP보다 훨씬 더 강력하고 완벽합니다. Drupal은 복잡한 비즈니스 로직을 더 잘 처리할 수 있습니다

2. Drupal은 전 세계적으로 단 하나의 항목 파일만 갖습니다. 단일 애플리케이션의 백엔드에는 입구가 하나만 있습니다. 사용자가 여러 개를 설정할 수는 있지만 여러 개를 설정하는 것은 권장되지 않습니다. 이는 복잡성을 줄이고 단순하게 유지하며 URL 별칭 시스템의 기반을 마련하며 ThinkPHP는 복잡한 다중 입력 메커니즘을 갖습니다. , 특히 다중 애플리케이션에서는 URL 별칭 지원이 어려워집니다

3. Drupal은 초기 상태에서 클래스 로더를 처리 코어에 전달하므로 당연히 클래스 로더 교체 또는 수정을 지원하지만 ThinkPHP는 이를 지원하지 않습니다. . 클래스 로더를 수정해야 할 경우 이를 얻을 수 없으므로 유연성이 크게 저하됩니다. 예를 들어, "thinkHttp" 클래스는 더 번거롭습니다.

다중 애플리케이션:

둘 다 다중 애플리케이션을 지원합니다. 즉, 여러 시스템이 동일한 코드 세트를 재사용하지만 Drupal은 특정 방법 측면에서 훨씬 간단합니다.

인터페이스 지향 프로그래밍:

다양한 구현 ThinkPHP에서는 클래스에서 인터페이스가 추출되지 않으며 일부 중요한 클래스에도 인터페이스가 없습니다. 예를 들어 thinkApp을 대체하기 위해 자체 앱 클래스를 구현하려는 경우 매번 문제가 되는 코어만 수정할 수 없습니다. 그러나 Drupal에서는 인터페이스가 엄격하게 준수되고 아키텍처가 완전히 인터페이스의 경우 가장 중요한 HTTP 코어 클래스를 포함하여 코어를 수정하지 않고 코어에서 제공하는 모든 클래스를 대체할 수 있습니다. : ThinkPHP의 앱 클래스와 유사한 DrupalKernel.

확장성에 영향을 미치는 것 외에도 인터페이스 프로그래밍을 엄격하게 따르지 않으면 IDE에 비우호적, 문서 추출 자동화가 어려움, 상속 없는 코드 주석, 불편한 공동 토론 등 많은 단점도 있습니다.

라우팅 시스템:

ThinkPHP 공식 튜토리얼의 원문 인용:

"ThinkPHP는 라우팅을 강제로 사용하지 않습니다. 라우팅이 정의되지 않은 경우 "컨트롤러/작업" 메서드를 사용하여 직접 액세스할 수 있습니다." 볼 수 있습니다. 위에서 언급한 것처럼 프레임워크 작성자가 라우팅의 특성에 대한 이해가 부족하다는 것입니다. 1번은 아직 추상화되지 않았습니다. 소위 "컨트롤러/작업" 방법도 라우팅이 없는 것이 아니라 기본 라우팅 또는 내부 경로 라우팅에 속해야 합니다. 겉으로는 무해해 보이는 이 지점은 본질적인 인지와 관련되어 실제로 매우 중요하며 결과적으로 매우 다른 행동을 초래합니다.

라우팅은 시스템에 진입한 후의 갈림길입니다. 권한 제어, 매개변수 변환, 경로 별칭 처리, 언어 처리 등 많은 비즈니스 로직이 여기에서 처리되어야 합니다. ThinkPHP에서는 다음과 같이 간주됩니다. 또한 이러한 인지 결과는 코드 중복, 일관되지 않은 사용 등을 필연적으로 느슨하고 복잡하게 만들 것입니다.

입력 처리는 라우팅의 두 가지 주요 기능 중 하나일 뿐입니다. 다른 주요 기능은 시스템 전체 URL을 생성하는 내보내기 처리입니다. 이는 URL 별칭 처리, 언어 협상, SEO 등에 중요합니다. ThinkPHP에는 단순한 기능만 있습니다. 라우팅 시스템의 구현은 아직 라우팅 시스템의 책임을 완전히 인식하지 못했습니다. 예를 들어 다음과 같은 요구 사항이 제기됩니다.

사용자가 "target="_blank""를 어떻게 추가할 수 있습니까? 사용자 정의 기능에서 전체 시스템의 URL?

컨테이너 및 종속성 주입:

이 개념과 이름은 Symfony 프레임워크에서 유래되었습니다. 자세한 내용은 다음을 참조하세요. 주요 아이디어는 시스템에 상위 개체라고도 하는 중앙 대형 개체를 설정하는 것입니다. 이는 일반적으로 사용되는 개체를 수집, 저장 및 자동으로 인스턴스화하는 역할을 합니다. Symfony에서는 이 대형 개체를 컨테이너라고 합니다. 여기에 저장된 객체를 서비스라고 합니다. 서비스 정의는 YAML로 정적으로 제공되거나 서비스 공급자의 형태로 동적으로 제공될 수 있습니다. 서비스가 필요할 때 컨테이너 객체입니다. 정의에 따라 서비스 객체를 인스턴스화한 다음 저장하고 반환합니다. 정의 진행 중 여기에는 클래스, 매개변수, 팩토리 메소드, 인스턴스화 후 콜백, 구성자, 공개 및 비공개 속성, 기능 상속, 지연된 인스턴스화와 같은 개념이 포함됩니다. 서비스 그룹 및 매개변수 수정과 같은 고급 기능을 처리하기 위해 컨테이너가 형성되기 전에도 서비스 컴파일 프로세스가 있으며, 컨테이너의 각 서비스에는 서비스 ID라는 ID가 있으며 이를 통해 서비스 객체를 얻습니다. 컨테이너는 서비스를 저장하는 것 외에도 컨테이너 매개변수, 서비스 별칭 등도 저장합니다.

ThinkPHP의 컨테이너 개념에는 Symfony의 그림자가 있지만 아직은 매우 어리고 초보적입니다. 예를 들어 서비스 ID에 대한 명확한 개념이 없고 Symfony 컨테이너에 서비스 개체가 없습니다. 해당 서비스 ID가 있어야 하며 ThinkPHP는 유사한 개념 추상(식별자 또는 클래스 이름일 수 있음)을 호출하지만 일부 컨테이너 메소드는 이를 클래스 이름으로 사용합니다. 예:

thinkApp::register

thinkApp:: getService

저자는 최대한 유연해지기를 원하는 것 같지만, 불일치로 인해 혼란을 야기합니다. ThinkPHP에서는 "서비스"라는 개념이 별도의 정의(운영체제 서비스와 약간 비슷함)를 가지고 있지만 본질적으로 그렇습니다. 이는 여전히 Symfony 서비스입니다. Symfony에서는 서비스를 컨테이너에 넣는 것을 서비스 "수집" 또는 ThinkPHP에서는 컨테이너에 "바인딩"이라고 합니다. 이름에서 알 수 있듯이 컨테이너는 물건을 담는 데 사용되는데 왜 바인딩이라고 합니까? 이런 종류의 이름은 발음하기가 매우 어렵고, 의미를 전달하지 못하는 이름이 많습니다. 예를 들어 컨테이너에 있는 개체의 인스턴스화 후 작업을 실행할 때 ThinkPHP에서는 이를 "실행 후" 작업이라고 부릅니다. "인스턴스화 후" 작업이 아닙니다. 컴퓨터 업계에서는 "무엇이 어렵습니까? 캐싱 및 이름 지정"이라는 유명한 말이 있습니다. 이 분야에서는 ThinkPHP의 일부 이름이 초보자에게 친숙하지 않습니다. .

또한 서비스(ThinkPHP에서는 컨테이너에 바인딩된 클래스, 객체 또는 콜백이라고 함)도 서비스를 컨테이너에 바인딩할 수 있습니다. 이 기능은 유연해 보이지만 코드 추적 및 디버깅, 새로운 사람 추가에는 매우 비우호적입니다. 시스템을 장악하는 것은 어렵고 Drupal은 중앙 집중식 선언을 허용하는 모듈식 설계의 이점을 얻습니다(왜냐하면 모듈은 서비스가 어떤 서비스에 의존하는지 알아야 하고 컨테이너 컴파일 메커니즘은 특정 서비스가 존재하는지 여부도 결정할 수 있기 때문입니다). 코드 추적 및 디버깅에 있어 가능한 한 간단하며, 실제로 각 서비스를 인스턴스화하지 않고 런타임 컨테이너에서 서비스 정의를 내보내는 것도 매우 편리합니다.

Façade:

이것은 단지 ThinkPHP의 개념으로, 패키지된 클래스의 동적 메서드를 정적으로 호출하는 데 사용됩니다. 즉, 정적 메서드를 사용하여 클래스를 메서드 수준으로 프록시하는 것입니다. 형식적인 조정 및 내부 인스턴스가 여전히 필요합니다. 사실 이 개념은 IDE에 매우 비우호적일 뿐만 아니라 PHP 정적 메서드의 원래 설계 의도에 위배됩니다. ThinkPHP에는 그러한 개념이 없습니다. Drupal의 기능적 목적은 Drupal::service($id) 정적 메서드를 사용하여 서비스 인스턴스를 얻은 다음 개발자가 직접 동적 메서드를 호출하는 것입니다. 다른 인스턴스가 필요하면 직접 복제할 수도 있습니다. 이렇게 하면 프록시 클래스를 도입하기 위해 use를 사용하는 문제도 피할 수 있습니다.
도움말 기능

ThinkPHP에는 도우미 기능이라는 개념이 있습니다. 문서에는 IDE에서 제공하는 자동 알림의 편리함을 누리는 것이 목적이라고 언급되어 있습니다. Drupal의 "Drupal" 전역 클래스. 그러나 Drupal은 IDE 때문이 아니라 PHP 함수 또는 정적 클래스 메소드를 슈퍼 전역적으로 사용할 수 있기 때문에 서비스를 얻는 것이 더 편리하기 때문입니다.
컨트롤러 및 모델:

ThinkPHP에서는 컨트롤러가 비즈니스 전 처리 로직을 수행하는 데 사용된다고 생각됩니다. 이는 반드시 PHP 클래스 또는 클로저여야 합니다. 비즈니스 로직은 실제로 "패턴"의 문제입니다. 우선 컨트롤러는 함수, 컨테이너 인스턴스 메소드(컨테이너 ID로 정의) 등을 포함하여 어떤 형태로든 표현되는 PHP 콜백이 될 수 있습니다. 둘째, 실제로 비즈니스 로직의 경계가 그다지 명확하지 않으며, "패턴"을 추상화하고 이름을 지정하는 것은 어렵습니다. 컨트롤러는 이미 비즈니스 처리의 시작이어야 하며 ThinkPHP 개념에서 컨트롤러가 수행하는 작업은 라우팅에서 처리되어야 합니다. 문서.

다국어 처리:

구현 측면에서 ThinkPHP와 Drupal은 모두 개발 메타 언어로 영어를 기반으로 합니다. ThinkPHP의 번역 구현은 매우 간단하며 특히 국제 개발 시 현실 요구를 충족하지 못하는 경우가 많습니다. Drupal은 완전한 다국어 시스템을 갖추고 있으며 다음 개념을 완벽하게 처리했습니다.

언어 단수 및 복수 문제(일부 언어에는 단수 및 복수 이상의 문제가 있습니다.) 복수) 상황별 문제("may"는 "can" 또는 ""May"로 번역됨) JS 텍스트의 번역 인터페이스, 구성 및 콘텐츠 언어 번역 팀 번역 협업 메커니즘, 왼쪽 텍스트 언어 처리,

ThinkPHP에는 이러한 기능이 없으며 템플릿의 텍스트 번역, 명령문의 변수 대체만 구현합니다. 또한 Drupal은 자연스럽게 사용자 설정, URL 접두어, 세션 정보와 같은 다중 언어 협상 메커니즘을 갖습니다. , 도메인 이름, HTTP 헤더, 사용자 에이전트 식별자 등을 지원하며 플러그인을 통해 언어 협상 메커니즘을 사용자 정의할 수 있습니다. ThinkPHP에서는 기본적으로 URL, HTTP 헤더 변수, 쿠키 및 브라우저만 지원됩니다. 쿠키를 사용하여 언어 정보를 전송하는 경우 국제 시스템을 개발할 때 법적 문제가 발생할 수 있습니다. 많은 국가에서는 사용자에게 쿠키를 포괄적으로 사용할 수 있는지 명시적으로 물어볼 것을 요구합니다. 인터넷에서 ThinkPHP를 사용할 때 개발자는 대부분의 언어 문제를 스스로 해결해야 합니다. 그러나 실제로 다국어 시스템은 전체 시스템에 걸쳐 실행되며 매우 크고 복잡합니다. Drupal은 국제적으로 공동 구축된 시스템이므로 다국어는 그 하이라이트 중 하나이며 당연히 다국어 시스템입니다. 이것만으로도 ThinkPHP 개발자는 어려움을 겪을 수 있습니다.

캐싱 시스템:

완전한 캐싱 시스템에는 만료 시간, 잘못된 태그, 컨텍스트라는 세 가지 요소가 있습니다. 반면 ThinkPHP는 시간과 태그만 구현하고 컨텍스트는 구현하지 않습니다. 문맥? 간단히 말하면, 동일한 캐시 키 KEY 하에 캐시된 객체가 누구에게 속해 있으며 어떤 환경 조건에 있는지를 나타냅니다. 예를 들어 사용자의 권한, 로그인 상태, 언어, IP, 프로토콜 버전, 주제 정보 등이 모두 캐시에 속합니다. 동일한 KEY는 서로 다른 컨텍스트 조건에서 서로 다른 캐시 개체를 읽어야 하는데 이는 대규모 시스템 설계에 매우 중요하며 ThinkPHP에서는 개발자가 캐시 컨텍스트 문제를 스스로 해결해야 합니다. 캐시 병합 메커니즘을 제공하지 않습니다. 이는 효율적인 캐싱을 달성하는 데 필수적인 계층적 캐시 처리를 활성화하지 않습니다.

세션:

ThinkPHP를 사용하는 개발자는 세션 관련 문제를 스스로 해결해야 하는 이유는 무엇입니까? 오늘날 IT가 발달함에 따라 소규모 및 마이크로 시스템만 하나의 서버만 사용하고 대부분의 시스템은 여러 서버에 로드 밸런싱을 수행하므로 애플리케이션에는 상태 비저장이 필요하므로 세션 데이터를 로컬에 저장할 수 없습니다. ThinkPHP는 세션의 데이터베이스 저장을 위한 기존 솔루션을 제공할 수 없는 프레임워크이기 때문에 개발자가 직접 처리해야 합니다. Drupal 자체에서는 로드 밸런싱 및 애플리케이션 무상태성 등을 고려했으며 세션은 다음과 같이 데이터베이스에 저장되었습니다. ThinkPHP는 확장 기능을 제공하지만 개발자는 여전히 개발을 구현하기 위해 많은 인건비를 지불해야 합니다. ThinkPHP의 세션 구현에는 스크립트가 끝난 후 세션이 저장되지 않는다는 문제가 있습니다. 하지만 스크립트 내에서 실행하면 사용자가 종료 기능을 등록하게 됩니다. 자세한 내용은 PHP 함수:

register_shutdown_function

데이터베이스:
ThinkPHP 및 Drupal을 참조하세요. 이 기능은 ThinkPHP에서 사용할 수 있습니다. Drupal은 이를 설명하기 위해 "분산 데이터베이스"라는 개념을 만들었습니다. Drupal은 특별한 렌더링 개념이 없으며 비즈니스 식별자만 사용하여 서로 다른 데이터베이스를 구별하고 읽기-쓰기도 지원합니다. 예를 들어, 데이터베이스 구성의 데이터 구조에서 Drupal은 첫 번째 수준의 키 이름이 비즈니스 식별자이고 두 번째 수준의 키 이름입니다. 는 마스터-슬레이브 식별자이고 그 값은 연결 구성 정보입니다. 이 구조는 매우 간단합니다. 데이터베이스 로드 스케줄링 하위 시스템을 구현하려는 경우 이 구조의 인터페이스는 매우 간단하며 ThinkPHP의 구성 데이터 구조에서도 마찬가지입니다. , 모든 호스트 주소는 배열 키 아래에 저장되고, 모든 비밀번호는 다른 배열 키 아래에 저장됩니다. 배열 키 아래에는 사용자 이름 등도 있습니다. 이러한 구조는 연결 정보를 생성할 때 구성 정보를 다시 구문 분석해야 할 뿐만 아니라. 읽고 수정하는 것이 직관적이지 않고 시스템 성능도 소모하며 데이터베이스 로드 스케줄링 하위 시스템의 인터페이스도 더 복잡하고 매우 우아하지 않습니다.

둘 모두 여러 유형의 데이터베이스를 지원합니다. 또한 Drupal은 mysql, pgsql 및 sqlite의 세 가지 데이터베이스를 지원합니다. 또한 Drupal은 일반적으로 사용되는 모든 데이터베이스에 대한 지원을 거의 완벽하게 구현합니다. "방언"이라고 불리는 다양한 방언의 처리는 드라이버 계층에서 완료되어 상위 계층에 통일된 인터페이스를 제공합니다. 즉, 상위 계층 데이터베이스 작업 클래스는 어떤 데이터베이스가 사용되는지 감지할 수 없습니다. 표준 SQL 사양을 채택하여 차이점을 완벽하게 보호합니다. 데이터베이스 분리를 실현한 후 모듈 개발자는 전환 시 사용자가 어떤 데이터베이스를 사용하는지 고려할 필요가 없습니다. 애플리케이션 계층에서 다양한 유형의 데이터베이스 간 작업을 한 번의 클릭으로 수행할 수 있습니다.

데이터베이스 운영과 관련하여 Drupal은 기본적으로 일련의 매우 진보된 데이터 저장 구조를 구현했습니다. 이 구조는 모든 사람이 통합된 데이터 구조를 기반으로 할 때 놀라운 일이 일어납니다. 결과적으로 전 세계에 분산된 사람들이 협력하여 풍부한 상위 수준 애플리케이션을 구현할 수 있습니다. 이 구조는 유명한 엔터티 개념을 만들었습니다. 또한 Drupal은 엔터티 쿼리와 같은 데이터에 대한 더 많은 작업을 제공하며 사용자는 이를 즉시 사용할 수 있습니다. . Drupal은 포괄적이며 사용자는 자신의 데이터 구조를 정의할 수도 있습니다.

ThinkPHP는 데이터 계층을 지원할 수 없습니다. ThinkPHP는 모델을 사용하여 데이터 캡슐화 및 작업을 처리합니다. 엔터티에 비해 모델은 수행할 수 있는 모든 엔터티를 수행할 수 있으며 그 반대도 마찬가지입니다. 모델은 입력용 필드 컨트롤, 출력용 포맷터, 양식 및 보기용 디스플레이 컨트롤 등을 지원하지 않습니다. 그 이유는 더 높은 수준의 구현이 필요하기 때문입니다.

중국과 외국 오픈 소스 생태계 및 연결:

완전히 비교하고 나면 ThinkPHP가 Drupal이 할 수 있는 모든 것을 할 수 있고 더 잘할 수 있지만 그 반대는 아니라는 것을 이해하게 될 것입니다. 백엔드 시스템으로 알려진 이 시스템은 더 많은 작업을 수행하는 데 도움이 되었습니다. 기본적으로 ThinkPHP 개발자가 이러한 기능을 원한다면 Putting을 기반으로 먼 길을 가야 합니다. 품질 문제를 제외하면 시간 소모만으로도 놀라운 수치입니다(예를 들어 Drupal 8의 공식 버전이 출시되기 전에 다양한 개발 버전이 5년 동안 수천 명 이상의 국제 최고 개발자에 의해 작업되었습니다). Drupal 개발자들은 실제로 ThinkPHP나 다른 프레임워크를 배우려고 애쓰지 않습니다. 하지만 중국에서는 매우 이상한 현상을 발견할 수 있습니다. 왜 중국에는 ThinkPHP를 사용하는 소규모 회사가 아직도 많이 있습니까? (다양한 채용 플랫폼에서 PHP 채용 정보를 검색하면 이에 대해 조금 알 수 있습니다.) 이를 설명하는 두 가지 이유가 있습니다:

문화 교류가 차단됩니다:

중국과 외국 문화, 생활의 교류 등의 문제가 여전히 존재합니다. 대부분의 사람들은 다른 나라의 친구가 없습니다. 가장 큰 이유는 잘 알려진 네트워크 장벽과 언어 문제입니다. 현재 국내의 주요 개발자들은 70~90년대 출생자들이다. 이들 대부분은 영어 의사소통 능력이 부족하거나, 영어가 벙어리이거나, 본능적으로 읽기에 어려움을 겪는 경우가 많다. 2000년이나 10년생의 영어 수준은 훨씬 높으며(초기 교수님들, 인터넷 등 덕분에) 앞으로는 기술이 발전하여 국제 환경에 더욱 통합될 것입니다. 번역 소프트웨어의 수준이 점점 높아지고 있으며 기술 도입에 전념하는 사람들이 점점 더 많아지고 있습니다. 예를 들어 Drupal은 중국에서 "Drupal", "Aima Document Collection", "Shui Drop Room", "을 보유하고 있습니다. Drupal University", "Think in Drupal", "Ninghao.com" 및 수많은 기술 플랫폼. 이러한 플랫폼이나 블로그는 거의 완전한 중국어 문서를 대량으로 제공하여 언어 장벽을 제거합니다. 베이징, 상하이, 광저우, 청두, 난닝, 닝보 등의 도시에는 Drupal을 핵심 기술로 하는 개발 회사가 있습니다.

스트레스로 인한 패스트푸드 현상:

중국인들은 확실히 세계에서 가장 열심히 일하는 사람들 중 하나입니다. 이러한 노력은 주로 스트레스와 관련이 있습니다. 주거, 결혼, 의료, 교육, 노인 간호는 각각 "돈 버는 것"입니다. 큰 일, 대부분의 보통 사람들에게는 독창성을 유지하고 장기적으로 축적하는 것이 너무 위험하며, 지금 벌 수 있는 돈을 먼저 벌어야 합니다. 미래에 사회가 이렇게 빨리 발전한다면 이런 현상은 우리나라의 기반에 큰 영향을 미칠 것입니다. 과학 분야의 피해도 크며, 빠르게 발전하는 IT 산업에서도 마찬가지입니다. .996은 대기업에서도 오랫동안 CURD와 같은 간단한 코드 파머 작업을 해왔지만 단순히 가족과 아이들과 함께 공부할 시간이 많지 않습니다. 여자친구. 쉴 시간이 거의 없어서 깊이 공부하기가 더 힘들어요. 시간이 생기면 보통 그 시간을 사적인 일을 하고 돈을 벌기 위해 사용해요. 이런 환경에서는 다들 익숙해요. 패스트푸드 먹기". 괭이가 있으면 먼저 쓴다. 굴삭기를 배울 시간도 없다. 굴착기 개발 비용은 더욱 비싸다. 결국 우리나라 오픈소스 산업 발전을 어렵게 만든다. 상업적인 성향이 강한 오픈소스 프로젝트는 소수에 불과합니다. 소규모 회사는 광고 보조금과 오픈소스 프로젝트에 의존하여 돈을 벌기 위해 상업 프로젝트를 유치합니다(ThinkPHP 홈페이지를 보면 느낄 수 있습니다). 반면 대기업은 선택합니다. 예비 인재 양성, 무료 버그 제거 등의 목적으로 사용됩니다. 오픈 소스는 일반적으로 '영향권' 색상이 강합니다. 일반적으로 순수한 사랑과 관심은 작은 비율을 차지하지만 이를 중국 개발자에게 비난해서는 안 됩니다. 이는 극심한 압박 환경으로 인해 발생하며, 현재는 1급 도시의 현상을 벗어나기 위해 덜 바쁘고 여유로운 시간을 가질 수 있는 2급 도시로 이동하는 경향이 있습니다. 오픈 소스 Get APP(Luoji Thinking)도 중국의 혁신 센터가 레저 2급 도시로 이동할 수 있다고 예측합니다.

반대로 국제 오픈소스의 토양은 훨씬 좋고, 많은 선진국이 지배하고 있으며, 이들 국가는 대개 복지 국가라는 압력에 비해 사람들이 기반으로 일할 여지가 많습니다. 오픈소스에 관련된 많은 사람들이 가장 먼저 고려하는 것은 삶의 의미에 관한 "Maslow Needs Model"입니다. 독자는 이에 대해 배울 수 있으며 "좋아요"는 "품질"을 보장하며 개발자는 혜택을 누릴 수 있습니다. 나이와 일을 무시하고 연례 DrupalCon 컨퍼런스에서 많은 개발자들이 50~60대에 달하는 밝은 눈으로 기술에 대해 이야기하고 자신의 삶의 축적을 Drupal에 쏟아 붓는 것을 볼 수 있었습니다.

물론, 국제 오픈소스가 선진국이 주로 참여하는 것은 아닙니다. 영어권 저개발국도 주요 참여자입니다. 오픈소스에서 파생된 상업 프로젝트를 통해 외화를 얻는 경우가 많습니다. 대표적인 국가가 인도입니다. 한때 영국이 이 나라를 식민지화했고, 고급 사람들 사이에서 영어의 인기가 매우 높았기 때문에 인도는 국제 오픈 소스에 고도로 통합되었으며 그에 따라 인도의 소프트웨어 개발 강도가 상대적으로 높아졌습니다.

개발자 경력 계획:

이 섹션에서는 국내 개발자의 경력 계획 문제에 대해 논의합니다. 일반적으로 35세 임계값에 해당하는 "프로그래머는 젊음의 음식을 먹습니다"라는 목소리가 있었습니다. 일부 대기업에서는 35세 개발자를 해고하는 경우가 종종 있는데, 일부 기업에서는 35세 이상을 채용할 수 없습니다. 35세가 더 깊은 능력을 축적하고 많은 일을 적절하게 처리할 수 있다는 것이 이상합니다. 현상이 일어나나요? 살펴보자:

우선, 이러한 뉴스는 '여성 운전자'처럼 주목을 받을 것이라는 의혹이 높습니다. 실제로 여성 운전자의 사고율이 남성 운전자보다 적기 때문입니다. 뉴스이고 사람들이 검색하게 만들 수 있지만, 이런 뉴스가 너무 많으면 착각을 하게 되기 때문에 35세 기준이 어느 정도 과장되어 나쁜 영향을 미치게 됩니다. 어떤 사람들은 이유 없이 추세를 따르기도 합니다.

하지만 35세라는 기준에는 진실이 있습니다. 이는 선별적으로 구분할 필요가 있습니다. 개발자가 CURD(실제 코더)처럼 단순하고 반복적인 육체 작업을 해왔다면, 35세가 되면, 이제 막 학교를 떠난 사람과는 다를 것이다. 1~2년 된 젊은이들과 비교하면 35세의 나이에는 자녀의 학업, 부모의 건강, 주거에 대한 압박이 클 것이다. 등으로 인해 개발자는 더 높은 급여 요구 사항을 제시해야 합니다. 가족 문제, 사회적 상호 작용 등도 많이 있습니다. 일반적으로 젊은 사람들이 장기간 근무할 수 있으면 누적 급여가 상대적으로 높습니다. 당신이 무엇을 하세요, 사장은 누구를 선택할 것인가? 동시에, 나이가 들수록 얼굴에 문제가 생기기도 합니다. 만약 당신의 상사가 당신보다 훨씬 어린 청년이라면 그에게 순종해야 할까요? 젊은 사람들이 자신보다 훨씬 나이가 많은 사람을 관리하는 것이 때로는 어색할 수 있습니다. 이를 토대로 볼 때 35세 문턱의 존재에는 일정한 이유가 있음을 알 수 있다.

시간은 누구도 기다려주지 않습니다. 그렇다면 개발자는 어떻게 35세의 문턱을 피하고 삶을 어떻게 계획해야 할까요?

기술이 별로 마음에 들지 않는다면, 그 나이에 아직 경쟁력이 있을 때 가능한 한 빨리 변화하고, 마음을 따르고, 좋아하는 것을 찾아 경쟁력을 축적해야 합니다.

기술을 정말로 좋아하고 그것을 하면서 평생을 보낼 의지와 준비가 되어 있다면 효율적으로 축적하고, 계속 학습해야 하며, 부담이 적고 체력이 강한 젊은이들과의 기술 격차를 넓히는 데 항상 주의를 기울여야 합니다. 장점, 기술적인 장점으로 보완해야 한다. 명인이 되는 길은 선택할 수 있는 것이 아니라 필수다. 35세가 되면 명인이 되어 시스템의 자리를 맡아야 한다. 젊은이들은 성취하기 어렵다는 것입니다.

사회가 발전함에 따라 기술의 한계가 실제로 점차 높아지고 있다는 점을 상기시켜 드리고 싶습니다. 예를 들어 "풀 스택 엔지니어"라는 말을 들어보셨겠지만 이는 인터넷 시대 초기에만 해당됩니다. 이제 사회적 분업은 너무 얇고 너무 깊습니다. 풀 스택이 존재한다면 사람들의 에너지 격차가 너무 크지 않기 때문에 "모든 것을 알고 있지만 전부는 아니다"라고 할 수 있습니다. 당신은 모든 것을 공부하기로 선택하고, 다른 사람들은 한 분야를 공부하기로 선택하고, 고용주는 어떤 직위를 위해 사람을 채용할 때 누가 유리한지 고려해야 합니다. 이유는 한 과목을 더 깊이 파고들어 주변을 이해하도록 만들 것입니다. 그러나 이런 식으로 당신은 큰 기계의 구성요소가 될 것이고, 당신의 선택의 자유는 제한될 것이고, 세분화에 대한 문턱도 제한될 것이고, 당신은 단지 스크래치만 할 수 있을 것입니다. 표면을 추구하지 않으면 제거에 직면하게 됩니다.

그런 기계 부품을 만드는 것은 창업을 꿈꾸는 사람들에게는 적합하지 않은데, 그들이 창업할 때 어떤 상황에 직면하게 될까요? 중국 사회의 발전을 살펴보면 일반적인 IT 요구 사항을 모두 충족할 기회가 없을 수 있습니다. 예를 들어 웹 사이트는 공식 계정으로 대체되고 소수의 웹 사이트 시장도 이러한 플랫폼과 경쟁하기 위해 점유됩니다. 초기화하려면 마우스를 클릭하기만 하면 되며, 시간 기준 요금이 매우 낮을 수 있습니다. 고객의 관점에서 가장 먼저 고려해야 할 사항은 비용입니다. 일반적인 요구 사항에는 전자 상거래 시스템, 라이브 방송 시스템, 콘텐츠 결제 시스템 등이 포함되며, 이들은 모두 규모 측면에서 매우 성숙한 기존 솔루션을 보유하고 있으며 Weimeng, Youzan, Weiqing, Weijianmu 등은 모두 매우 우수합니다. 일반적이지 않은 IT 요구 사항은 어떻습니까? 많은 수직 분야의 솔루션이 형성되고 Meituan, Didi, Tubatu, Dingguagua 등과 같은 산 꼭대기가 점령되고 분할됩니다. 해당 분야에서 기회를 갖기가 어렵고 숫자만 남습니다. 실제로 맞춤화가 필요한 수요는 많지 않습니다. 이러한 종류의 수요는 맞춤화이기 때문에 단가가 높을 수밖에 없다는 특징이 있습니다. 기업가의 회사는 직원이 몇 명입니까? 사무실은 얼마나 큽니까? 역사적 축적은 얼마나 됩니까? 경우의 수는 몇 개인가요? 등록자본금은 얼마나 됩니까?

또한 오늘날 IT가 발전함에 따라 동일한 응용 프로그램 시스템은 일반적으로 하나 이상의 앱, 작은 프로그램, 웹 페이지 등이 필요하며 크로스 플랫폼도 포함됩니다. (APP에는 Android, IOS 및 곧 출시될 Hongmeng, WeChat, Alipay, Baidu, Douyin 등이 포함된 미니 프로그램이 포함됩니다.) UNIAPP과 같은 도구가 있지만 고객이 기본 애플리케이션을 요구할 경우 여전히 많은 기술이 필요하므로 팀을 구성하고 팀원을 구성하는 데에는 영업사원, 재무 등 비기술 인력도 포함되어 특정 진입 장벽을 형성합니다. 결국 사업을 시작하려면 기술뿐만 아니라 자본도 필요하다는 것을 알게 될 것입니다.

이렇게 말하니 길이 어렵다고 느껴지시나요? 하지만 이는 IT 분야뿐만 아니라 경쟁이 치열한 곳에서도 마찬가지라는 사실을 믿으시기 바랍니다. 성공은 쉽지 않습니다. 관심만이 어디까지 갈 수 있는지를 보장할 수 있으니 마음을 따르시기 바랍니다.

마음을 따르고 신중한 고려 끝에 여전히 기술을 선택하고 위대한 마스터가 되기로 선택했다면 어떻게 해야 합니까? 우선, 축적에 집중해야 하며, 특히 거인의 어깨에 서서 미개발 지역을 향해 돌진해야 합니다. 틈새 시장에서 가장 유망한 생태계를 찾아서 참여하고 PHP 개발 프레임워크인 Xiaobai로 돌아가야 합니다. 프레임워크는 필요한 기능을 추가로 캡슐화하고 제공하지만 전문가는 프레임워크가 통합된 협업 플랫폼을 제공하므로 모든 사람이 동일한 플랫폼에서 생성하므로 경제적 비용 측면에서 충분합니다. 비용 효율적이며 모든 사람의 힘의 도움으로 자유롭게 자신의 사업을 개발할 수 있습니다.

기본 플랫폼의 통일성은 매우 중요합니다. 그래야만 인간이 축적하고 앞으로 나아갈 수 있으며 비용을 절감할 수 있습니다. 그러나 통일된 플랫폼을 형성하는 데에는 흥미로운 규칙이 있습니다. 경쟁적 예비군을 형성하기 위해서는 기본적으로 3위와 4위는 무시할 수 있으며, 1위와 2위의 규모는 매우 다를 것입니다. 운영체제는 2개가 있는데 결국 윈도우와 리눅스 둘 사이에는 사용자 수에 큰 차이가 있습니다. 이는 안드로이드와 애플, 타오바오에서도 마찬가지입니다. JD.com, Douyin과 Kuaishou, Meituan과 Ele.me 등이 있습니다. 일단 패턴이 형성되면 흔들리기 어렵습니다. 예를 들어 Microsoft는 기술 때문이 아니라 눈덩이 효과가 있기 때문에 Android를 흔들 수 없습니다. 왕은 점점 더 강해지고, 패자는 점점 외로워지고 사라질 것입니다. 왕이 약간의 실수를 하더라도 발전하지 않을 것입니다. 예를 들어 우리가 지금 사용하는 키보드, 문자 배열은 그렇지 않습니다. 역사상 가장 합리적인 키보드가 있었지만 모두가 현재의 키보드에 익숙해져 있기 때문에 계속해서 사용하게 됩니다. 두 가지 중요한 점은 기술의 발전이 충분해야 한다는 것입니다. , 그리고 공동체 생태계는 눈덩이 효과를 확립해야 합니다. 이 두 점은 서로를 보완합니다.

그럼 누가 PHP 프레임워크 분야의 통합 기본 플랫폼이 될까요? 오픈소스 프로젝트의 주된 개발력은 소수의 사람이 자신의 생각이나 경험에 의존하기보다는 다수의 사용자가 사용 중에 계속해서 다듬고 요약하고, 계속해서 함께 논의하고 개선해 나가는 것이 되어야 하므로, ThinkPHP와 Symfony에서 선택한다면 대답은 매우 분명합니다. 사실 Symfony는 통합 플랫폼의 중요성을 일찍부터 깨달았기 때문에 분리되고 완전한 기본 구성 요소를 구축하는 데 전념했으며 반복적으로 반복되었습니다. Laravel 및 ThinkPHP와 같은 일부 기존 프레임워크도 Symfony 구성 요소를 사용하므로 Symfony는 "표준"을 반복적으로 강조해 왔으며 이제는 통합 플랫폼의 필수 조건이기 때문에 PHP 개발 분야에서 사실상의 표준이 되었습니다.

Drupal은 Symfony를 기반으로 구축된 상위 수준의 통합 표준 플랫폼으로, 여기에서 일반적으로 사용되는 거의 모든 애플리케이션 레이어 기능이 제공됩니다. 모듈형 설계를 기반으로 보다 미래지향적인 기능을 창출하고 "탁월한 디지털 경험 제공"이라는 Drupal의 이상을 실현합니다.

의사결정자 기술 선택:

프로젝트에 대한 기술을 선택하는 기업가 상사 또는 프로젝트 디렉터인 경우 다음 사항에 유의해야 합니다.

비용 관리:

물론 이는 당연한 일인 것 같지만 실제로 통제할 수 있습니까? 소프트웨어는 무형입니다. 전문가가 아니면 비용 관리가 어렵습니다. 다음은 몇 가지 함정입니다.

현재 환경에서는 장기 계획 프로젝트를 직접 개발하고 싶다면 아웃소싱하지 마세요. 일부는 동일해 보이지만 실제로는 그 차이가 매우 큽니다. 비전문가는 견고성, 확장성, 보안, 지속 가능성 등의 측면에서 두 시스템의 차이점을 알기 어렵습니다. 동일한 기능의 개발 부하가 5,000이고 비용이 완전히 다릅니다. 예를 들어 소프트웨어 문서 작업량이 때로는 소프트웨어 개발 자체보다 훨씬 높을 수 있습니다. 하지만 아웃소싱의 경우 완전한 문서화를 달성하기 어렵습니다. 아웃소싱의 품질로 인해 나중에 비용을 지불하게 되는 경우가 많습니다. 결국 그 이유는 아웃소싱 회사가 강하지 않기 때문이 아니라 비용 문제 때문입니다. .

Ow 기술 부채 감소:

처음에 돈을 절약하기 위해 충분한 경험이 없는 개발자를 찾지 마십시오. 다음은 이야기입니다. 상사와 기술 이사는 인재 채용에 차이가 있었고, 기술이사가 요구한 직위의 급여는 15,000인데 지원자가 오면 8,000밖에 안 든다. 기술이사는 그것을 원하지 않지만 상사는 너무 기뻐하며 자신이 얻은 것이라고 생각하는데 왜 어리석게도 더 많이 지불해야 하는가? ? 때때로 초보자는 시스템에 엄청난 숨겨진 위험을 남길 수 있습니다. 이 기술 책임자는 기술 부채 문제를 목격했습니다. 동시에, 기본 시스템을 선택할 때 개발 팀은 깊은 기술 백본을 보유해야 합니다. 성숙도가 낮은 것, 이것은 가능한 한 기술적인 빚을 지지 않도록 보장합니다. 그렇지 않으면 도로에 익숙해지기 시작하고 나중에 중요한 비즈니스 창구 기간에 직면하게 되면 신들조차도 곤경에 빠지게 될 것입니다. can't save you

가속을 위한 활용:

오늘날의 사회 발전 실제로 많은 IT 시스템 기능이 이미 존재하며 매우 완벽합니다. 예를 들어, 내가 선택해야 하는 경우입니다. ThinkPHP와 Drupal 중에서는 주저 없이 Drupal을 선택하겠습니다. 왜냐하면 ThinkPHP는 반제품일 뿐이고 주로 다양한 응용 프로그램에 사용되기 때문입니다. 가비지 수집 시스템, 상태 시스템, 키-값 등 일부 기능은 비즈니스 시스템에 필요합니다. 스토리지, 일괄 처리 시스템, 예약 작업 시스템, 데이터 입력 시스템, Ajax 시스템, 데이터 보기 엔진, 버전 지원 시스템, 권한 시스템 등은 ThinkPHP에서는 사용할 수 없으며 Drupal은 매우 완벽하여 완료하는 데 수개월이 걸립니다. ThinkPHP에서 개발하는데 수년이 걸렸습니다. 기본 통합 플랫폼의 장점을 말할 수 없을 뿐만 아니라, 스스로 개발한 코드의 품질을 보장하기 어려울 뿐만 아니라 자원 낭비입니다. , 신규 회원은 이후 단계에서 높은 교육 비용을 지불해야 합니다. 완벽한 기반을 갖춘 기성품 및 성숙한 시스템을 사용하는 것은 어떨까요?

환경에 통합:

개발 시스템은 가속을 활용하는 것 외에도 개발자를 프로젝트에서 분리하기 위해 예비 인재 확보에 달려 있습니다. 기존 개발자가 떠나거나 빨리 합류할 수 없습니다. 프로젝트가 더 큰 환경에 통합되고 개발자를 분리하면 프로젝트의 개발 보안이 크게 보장됩니다.

국가 오픈소스 권장사항:

이 섹션에서는 국가 차원에서 오픈소스를 어떻게 대해야 하는지 살펴보겠습니다. 우리나라는 날이 갈수록 강해지고 있습니다. 그러니 중국이 미국을 뛰어넘고 싶다면 봉쇄하고 초월을 이루려면 스스로 독립된 시스템을 구축하기보다는(자체 구축한) 국제 오픈소스에 참여해 주요 기여자가 되어야 한다. 오픈 소스는 특정 국가를 위한 것이 아닌 모든 인류를 위한 오픈 소스이기 때문에 중국은 세계와 멀어지게 됩니다. 중국의 인구는 14억 명에 불과한데 비해 세계 인구는 70억이 넘습니다. 생태학적 세력은 세계와 경쟁할 수 없기 때문에 오픈 소스에 참여하여 기여하려고 노력하는 것이 하나입니다. 인류 발전의 기존 성과를 계승하고 거인을 기반으로 더 빨리 발전하는 것, 다른 하나는 다수의 사람들과 함께 국가를 열고 영향력을 행사하는 것입니다.

【관련 튜토리얼 추천: thinkphp Framework】

위 내용은 드루팔, 국내 오픈소스 환경 살펴보기 위해 thinkphp와 비교의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!