php The Right Way를 읽어보셔야 합니다. 이 글은 많은 내용을 포함하고 있으며 확장 가능합니다. 대부분의 용어와 개념을 알아야 합니다. 1.PSR 대표님들의 공통점에 대해 이야기 나눠보세요. 이전 기사와 동료와의 대화에서 PSR(PHP)에 대해 여러 번 언급한 적이 있습니다. 많은 사람들은 PSR이 코딩 스타일 표준화와 같은 사소한 일만 한다고 생각하지만 실제로는 그 이상입니다. 공식 홈페이지에 따르면 이 조직의 목적은 무엇을 해야 하는지 알려주는 것이 아니라 일부 주류 프레임워크 사이에서 서로 협상하고 합의하는 것입니다. 하지만 저는 이러한 프레임워크와 확장 중에서 항상 사용하는 것이 있을 것이라고 믿습니다. 현재 PSR에서 승인한 문서는 6개입니다: 0: 자동 로딩(주로 네임스페이스가 없는 PHP 5.3 이전 버전의 경우) 1: 코딩 사양 2: 코딩 스타일 권장 사항 3: 로그 결과 4: 자동 로딩이 더욱 상세해졌습니다(네임스페이스가 나타난 후 많이 변경되었습니다) 7: HTTP 메시지 인터페이스 현재 초안에는 PSR-5(PHPDoc 표준), PSR-6(캐시) 등이 있습니다. 5번과 6번은 아직 투표를 하지 않았기 때문에 위 목록에 없습니다. 표준이 계속 업데이트됨에 따라 모든 규칙을 반드시 준수할 수는 없더라도 이러한 규칙을 연구하는 것이 여러분에게 매우 유익하다는 것을 알게 될 것이라고 믿습니다. 그룹 내 어느 누구도 프로그래머로서 앱 설치 방법을 알려주고 싶어하지 않습니다.2. Composer Composer는 프로젝트가 의존하는 라이브러리를 선언하고 이를 관리(설치/업데이트)할 수 있는 PHP의 종속성 관리 도구입니다. Composer는 Pear 및 Pecl과 다릅니다. 확장 기능을 설치하는 데 사용될 뿐만 아니라 더 중요한 것은 최신 PHP 프레임워크의 구현 및 확장 관리 방법을 정의한다는 것입니다. node.js의 npm 및 Python 의 pip와 비슷하지만 위의 것보다 더 많은 작업을 수행합니다.Composer의 핵심은 확장 기능의 표준 설치와 클래스 자동 로딩을 구현하는 것입니다. packagist.org 플랫폼을 통해 수많은 확장 구성 요소를 쉽게 도입할 수 있으며, 현재 더 잘 알려진 PHP 확장은 작곡가를 통해 설치할 수 있습니다. 호출에서는 autoload.php 파일만 로드하면 됩니다. Composer는 확장 클래스와 파일을 로드하기 위해 spl_autoload_register 메소드를 통해 자동 로딩 방법을 등록합니다. 물론 이 과정에서 Composer도 최적화를 수행했습니다. 우리 모두는 PHP 가져오기 파일이 include 및 require를 통해 구현되어야 한다는 것을 알고 있는데, 이는 실제로 작성하기에 보기 좋지 않습니다. PHP 5.3은 파일 가져오기와 관련이 없는 네임스페이스를 제공합니다. 그러나 Composer는 PSR-4(이전 버전의 PHP에서는 PSR-0)를 구현합니다. 주문형 로딩과 지연 로딩의 역할을 하게 됩니다. 3.php-cs-fixer PHP Coding Standards Fixer 도구는 PHP 코드를 따르고 싶을 때 코드의 대부분의 문제를 해결합니다. PSR-1 및 PSR-2 문서에 정의된 코딩 표준 중 일부 선택적 코딩 스타일은 Symfony 사양입니다. 프로젝트 주소: https://github.com/FriendsOfPHP/PHP-CS-Fixer 구체적인 사용법과 구성 방법이 들어있습니다. 프로젝트 홈페이지에 소개가 있습니다. 이 조직의 이름도 흥미롭습니다: FriendsOfPHP. 주요 멤버는 아마도 Symfony 프로젝트 출신일 것입니다. 어떤 사람들은 코딩 스타일에 대해 걱정할 필요가 없다고 생각할 수도 있습니다. 프로그래밍이 단순한 직업 이상이라고 생각한다면 방을 청소하는 것과 같습니다. 더러운 방은 먹고 자는 데 영향을 미치지 않지만 깨끗한 방은 더 편안해 보입니다. 다른 사람과 협력하고 싶다면 이 문제가 더욱 중요합니다. 4.PsySH 런타임 개발자 콘솔, PHP용 대화형 디버그 ger 및 REPL PsySH는 Python의 IDLE과 유사한 PHP 대화형 실행 환경입니다. 저는 이것을 Laravel에서 발견했고, Laravel 5의 artisan Tinker 기능이 이를 통해 구현되었습니다. Laravel 4는 또 다른 프로젝트인 Boris를 사용합니다.이는 주로 PHP의 몇 가지 간단한 기능과 특징을 테스트할 때 유용합니다. 공백 사용과 같은 불확실한 사항이 발생하면 이를 사용하여 테스트를 수행할 수 있습니다. 5. 일부 프레임워크 및 구성 요소 프레임워크 현재 선호하는 것은 Laravel입니다. , 회사에서는 Yii2를 사용하고 있는데 Symfony와 Phalcon(C 언어 구현)에 주목하고 있습니다. 무엇을 사용할지, 무엇을 사용하지 않을지는 주로 선호도에 따라 결정되며, 때로는 스스로 선택하지 않을 수 없을 때도 있지만, 이에 대해 좀 더 알아보고 연구해 보는 것도 나쁘지는 않습니다. 라라벨 하면 바로 Ruby on Rails를 떠올리시는 분들이 많을 것입니다. 모방이나 표절이 주된 목적은개발자에게 더 나은 도구를 제공하는 것이 아니라고 생각합니다. 다행스럽게도 Laravel에는 다른 라우팅 제어(Action 접미사 또는 접두사 없음), 유용한 ORM(Eloquent), 유용한 템플릿 엔진(Blade) 또는 상대적으로 보기 좋은 문서(커뮤니티에서 볼 경우) 등이 있습니다. 강력하다는 것이 거대하다는 비판을 받기도 하지만 이는 프로젝트의 중장기 계획과 현재 프로젝트 규모, 향후 규모와 수용 능력을 이해해야 하기 때문입니다. Larval의 핵심 구현은 컨테이너(Container)와 PHP의 리플렉션 클래스(ReflectionClass)입니다(Yii 2도 마찬가지입니다). 이를 이해하려면 더 많은 기사와 문서를 읽으면서 소스 코드를 살펴볼 수도 있습니다. Symfony 2는 많은 구성요소를 제공합니다. http-kernel과 http-foundation도 Laravel에서 상속되어 직접 사용됩니다. 알고 배울 가치가 있습니다. CodeIgniter는 작지만 강력한 프레임워크입니다. CI는 Composer 구성 요소를 사용하여 개발되지 않았지만 3.0 이후 버전에는 Composer 지원도 추가되었습니다(이는 추가 공급업체 디렉터리와 autoload.php 파일 도입에 지나지 않습니다). ORM 아직은 ORM이나 Active Record가 필요한 것 같아요. 어떤 사람들은 PHP가 단지 템플릿 엔진이고 SQL은 직접 작성해야 한다고 생각할 수도 있습니다. 이런 말에 신경쓰지 마세요. CodeIgniter에서 Active Record를 구현하는 것은 매우 가볍지만 CI 자체의 크기에 비해 이미 매우 유용합니다. 저는 Laravel에서 구현한 Eloquent를 매우 좋아하고 다른 프로젝트에도 통합할 수 있습니다. Symfony 2는 Doctrine을 사용하고 있는데, 이번 프로젝트도 주목할 만하다. Yii 2에는 자체 구현 방법 세트도 있습니다. 템플릿 엔진 템플릿 엔진은 세 가지 작업을 수행해야 합니다. 1. 변수 value 출력(echo), 2. 조건부 판단 및 루프(if ... else, for, foreach, while) 3 , 다른 파일에서 가져오거나 상속 Laravel에서 구현한 블레이드는 비교적 가볍고 사용하기 쉬운 템플릿 엔진입니다. 그러나 현재 이를 다른 프레임워크에 도입하는 것은 그리 쉽지 않습니다. 자유로울 때 Yii 2에 도입하려고 했는데요. 지금은 그냥 간단한 구현일 뿐이고 나중에 블레이드의 파싱 부분을 따로 추출해서 경량화 구현을 했으면 좋겠습니다. Github에서 검색해보니 같은 일을 하는 사람이 있었습니다. Yii 2는 기본 PHP로 작성하는 것이 더 권장되는 것 같지만 Smarty 및 Twig를 지원하는 확장 기능도 제공합니다. Symfony 2는 Twig를 사용합니다. 위에서 언급한 php-cd-fixer뿐만 아니라 Twig와 Symfony도 모두 SensioLabs의 작품입니다. Smarty는 오래되고 끈질긴 템플릿 엔진입니다. 솔직히 말해서 구문이 너무 복잡하고 변수 할당과 같은 것에는 고유한 메서드 집합이 있는 것을 별로 좋아하지 않습니다. 현재 버전은 Lexer를 사용하여 파일을 구문 분석하는데, 이는 PHP에서 구현된 또 다른 언어처럼 느껴집니다. 프로젝트에는 너무 길고 구현이 너무 복잡한 정규 표현식도 있는데 이는 매우 위험하고 오류가 발생하기 쉬운 일이라고 생각합니다. 관련 PHP 정보 더보기 http://www.kokojia.com/list/219.html |