PHP가 성숙해졌습니다

PHP가 성숙해짐에 따라 빠르고 독창적인 스크립터가 UML에 능숙한 객체 지향 개발자와 "동일한 관점에서 생각"해야 할 때입니다.
PHP만큼 빠르게 인기를 얻은 프로그래밍 언어는 거의 없습니다. IT 산업을 변화시키는 DIY(Do-It-Yourself) 스크립트 언어에 대한 현재 널리 알려진 이야기는 성공이 항상 체계적인 계획과 시장 조사에서 나오는 것은 아니라는 것을 보여줍니다. 그러나 이제 진짜 질문은 이러한 성공이 방대한 IT 산업에서 어떻게 받아들여질 수 있느냐는 것입니다. 오라클을 비롯한 몇몇 다른 대형 업체들은 PHP를 주목하고 있으며 언어가 성숙해졌다는 사실을 보여줍니다.
지금까지는 성공이 '나타났을' 뿐입니다. 마치 천재 신동처럼 PHP를 좋아하는 사람들이 점점 더 많아지고 있습니다. 그런데 이제 아이가 수염을 기르고 어른들과 동등한 입장에서 대화를 나누기 시작하니, 초기 옹호자들은 변화에 적응할 것인가?
PHP는 대부분의 주요 오픈 소스 프로젝트와 마찬가지로 주류 기술이 되는 과정에서 나타나는 근본적인 현상입니다. PHP가 명성을 얻은 사람들을 실망시킬까요? 대규모 IT 산업의 기대에 부응할 것인가?
두 가지 프로그래밍 문화 이야기
PHP의 성공은 다양한 배경을 가진 사람들의 관심을 끌었습니다. 초기 Rasmus 지지자들(오픈 소스 서클에서 흔히 볼 수 없는 약간 구호적인 어조를 용서할 수 있다면)은 빠르고 독창적인 스크립팅 방법에 익숙했으며 이제는 UML을 이해하는 사람들과 싸워야 했습니다. PHP를 다른 최신 개발 도구와 동등한 수준으로 유지하기로 결정한 OO(지향적) 프로그래밍 개발자입니다. 두 당사자 모두 웹 개발을 잘 알고 있으며 강력한 문화를 가지고 있습니다. 어느 쪽이든 무시하는 것은 현명하지 않습니다.
초기 PHP 유형은 웹 개발에 대해 무엇을 알고 있었고, 어떤 점을 잘하고, 어떤 부분이 나빴나요? 디자인에 대해 많은 것을 알고 있습니다. 그 스타일은 때때로 의심스러울 수 있지만 더 널리 사용되는 RIA(Rich Internet Application) 기술은 말할 것도 없고 HTML 및 CSS 기능도 갖추고 있음을 알 수 있습니다. 항상 젊지만 PHP 포럼에 자주 등장합니다. "객체 지향"이라는 용어는 부정적인 의미를 가질 수도 있습니다. 코드는 간결하며 유지 관리보다는 성능에 중점을 둡니다.
UML 유형은 느슨한 유형의 변수와 HTML 코드를 문으로 채우므로 덜 매력적입니다. 애플리케이션 아키텍처, 클래스 수준 코드 재사용, 팀워크 및 소스 코드 관리를 고려합니다. 적당히 복잡한 웹 사이트라도 무엇보다도 애플리케이션이며 잘못 설계된 애플리케이션은 지연, 고객 짜증, 심지어 일자리 상실로 이어질 수 있다는 것을 알고 있습니다.
언뜻 보면 후자가 점점 더 까다로워지는 환경에 더 적합한 것처럼 보입니다. 이러한 환경에서는 웹 개발이 점점 더 마케팅 전략과 경제적 요인에 의해 주도될 것입니다. 하지만 전자를 멸종위기종으로 간주해야 할까요? 어쩌면 이렇게 되어서는 안 될 것 같습니다. 웹이 데스크톱 시스템과 매우 다른 매체라는 점을 인정한다면(메인프레임 환경에서 지배적인 개발 방법론을 탄생시킨 메인프레임(3270을 기억하는 사람이 있습니까?)은 말할 것도 없고) 결론은 다음과 같습니다. 성공했지만 상대적으로 지저분한 접근 방식에서 효과적인 것들을 배울 수 있습니다.
실제 문제가 발생하기 전에 극복해야 할 문제를 검토하고 몇 가지 실제 작업 방법을 검토해 보겠습니다.
문화 격차 해소
이제 PHP5는 객체 지향 기술을 PHP 세계에 도입하려고 합니다. Zend 엔진 수정(ZE2)은 객체를 언어의 핵심으로 가져옵니다. 새로운 언어 구성이 객체 프로그래밍 스타일을 장려할 뿐만 아니라 언어 구현도 다른 객체 지향 환경에 적용되고 있습니다. 예를 들어 기본적으로 객체를 앞뒤로 복사하는 대신 참조로 처리됩니다. 객체 개념에만 관련되고 Java 스타일을 보존하는 새로운 키워드(예: final 또는 static)가 도입되었습니다. 다른 기능(예: 위임)은 객체 디자인 패턴의 사용을 권장합니다. (몇 달 후에 모든 사람이 "원래 PHP4"에 대해 이야기하는 것을 들을 수 있을 것으로 기대합니다.) 이 중대한 변화는 현재 지배적인 프로그래밍 모델을 향한 무자비하고 혁명적인 전환에서 비롯됩니다. 좋든 싫든 개체 접근 방식은 웹 응용 프로그램이든 아니든 복잡한 응용 프로그램을 제공하는 데 가장 효과적인 것으로 입증되었기 때문에 계속 유지됩니다. 이에 우리는 디자인을 생각하는 사람과 건축을 이해하는 사람이 서로의 장점을 배울 수 있도록 두 문화를 조화시킬 수 있는 상상력 있는 방법을 찾을 수밖에 없습니다.
이를 위해서는 언어를 명확한 경계 내에 포함시키면서 언어의 다양성을 확보할 수 있는 방법을 개발(또는 다른 플랫폼에서 번역)해야 합니다. 이러한 방식으로 강력한 아키텍처 내에 프로그래밍 창의성의 "섬"이 존재할 수 있습니다.
한 가지 분명한 사실은 PHP CMS 또는 애플리케이션 프레임워크의 수가 폭발적으로 증가함에도 불구하고 이에 대한 합의가 이루어지지 않고 있다는 것입니다. 흔히 제기되는 불만은 프로젝트가 무엇이든 기존 시스템으로는 작업을 완료할 수 없다는 것입니다. 사람들은 종종 여러 시스템을 평가하는 것으로 시작하여 처음부터 자신만의 프레임워크를 개발하게 되는 경우가 많습니다. 왜 그래?
데스크탑 시스템에서는 GUI 디자인 문제가 운영체제에 의해 완전히 해결된 것 같습니다. 반면 웹은 독창적인 시각적 디자인이 중요한 역할을 하는 플랫폼입니다. 웹사이트에는 기업의 이미지와 개성이 담겨 있으며, 이는 기업의 수익에 점점 더 많은 영향을 미칠 수 있습니다. 시각적 창의성은 브랜딩과 밀접하게 연관되어 있으므로 이를 장려해야 합니다.
동시에 사용자 경험을 최대한 향상시키기 위해 애플리케이션에 유연한 논리를 엮을 수 있어야 하며, 사용자는 데스크톱 시스템에서보다 웹에서 더 정교하다는 점을 염두에 두어야 합니다. .
디자이너가 시스템 프로그래머가 설계한 시스템 때문에 끊임없이 좌절감을 느끼는 것이 문제이고, 개발자가 불완전한 포털 프레임워크에 애플리케이션 코드를 집어넣어야 하는 경우도 마찬가지로 문제입니다. 가장 일반적인 결과는 만족스럽지 못한 타협입니다. 즉, 애플리케이션의 복잡성을 관리 가능한 수준으로 제한하기 위해 많은 유용성을 희생하는 다소 둔해 보이는 것입니다. (이 현상은 PHP 애플리케이션에만 국한되지 않습니다.)
이러한 한계를 완전히 극복하려면 디자이너와 객체지향 개발자가 서로의 작업을 방해하지 않고 협업할 수 있는 방법을 찾아야 합니다. 가장 좋은 접근 방식은 다른 팀의 작업 방식을 이해하는 것부터 시작하는 것입니다.
기술에서 산업까지
지금 당장 협업 문제를 생각하지 말고 실제 운영을 살펴보겠습니다. 먼저 "enhanced html" 사용자의 스토어를 방문하여 PHP의 역사적 순서부터 시작하겠습니다.
거래 도구는 "순수 HTML" 사용자를 위한 도구와 매우 유사합니다. 다양한 수준의 편리한 기능과 프로젝트 관리 기능을 갖춘 일부 HTML 편집기와 어느 정도 PHP, ASP, JavaScript 및 그 이하의 도구를 통합해야 합니다. .
잠시 코드를 주의 깊게 살펴보겠습니다. 가장 먼저 눈에 띄는 것은 이러한 다양한 도구를 사용하여 제작된 웹사이트가 매우 아름답다는 것입니다. 여기서는 기술뿐만 아니라 재능에 대해서도 이야기하고 있습니다. 추상적인 프로그래밍 요소의 제약에서 벗어나 웹 디자이너는 실제 매장에서 기민한 장식가가 만든 것과 유사한 긍정적이고 미묘한 감정적 효과를 활용하여 웹 사이트 고객을 편안하게 하는 시각적 환경을 만듭니다.
숙련된 객체 지향 프로그래머의 관점에서 이 코드를 보면 상황이 갑자기 매우 잘못됩니다. 코드는 다음과 같습니다. 향후 개발이나 손쉬운 유지 관리를 위한 준비가 없는 일회성 작업으로 잊어버릴 수 있습니다. 실제로 종종 그렇습니다.
그럼 이게 무슨 문제인가요? 나중에 문제가 되어 사이트의 일부 또는 전체를 버리고 처음부터 다시 구축하게 될까요? 어쩌면 그렇지 않을 수도 있습니다. 결국, 실제 매장 장식은 정기적으로 철거되고 재건축되는 경우가 많습니다. 따라서 이러한 쇼케이스 웹사이트에는 카우보이 스타일의 PHP 프로그래밍이면 충분합니다. 이 언어에는 방문자의 관심을 끌 수 있도록 고안된 시각적 효과를 얻는 데 도움이 되는 기술이 풍부합니다. 이것은 분명히 객체 메소드와 아무 관련이 없습니다.
일부 애플리케이션 로직이 필요하면 이러한 관점이 크게 달라집니다. 귀하의 사이트를 자주 방문하는 사람들에 대한 소량의 마케팅 정보를 수집하려면 여러 가지 양식이 필요합니까? 이 정보가 관련성을 가지도록 하려면 인증 코드를 추가하는 것이 좋습니다. 이렇게 하면 악성 스크립트나 SQL 명령을 사용하여 침입 공격을 필터링할 수 있는지 확인해야 합니다. 그런데 OTN 기사를 읽고 있기 때문에 데이터베이스(DB) 문제에 대해 잘 알고 있어야 합니다. 수집할 정보는 일부 데이터베이스 테이블에 저장되며 PHP 코드의 SELECT 문은 이 데이터베이스 구조를 반영합니다. 이제부터 이 웹사이트는 이미 귀하의 비즈니스 인프라에 고정되어 완전한 애플리케이션이 되어가고 있습니다.
지금은 모든 하드 코딩된 링크, 위험한 유형 변환 및 보안 허점을 무시하고 PHP 객체 지향 애플리케이션의 최신 어셈블리 라인을 방문해 보겠습니다. 아티스트를 지향하는 우리 웹 디자이너들에게는 이런 장소가 낯설고 어쩌면 불친절할 수도 있습니다. 여기서는 기술에 그다지 중점을 두지 않습니다. 웹 개발이 산업화되었습니다. 여기에 합격하려면 클래스, 상속, 데이터 추상화 및 다양한 코드 캡슐화 도구에 익숙해야 합니다.
팀 공동작업에는 규칙이 필요합니다. 프로그래밍 규칙을 따라야 합니다. 소스 파일은 버전 제어 및 소스 코드 제어에 제출되어야 합니다. 파일은 엄격한 모듈식 계층 구조에 따라 구성됩니다. 위험한 코딩 기술, 특히 영리한 코딩 기술이 제거됩니다. 코드는 읽기 쉬워야 할 뿐만 아니라 주석도 잘 달아야 합니다.
귀찮을 수도 있지만 효과가 있습니다. 이제 우리는 인트라넷, 비즈니스 웹 사이트, 전자 시장, 결함이 있는 설계로 인해 비즈니스가 중단될 수 있는 모든 종류의 애플리케이션 등 웹 애플리케이션을 만들고 있습니다. 한마디로 우리는 복잡성을 극복하고 있습니다.
PHP 객체 지향 조립 라인 관리자는 언어를 사랑했기 때문에 PHP를 선택한 것이 아닙니다. 이렇게 하는 이유는 다른 독점 언어만큼 효과적으로 작업을 수행할 뿐만 아니라 무료이고 문자열이 첨부되지 않기 때문입니다.
우리 어디로 가는 걸까요?
그렇다면 C 및 Java 교육을 받은 사람들이 제공하는 업계 수준의 방법을 어떻게 활용하여 다용도 언어의 얼리 어답터의 전문 지식을 잠재적으로 보완할 수 있을까요?
PHP5는 많은 습관을 뒤흔들 것이므로 이 질문은 시기상조일 수 있습니다. 어떤 사람들은 어느 정도 객체 지향 접근 방식을 채택해야 하는 반면, 다른 사람들은 결국 객체 지향에 대한 모든 것을 배우고 이를 믿게 될 것입니다. 특정 틈새 시장은 과거와 마찬가지로 잘 작동하고 계속해서 번창할 수 있습니다.
연습해 봅시다
이제 간단한 습관을 기르는 방법과 간단하면서도 효과적인 솔루션을 찾는 것이 다가올 변화에 대비하는 데 어떻게 도움이 되는지 이해하기 위해 기본적인 기술 수준을 살펴보겠습니다. 매우 간단한 여러 규칙은 프로그래밍을 용이하게 하고 애플리케이션 확장을 준비하는 데 도움이 됩니다.
명명 규칙(C 프로그래머의 습관)이 가장 쉬운 방법입니다. 이미 PEAR와 같은 코드 베이스를 많이 사용하고 있다면 해당 규칙을 자신의 것으로 채택하는 것이 좋습니다. 그렇지 않으면 자체 내부 규칙을 개발해야 합니다. 단순화된 헝가리어 주석(헝가리 발명가 Charles Symonyi의 이름을 따서 명명됨)은 느슨한 유형이 허용하는 한 광범위하게 사용될 수 있습니다. 밑줄을 사용하여 클래스 멤버 앞에 붙일 수도 있습니다. 또 다른 유용한 습관은 클래스 외부에서 호출되지 않는 메서드(클래스에 속하는 함수)에 특수 접두사(예: impl_)를 추가하는 것입니다.
어떤 명명 규칙을 채택하든 코드를 최대한 명확하게 만드세요. 따라서 숙련된 사람은 초상화의 얼룩처럼 잘못된 것처럼 보인다는 이유로 PHP로 가득 찬 화면에서 프로그래밍 오류를 발견할 수도 있습니다.
명명 규칙의 또 다른 중요한 측면은 이름 충돌을 방지하여 대규모로 코드를 재사용할 수 있게 한다는 것입니다. 경험에 따르면 프로그래머는 프로그래밍 개체의 이름을 지정하는 데 항상 상상력이 풍부한 것은 아닙니다. 아마도 많은 Page 클래스가 있을 것이며 두 Page 클래스를 재사용하여 이름은 같지만 목적이 완전히 다른 것을 확인하는 것이 불가능하지는 않습니다. 정말 운이 좋지 않습니다. 장기적으로 이름을 바꾸면 유지 관리 문제가 발생합니다. 우선 이 문제를 피하는 것이 좋습니다. GUID를 생성하는 것은 과도하고 보기 흉하며(예: _16B280C5_EE70_11D1_9066_00C04FD9189D_Page!) PHP의 정신에 어긋납니다.
충돌을 방지하는 간단한 방법은 클래스의 여러 측면을 이름에 연결하여 내부 클래스를 고유하게 만드는 것입니다(예: GalleryPage). 클래스 충돌이 발생하는 경우, 소유한 도메인 이름의 예약된 버전(com_mydomain_GalleryPage)을 Java 방식으로 접두사로 붙일 수 있습니다.
애플리케이션 범위에 대한 예상치 못한 변경이 불가피할 때 비용이 전혀 들지 않고 작업 시간을 절약할 수 있는 또 다른 개발 습관은 가장 일반적으로 사용되는 기본 명령문을 채널의 단일 항목에 캡슐화하는 것입니다. 예를 들어 디버깅 코드를 제외하고 전체 애플리케이션에는 "응답" 문이 하나만 있어야 하며 일부 함수(또는 별도의 클래스 메서드)에 있어야 합니다. 새로운 환경에서 출력을 전처리하거나 리디렉션해야 하는 경우 대용량 파일을 검색하고 편집해야 하는 답답한 상황에 직면하지 않고도 필요한 몇 줄의 코드를 어디에 배치해야 하는지 알 수 있습니다.
오류 처리는 C만큼 엄격할 필요는 없습니다. C에서는 매달려 있는 포인터나 버퍼 오버플로가 매우 파괴적일 수 있습니다. 데이터 무결성이 손상되지 않으면 관대하게 방문자에게 일부 기능이 완벽하지 않더라도 다시 시도할 수 있다고 말하십시오. 자주 간과되는 도우미는 표준 set_error_handler() 함수입니다. 이는 모든 코드가 이러한 기본 이벤트를 처리하는 데 전념하는 중앙 위치로 캡슐화되는 또 다른 예입니다. 이번에는 기본 이벤트입니다. 반복되는 문제를 식별할 수 있도록 발생하는 모든 오류의 이벤트 로그를 유지하려는 경우 여기에서 수행해야 합니다.
저수준 프로그래밍에 대한 이야기를 마치기 전에 생명을 구하는 또 다른 트릭이 있습니다. PHP5에서는 기본적으로 객체 참조가 할당되거나 전달됩니다(참조는 객체 자체나 객체의 복사본이 아닌 객체에 대한 핸들입니다). PHP4를 사용해야 하는 한, 객체가 전달되는 방식에 세심한 주의를 기울여야 합니다. 당신을 불안하게 할 수 있는 몇 가지 미묘함이 있습니다. 예를 들어, 다음 명령문을 사용하면 $obj2가 $obj1의 복사본이 됩니다.
$obj2=$obj1;
달리 지정하지 않는 한 함수는 복사본을 사용하고 복사본을 반환합니다. 이 경우를 수락하면 됩니다. 다음 예에서는 추적하기 어려운 오류가 많이 발생합니다.
class ObjectKeeper {
var $_obj; // 모든 객체는
function & get_object() {
return $ this->_obj ;
}
}
//참조는 정상적으로 반환될 수 있습니다. 이제 트랩이 나타납니다.
$keeper = new ObjectKeeper();
$obj1 = $keeper->get_object();
$obj1->modify();
$obj2 = $ keeper->get_object(); // 동일한 객체에 대한 새 참조 요청
if ($obj2->is_modified()) {
echo 'OK' // 절대 인쇄되지 않습니다
}
올바른 구문은 다음과 같습니다.
$obj1=&$keeper->get_object() // "=" =&가 없으면 반환된 참조가 가리키는 객체의 복사본이 $obj1에 할당되며, 자신이 옳다고 생각하는 참조로 무엇을 하여도 원본 객체의 상태에는 영향을 미치지 않습니다. 즉, 업데이트가 손실됩니다.
템플릿은 웹 디자이너와 프로그래머의 문화를 조화시키는 데 큰 도움이 될 수 있습니다. 여기에는 일반적으로 페이지 생성 시 모든 변수 콘텐츠를 채우는 템플릿 엔진과 함께 레이아웃(주로 HTML 코드)에 들어가는 모든 항목이 포함됩니다. 대부분의 템플릿 엔진에는 데이터 소스 업데이트에 필요할 때만 리소스 집약적인 처리가 수행되도록 하는 캐싱 메커니즘이 포함되어 있습니다.
다음 단계
포럼: Oracle 기반 PHP
PHP 히치하이커 가이드
오픈 소스 개발자 센터
Oracle PHP 문제 해결 가이드
PHP 스크립팅: Freewheeling 코드의 인기가 점점 높아지고 있음
Oracle PHP 시작하기
Oracle, PHP 및 Apache 설치 Linux

템플릿 엔진을 사용하면 한쪽에서는 레이아웃과 그래픽을, 다른 쪽에서는 비즈니스 로직을 상당히 분리할 수 있습니다. 아마도 가장 인기 있는 템플릿 엔진은 Smarty일 것입니다. 이는 많은 오픈 소스 CMS 및 프레임워크 프로젝트에도 통합됩니다.
마지막으로, 논리가 기본 검색 및 바꾸기를 넘어서는 경우 템플릿 엔진이 프로그래밍 방언을 제공하는 경향이 있다는 점에 유의하는 것이 중요합니다. 미래의 접근 방식은 XSLT 기술에 의존할 가능성이 높으며 결과적으로 PHP5의 확장된 XML 지원이 많이 변경될 것입니다.
마지막으로 매우 중요한 실용적인 측면이 있습니다. 바로 잘 알려진 라이브러리의 일류 코드를 재사용하는 것입니다. 우리의 연구는 이제 표준 PHP 배포판의 일부인 PEAR로 제한됩니다.
PEAR는 이제 진정한 표준 PHP 소프트웨어 구성 요소에 더 가까워질 수 있습니다. 엄격한 공급자 선택과 엄격한 품질 표준을 통해 구성 요소가 상용 등급 구성 요소만큼 우수함을 보장합니다. 버전 관리 규칙을 사용하면 애플리케이션에 적합한 구성 요소 버전을 정확하게 제어할 수 있습니다. PEAR는 양식 처리부터 데이터베이스 추상화 계층(PEAR::DB)까지 다양한 기능 세트를 제공하며 웹 서비스 또는 WebDAV 지원과 같은 고급 기능을 포함합니다.
말할 필요도 없이 PEAR 및 유사한 PHP 코드 라이브러리에 익숙해지면 며칠 간의 집중적인 R&D 작업을 절약할 수 있습니다.
PHP5가 코앞으로 다가왔습니다
PHP는 Linux, Apache와 함께 가장 큰 오픈 소스 성공 사례 중 하나로 자리매김했습니다. 단점에도 불구하고 IT 세계에서 확고히 자리 잡았으며 대규모 사용자 기반이 여전히 이를 좋아합니다.
PHP5는 점점 더 PHP 코드를 수용하는 데이터베이스와 상호작용하는 비즈니스 로직 계층을 통해 강력한 웹 애플리케이션의 개발을 촉진할 수 있습니다. 동시에 유연한 프로그래밍 방법에서는 XML 기술을 점점 더 많이 사용하게 되어 웹 디자이너가 개발자 및 소프트웨어 디자이너와 원활하게 협업하기가 더 쉬워집니다.
우리는 매우 매력적이고 사용하기 쉬운 PHP 기반 웹 애플리케이션의 새로운 세대를 기대하고 있습니다.

위에서는 경제학의 내용을 비롯해 PHP가 성숙해졌다는 내용을 소개했습니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되었으면 좋겠습니다.