PHP가 싫은 12가지 이유

기어 변경이 골칫거리다 PHP 개발에 있어 가장 중요한 과제는 언제 HTML을 입력하고 언제 PHP를 입력하는지를 기억하는 것이다. 이 둘을 섞을 수 있다는 것이 PHP의 장점이긴 하지만 이를 잘 활용하는 것은 꽤나 골치 아픈 일이다. PHP를 개발할 때 코드처럼 보이는 하나의 파일을 보게 된다. 하지만 잠깐, HTML에서 서버 작업으로 전환되는 예의 그 태그는 어디에 있지? 이는 마치 서로 다른 계층에서 동작하는 두 개의 파일을 으깨어 놓은 것 같다. 이 모든 것은 코드를 마크업과 병합하기 위한 것으로, 주의를 필요로 한다. Credit: iStockphoto

마크업 미로 서버 측 작업과 브라우저 마크업을 섞은 것은 실수다. 자바 진영에서는 MVC 패러다임을 엄격히 지키도록 하고 있다. 즉, 데이터를 위한 모델이 하나의 파일에 들어가고 뷰를 제어하는 레이아웃 명령이 다른 파일에 들어가며 컨트롤러를 구성하는 로직이 세 번째 파일에 들어간다. 이렇게 분리하면 모든 것을 좀 더 조직적으로 만들 수 있다. 하지만 PHP의 경우 근본적으로는 HTML 마크업과 서버 측 컨트롤러 로직을 섞도록 되어있다. 이 둘을 분리할 수도 있지만(많은 사람들이 실제로 그렇게 하고 있다), 한번 그렇게 하기 시작하면 스스로에게 “왜 우리는 PHP를 쓰고 있는 거지?”라는 질문을 하게 될 것이다. Credit: Kutay Tanir

일관성이 없고 독특한 명명법 언제 밑줄을 사용해야 하는지 아는 사람? base64_encode 메쏘드에는 밑줄이 있지만 urlencode에는 없다. 마찬가지로 php_uname에는 밑줄이 있지만 phpversion에는 없다. 왜일까? 이에 대해 생각해 본 사람이 있을까? 누군가 API를 고쳤을까? 비슷하게 strcmp는 대소문자를 구분하지만 strcasecmp는 그렇지 않다. 또 strpos는 대소문자를 구분하지만 stripos는 아니다. i 혹은 case가 대소문자를 무시하라는 뜻일까? 이런 것을 누가 기억이나 할 수 있을까? 아마도 기억하는 편이 좋을 것이다. Credit: Wikipedia

정렬 지옥 정말로 필요한 정렬 함수는 몇 가지나 될까? 자바는 는 기본적인 정렬 함수 하나와 모든 객체를 위한 단순한 인터페이스를 제공한다. 다른 정렬 알고리즘을 원한다면 추가할 수도 있지만 대부분이 기본으로 제공되는 함수에 대충 만족한다. 반면 PHP에는 usort, sort, uksort, array_sort 등 수많은 정렬 함수가 있다(이들 중 일부에만 밑줄이 있다는 점에 유의하라). 그러므로 열심히 공부해서 컨닝 페이퍼를 만들어두기 바란다. Credit: Wikipedia

오픈소스에도 한계가 있다 PHP는 오픈소스라 할 수도 있지만 캐싱과 같은 좋은 기능은 상용이다. 이는 단지 현실적인 이유에서이다. Zend는 필요한 사람에게 최고의 버전을 판매함으로써 수익을 올리고 그 수익으로 전체 PHP를 지원한다. 이에 대해 불평하는 것은 중력을 불평하는 것과 같다. 지구에도 형편없는 부분은 있는 것이다. 다만 PHP가 하나의 큰 오픈소스라는 바보 같은 생각만은 하지 않길 바란다. Credit: David Trawin via Flickr

망가진 네임스페이스 자신만의 함수를 정의하고 싶은가? 그렇다면 우선 네임스페이스가 도입된 PHP 버전 5.3 이상을 사용할지를 먼저 결정해야 한다. 그 이하의 버전을 사용할 예정이라면 자신만의 함수가 다른 라이브러리에 있는 함수들과 충돌하지 않는지에 유의해야 한다. 이전에는 모든 것이 글로벌이었기 때문이다. PHP 5.3 이상의 버전에서 네임스페이스를 사용할 계획이라면 사상 최악의 구분 기호인 역슬래시에 익숙해져야 한다. Credit: Wikipedia

타입 안전성이 깨졌다 심하게 깨졌다. PHP 프로그래머들은 다음의 표현이 참이라는 점을 언급하기를 좋아한다. (string)"false" == (int)0 이 예가 일부 PHP 광팬들이 내세우는 전형적인 예들 중 하나가 아니라 실제로는 기능적인 부작용이라는 점에 주의하기 바란다. 그래도 어쨌든 자바스크립트 역시 극성스러운 타입 변환에서 비롯된 비슷한 예를 수없이 가지고 있다. 아니다. 예를 잘 보면 왼쪽은 문자열이고 오른쪽은 정수이다. 그런데 어찌된 일인지 이 둘은 같다. 아마도 PHP 설계자에게 세계를 맡기면 모든 사람들이 조화롭게 살아갈 수 있을 것이다.

너무 많은 옵션, 너무 많은 리던던시 너무 많은 것을 할 수 있는 너무 많은 방법이 존재한다. 엔드오브라인 코멘트는 숫자 기호나 슬래시 두 개로 명시할 수 있다. float과 double은 같은 뜻이다. 사람들이 각자 자신만의 작은 기능들을 추가하느라 간결함은 뒷전이 되었다. 설계는 위원회에서 했지만, 위원회는 이런 불화를 해결하기 위해 한 번도 모임을 가진 적이 없는 것 같다. Credit: Wikipedia

이상한 변수 명명법 달러 기호는 꽤 혼란스럽다. 템플릿에 삽입하기 쉽도록 모든 변수를 달러 기호로 시작하게 하는 것이 합리적이겠지만, 그렇다면 상수도 달러 기호로 시작해야 하지 않을까? Credit: Svilen.milev via Wikimedia

CPU 줄다리기 32비트 머신에서는 크기가 큰 정수와 관련된 문제가 있다. 이 경우 랩어라운드가 일어나지만 64비트 머신에서는 그렇지 않으며, 이 말은 코드가 머신에 따라 다르게 동작한다는 뜻이다. 데스크톱에서는 잘 동작하던 프로그램을 서버로 옮기면 완전히 다르게 동작할 수도 있다. 그리고 다시 데스크톱에서 같은 오류를 재현해보려고 시도하면 실패할 것이다. 한 가지 좋은 소식은 32비트 머신이 언젠가는 사라지게 되리라는 것이다. Credit: Linda Tanner via Wikimedia

SQL 삽입 사실 SQL 인젝션이라는 가장 큰 보안 취약점으로 PHP를 탓하는 것은 공평하지 않다. 다른 언어를 통해서도 얼마든지 이상한 SQL 문자열을 삽입할 수 있다. 단지 PHP의 경우 폼에서 데이터를 추출해 MySQL로 전송하기 쉽게 되어있을 뿐이다. 너무 쉽다. 일반적인 초보 개발자라면 어떤 언어를 사용하든 비슷한 실수를 저지를 수도 있지만 PHP로는 너무 간단한 일이다. Credit: Armin Kübelbeck via Wikimedia

호환되지 않는 변경사항이 너무 많다 버전 간에는 큰 차이가 있다. 호환성은 그리 간단한 문제가 아니다. 자바나 자바스크립트 같은 많은 언어들이 하위 호환성을 위해 빠른 진화를 포기했다. 오래된 코드가 새로운 버전이 설치된 머신에서 문제없이 돌아가는 것은 흔한 일이다. 그러나 PHP에서는 아니다. 다양한 버전들 간에는 큰 차이가 존재하며, 자신의 서버에 올바른 버전이 설치되어 있기를 기도하는 편이 좋을 것이다. 이상한 오류가 발생하기 시작해야만 문제를 알아차릴 수 있기 때문이다. 서버가 작동을 멈추었을 때 가장 먼저 해야 할 일은 누군가 PHP를 업그레이드 했는지 확인하는 것이다. Credit: Quinn Dombrowski via Flickr