PHP가 대규모 프로젝트에 적합하지 않은 이유는 무엇입니까?

왜 PHP는 대규모 프로젝트에 적합하지 않나요?

1. 재귀에 대한 지원 부족

재귀는 함수가 스스로를 호출하는 메커니즘입니다. 이는 복잡한 것을 매우 간단한 것으로 바꿀 수 있는 강력한 기능입니다. 재귀를 사용하는 예는 퀵 정렬(quicksort)입니다. 불행하게도 PHP는 재귀를 잘 수행하지 못합니다. PHP 개발자인 Zeev는 다음과 같이 말했습니다. "PHP 4.0(Zend)은 밀도가 높은 데이터에 대해 힙 접근 방식이 아닌 스택 접근 방식을 사용합니다. 이는 허용할 수 있는 재귀 함수의 수가 다른 언어보다 훨씬 덜 제한된다는 것을 의미합니다. 버그 1901을 참조하세요." . 이것은 매우 나쁜 변명입니다. 모든 프로그래밍 언어는 좋은 재귀 지원을 제공해야 합니다.

2. 많은 PHP 모듈은 스레드로부터 안전하지 않습니다

몇 년 전 Apache는 웹 서버 버전 2.0을 출시했습니다. 이 버전은 소프트웨어의 한 부분이 동시에 여러 부분을 실행할 수 있는 멀티스레딩 모드를 지원합니다. PHP 창시자는 PHP의 핵심은 스레드로부터 안전하지만 비핵심 모듈은 그렇지 않을 수 있다고 말합니다. 그러나 10번 중 9번은 이 모듈을 PHP 스크립트에서 사용하고 싶지만 이로 인해 스크립트가 Apache의 다중 스레드 모드와 호환되지 않게 됩니다. 이것이 바로 PHP 팀이 Apache 2의 다중 스레드 모드에서 PHP를 실행하는 것을 권장하지 않는 이유입니다. PHP의 열악한 멀티스레딩 모드 지원은 Apache 2가 여전히 인기가 없는 이유 중 하나로 자주 언급됩니다.

3. 비즈니스상의 이유로 PHP가 제대로 작동하지 않습니다

캐시를 사용하면 PHP 성능을 500% 향상시킬 수 있습니다 [벤치마크 테스트 참조]. 그렇다면 왜 PHP에는 캐싱이 내장되어 있지 않습니까? PHP 제조업체인 Zend는 자체 Zend Accelerator를 판매하므로 당연히 상용 제품을 버리고 싶지 않습니다.

그러나 또 다른 대안이 있습니다: APC(Zend는 나중에 무료 가속기-번역기인 Zend Optimizer를 출시했습니다)

4. 비표준 날짜 형식 문자

많은 프로그래머는 날짜 형식 문자가 모두 친숙하다는 점을 우려합니다. , UNIX 및 C 언어에서 유래되었습니다. 여러 다른 프로그래밍 언어가 이 표준을 채택했지만 이상하게도 PHP에는 완전히 호환되지 않는 날짜 형식 문자 세트가 있습니다. C에서는 "%j"가 올해의 날짜를 나타내고, PHP에서는 해당 월의 날짜를 나타냅니다. 그러나 상황을 더욱 혼란스럽게 만드는 것은 Smarty(인기 있는 PHP 템플릿 엔진)의 strftime 함수와 date_format 함수가 C/UNIX 형식 문자를 사용한다는 것입니다.

5. 혼란스러운 라이센스

PHP는 무료이고 매뉴얼에 언급된 모든 PHP 모듈도 무료라고 생각할 수 있습니다. 잘못된! 예를 들어, PHP에서 PDF 파일을 생성하려는 경우 설명서에서 PDF와 ClibPDF라는 두 가지 모듈을 찾을 수 있습니다. 그러나 이 두 가지 모두 상업적으로 라이센스가 부여되었습니다. 따라서 사용하는 모든 모듈에 대해 해당 라이센스에 동의해야 합니다.

6. 일관되지 않은 함수 명명 규칙

일부 함수 이름은 여러 단어로 구성됩니다. 일반적으로 단어 조합에는 세 가지 습관이 있습니다.

● 직접 연결: getnumberoffiles

● 밑줄로 구분: get_number_of_files

● Camel의 규칙: getNumberOfFiles

대부분의 언어는 그중 하나를 선택합니다. 하지만 PHP가 사용됩니다.

예를 들어 일부 특수 문자를 HTML 엔터티로 변환하려면 htmlentities(단어 직접 연결) 기능을 사용합니다. 반대 기능을 사용하려면 동생인 html_entity_decode를 사용해야 합니다. 특별한 이유로 이 함수 이름에는 밑줄로 구분된 단어가 있습니다. 어떻게 이런 일이 일어날 수 있습니까? strpad라는 기능이 있다는 걸 아시나요? 아니면 str_pad인가요? 매번 기호가 무엇인지 확인하거나 오류를 기다려야 합니다. 함수는 대소문자를 구분하지 않으므로 PHP의 경우 rawurldecode와 RawUrlDecode 간에 차이가 없습니다. 둘 다 사용되어 다르게 보이고 독자를 혼란스럽게 하기 때문에 이는 또한 나쁩니다.

7. 마법의 인용문

마법의 인용문은 SQL 주입 공격으로부터 PHP 스크립트를 보호할 수 있습니다. 이것은 좋다. 그러나 어떤 이유로 인해 php.ini에서 이 구성을 끌 수 있습니다. 따라서 유연한 스크립트를 작성하려면 항상 매직 참조가 켜져 있는지 꺼져 있는지 확인해야 합니다. 이러한 "기능"은 프로그래밍을 더 쉽게 만들어 주지만 실제로는 프로그래밍을 더 복잡하게 만듭니다.

요약

매우 작은 프로젝트의 경우 매우 만족스러운 프로그래밍 언어가 될 수 있습니다. 그러나 더 크고 복잡한 프로젝트의 경우 PHP는 약점을 드러냅니다.

PHP 관련 지식을 더 보려면 PHP 중국어 웹사이트를 방문하세요!

위 내용은 PHP가 대규모 프로젝트에 적합하지 않은 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!