번역의 글

번역자는 phpthewrongway 의 모든 의견에 무조건적으로 따르지 않습니다.

일부 내용은 공감하며 일부 내용은 공감하지 않습니다.

다만 모던 PHP 외에도 여러가지 관점이 있다는 것을 알리기 위해 번역했음을 말씀드립니다.

환영합니다.

PHP 프로그래밍의 세계에서,(책과 웹 사이트에서) "Modern PHP"로 많은 트렌드를 전파하고 있는 일부 사람들은 Modern PHP 를 제외한 다른 모든 접근 방식을 어리 석거나 단순한 잘못으로 치부함으로써 눈살을 찌뿌리게 합니다.

이 사람들은 다른 사람들이 본인이 일하는 방식을 따르도록 지칠 줄 모르고 일하는 것 같습니다.

이 웹 사이트는 PHP 프로그래밍에 대한 실용적인 견해를 제시하기 위해 만들어졌습니다.

대중적 경향, 이론 또는 학문적 교리보다는 경험과 실제적인 결과에 의해 결정된 견해를 말합니다.

웹 사이트 PHP-The Wrong Way는 살아있는 문서이며 가능하면 더 많은 정보로 계속 업데이트됩니다.

부담없이 참여하십시오.

번역

프로그래밍 규칙 및 가이드 라인의 한 가지 문제점은 특정 맥락(컨텍스트) 안에서만 해결책을 제공한다는 것입니다.

맥락에서 벗어나면 좋은 규칙은 끔찍한 규칙이 될 수 있습니다.

사실, 모든 좋은 규칙은 극단적으로 나아질 때 나빠집니다.

많은 사람들이 제시한 많은 소프트웨어 개발 원칙과 규칙이 시간들은 지남에 따라 다른 사람들에 의해 소개되고 발전합니다.

때로는 극단 주의자들에 의해 오용되기도 하기 때문에 맥락에 맞는 규칙을 이해하는 것은 중요합니다.

경험에 따르면 일반적인 규칙과 지침을 잘못 사용할 경우 복잡성, 보안 부족, 오류가 발생하기 쉬운 결과가 자주 발생하며 특정 상황에는 완전 대대적인 재앙이 발생합니다.

KISS 원칙은 "Keep It Simple Stupid"의 약자이며 (심플하게 생각해 바보야), 일반적으로 숙련된 사람들의 관점에서는 현명하고 좋은 조언이고 따라야 할 좋은 원칙입니다.

그러나 이 위대한 원칙조차도 극단적으로 받아 들여지면 프로젝트에 위험이 됩니다.

때로는 "지나치게 간단한" 것은 기능이 부족한 결과를 불러오게 될 수도 있으니까요.

잘못된 길 : 규칙과 지침을 종교처럼 따릅니다. Thumbs down

항상 프레임 워크를 사용하십시오

모든 범용 PHP 프레임워크는 엉망입니다!

-[Rasmus Lerdorf] (https://www.youtube.com/watch?v=DuB6UjEsY_Y)

PHP 커뮤니티에서 웹 어플리케이션 개발을 할 때 대중적인 범용 프레임워크를 쓰는 나쁜 추세는 사실상 표준이 되었습니다.

이러한 추세는 결과적으로 개발 절차를 향상시키거나 기술적이고 아키텍쳐 관점에서 옳은 일이기 때문에 등장하고 대중화된 것이 아닙니다.

그저 프레임워크 개발자 중 일부가 "바퀴를 재발명하지 마세요!" 그리고 "직접하지 마세요. 다른사람들이 당신보다 능숙합니다." 같은 문구로 (기존) 프로그래밍 방법에 논쟁을 지피고 대중을 선동할 수 있기 때문에 인기를 얻은 것입니다.

오늘날의 많은 프로그래머들은 건전한 프로그래밍의 기본 원칙을 완전히 무시하고, 다른 사람에게 더 영리하고 쿨하며 더 변화를 잘 받아들이는 사람으로 보이기 위해 복잡한 새 레이어를 쌓아서 환상적으로 보이려고 많은 시간을 허비합니다.

이 사람들은 다른 사람들이 자신의 "일을 하는 방법"을 따르고, PHP 커뮤니티 리더가 되고, 다른 사람들이 그들의 최신 "힙한" 오픈 소스 도구를 사용하게 하는 것에 빠진 것 처럼 보입니다. 그들은 건전하고 확고한 조언이 필요하다는 것을 잊어버린 것 같습니다.

소프트웨어 산업에서는 미리 만들어진 집을 범용 프레임워크와 비교할 수 있습니다. 미리 만들어진 집을 사온다고 해서 목수가 되는 것이 아니듯이 범용 프레임워크를 사용하여 소프트웨어를 구축한다고 해서 코더나 프로그래머가 되는 것은 아닙니다.

이 웹 사이트에서는 다음과 같은 방식으로 프레임워크와 라이브러리를 구분합니다.

  • 라이브러리 : C 표준 라이브러리 또는 Go 표준 라이브러리와 같은 재사용 가능한 코드 모음 을 말합니다. 그것은 어떤 제한이나 제한을 강요하지 않고 자신의 프로젝트에 쉽게 통합하는 코드로 구성됩니다. 각각 하나의 특정 기능을 가진 작은 코드 조각으로 구성됩니다.
  • 프레임 워크 : 재사용 가능한 코드 모음이 아닙니다. 프레임 워크에서 코드를 가져와 자신의 프로젝트에 통합 할 수는 없습니다. 프레임 워크는 소프트웨어 구축을 돕는 시스템이지만 동시에 프레임 워크 자체의 제약 혹은 제한 내에서 작업하도록 합니다. 프레임 워크 자체에는 많은 상호 의존적인 기능이 있습니다. 한 조각은 다른 조각 없이는 작동 할 수 없습니다.

파이썬과 루비의 세계에서는 처음부터 웹 사이트를 구축하기 위해 파이썬이나 루비가 만들어지지 않았기 때문에 처음부터 웹 사이트를 구축하는 것은 번거로운 일입니다. 결과적으로 DjangoRuby on Rails는 이러한 언어로 웹 사이트를 구축하는 데 빠르게 인기를 얻었습니다.

반면에 PHP는 처음에 Rasmus Lerdorf에 의해 동적 HTML을 쉽고 빠르게 개발할 수 있는 C언어로 작성된 도구 모음으로 시작했습니다. PHP는 그때부터 지금까지 그 자체로 프레임 워크 입니다.

그 이후로 PHP는 엄청나게 발전해 왔으며 오늘날 PHP는 HTML과 웹 사이트를 구축하는 것 이상으로 사용할 수 있지만 PHP를 자체 프레임 워크로 보는 것은 잘못된 것이 아닙니다. PHP는 본질적으로 웹 응용 프로그램을 개발하기 위해 절차적인 C언어의 추상화 계층입니다.

프로젝트 내에서 라이브러리를 사용하는 것은 자연스럽습니다. PHP 자체에는 코드를 확장하는 데 사용할 수 있는 라이브러리 세트가 기본으로 제공됩니다. 예를 들어 PDO는 PHP에서 데이터베이스에 액세스하기 위한 일관된 인터페이스를 제공하는 경량 라이브러리입니다.

반면에 PHP 위에 프레임 워크를 사용하는 것은 전적으로 또 다른 문제입니다.

PHP에서 프레임워크를 사용할 때 시작과 동시에 다른 추상화 계층 위에 다시 한번 계층(레이어)을 덧붙입니다. 프레임워크가 제공하는 추가 추상화 계층은 당신의 코드를 미리 정해진 패턴으로 사용하게 하거나, 수백개의 클래스와 메소드가 얽혀있는 복잡한 의존성 지옥으로 데러가거나, 필요 이상의 계층을 추가함으로써 복잡성을 증대시킬 것입니다.

모든 경험은 인터페이스에서 시작합니다. 인터페이스 경험은 기술에 대한 이해와 추상화 계층의 결과입니다.더 많은 추상화를 사용하면 효율성이 떨어지고 어플리케이션의 안정성이 떨어지게 될 것입니다. 높은 추상화는 꼼꼼함과 효율성을 잃어버립니다.

이를 명확하게 이해하십시오. 어떤 프로젝트든 이상적인 코드는 명확하고 읽기 쉽고 줄 수가 적습니다.

모두에게 필요한 것은 범용 프레임워크가 아닙니다. 일반적인 문제는 없습니다. 모두가 해결하려는 매우 구체적인 문제가 있습니다.

-Rasmus Lerdorf

일부 회사는 PHP 프레임 워크에 대한 과대 광고를 듣기 시작했으며 이러한 인기있는 범용 프레임 워크 중 하나를 사용하여 다음 프로젝트를 시작하여 재난을 겪었습니다. 그들은 범용 프레임 워크가 특정 요구를 해결하는 데 실제로 나쁠 뿐만 아니라 느리다는 것을 발견했습니다. 확장이 불가능했고 결과적으로 그들은 실제로 필요하지 않은 모든 것을 꺼내기 위해 필사적으로 프레임 워크를 추출하는 것을 시도해야 했습니다.

항상 실용적인 접근 방식을 사용하십시오.

이론이나 교리보다는 즉각적인 실질적인 결과를 고려하여 결정된 행동하거나 정책을 결정하세요.

-콜린스 영어 사전, Complete and Unabridged, 12th Edition 2014

잘못된 방법 : 항상 PHP 위에 프레임 워크를 사용하십시오. Thumbs down

항상 디자인 패턴을 사용하십시오

나는 아이보리 타워 디자인 및 디자인 패턴에 큰 알레르기가 있습니다. Peter Norvig는 Harlequin에 있을 때 디자인 패턴이 실제로 프로그래밍 언어의 결함 하는 방법에 대해 문서를 작성했습니다. 더 좋은 프로그래밍 언어를 얻으세요. 패턴은 절대적으로 옳습니다. 패턴을 숭배하고 "아, 나는 X 패턴을 사용할 것이다."라고 생각하세요.

-브렌든 아이크 (Brendan Eich) - 직장 코더-프로그래밍 기술에 대한 고찰

소프트웨어 엔지니어링에서 디자인 패턴은 소프트웨어 디자인에서 일반적으로 발생하는 문제에 대한 재사용 가능한 솔루션입니다. 디자인 패턴은 코드로 직접 변환 할 수있는 완성된 디자인이 아닙니다. 다양한 상황에서 사용할 수 있는 문제를 해결하는 방법에 대한 설명 또는 아이디어입니다. 객체 지향 디자인 패턴은 특정 클래스 혹은 개체 없이 클래스 혹은 개체간의 관계와 상호작용에 대해 보여줍니다.

PHP는 명령형, 기능성, 객체 지향, 절차 및 반사 패러다임을 지원합니다. PHP는 한 가지 방법이 아닌 여러 가지 방법으로 많은 문제를 해결할 수있는 다양한 도구가 포함 된 거대한 도구 상자입니다.

PHP는 자유롭고 빠르며 확장 가능한 솔루션 및 다양한 문제 해결 방법을 가지고 있습니다.

우리는 개별 패턴이나 아이디어의 철학에 매달려서 현실을 잊어버리는 경우가 종종 있습니다.

프로그램에서 패턴을 볼 때 문제의 징후라고 생각합니다. 프로그램의 형태는 해결해야 할 문제만 반영해야 합니다. 코드에 다른 규칙적인 신호가 있다면, 최소한 저에겐, 충분히 강력하지 않은 추상화를 사용하고 있다는 뜻입니다. - 종종 저는 필요한 매크로를 수작업으로 작성하곤 합니다.

-폴 그레이엄

특정 패턴이나 솔루션의 철학이나 아이디어에 너무 얽매이지 않아야합니다. 우리의 주요 관심사는 찾기 쉽고, 가능한 이해하기 쉽고, 유지보수하기 쉽고 보안을 유지하는 데 있어야 합니다.

우리는 또한 안티 패턴과 같은 것이 존재한다는 것을 기억해야합니다. 일반적으로 사용될 수 있지만 실제로는 비효과적이고 비생산적입니다.

패턴이 일반적인 문제에 대해 일반적으로 인정되는 최상의 솔루션으로 시작되었다고 생각합니다. 하지만 지금 우리는 어플리케이션이 필요한 것보다 10배 더 복잡한 것을 경험했습니다. 사람들은 읽어본 패턴을 (올바른 이해 없이) 적용하려고 하기 때문입니다. ("내 어플리케이션은 잘 구조화되어 있어. 왜냐하면 패턴대로 작성되었거든.") 패턴에 대한 제 인식이 조금 바뀌었습니다.

-Paul Weaton - 사악한 디자인 패턴

하지만 지금 우리는 어플리케이션이 필요한 것보다 10배 더 복잡한 것을 경험했습니다. 사람들은 읽어본 패턴을 (올바른 이해 없이) 적용하려고 하기 때문입니다. ("내 어플리케이션은 잘 구조화되어 있어. 왜냐하면 패턴대로 작성되었거든.") 패턴에 대한 제 인식이 조금 바뀌었습니다.

항상 실용적인 접근 방식을 사용하십시오.

이론이나 교리보다는 즉각적인 실질적인 결과를 고려하여 결정된 행동하거나 정책을 결정하세요.

-콜린스 영어 사전, Complete and Unabridged, 12th Edition 2014

잘못된 방법 : 문제를 해결할 패턴을 찾으십시오. Thumbs Down

항상 객체 지향 프로그래밍을 사용하십시오

객체 지향 언어의 문제점은 묵시적인 환경을 가지고 있다는 것입니다. 바나나를 원했지만 바나나와 정글 전체를 들고있는 고릴라였습니다.

-Joe Armstrong - 작업중인 코더-프로그래밍 기술에 대한 고찰

추상화는 강력합니다. 제가 90 년대에 실제로 알레르기 반응을 보인 것은 CORBA, COM, DCOM, 객체 지향 넌센스였습니다. 모든 스타트업에는 "Hello world" 를 출력하기 위해 200,000개의 메소드 호출을 하는 미친 일도 있었습니다. 그것은 비극입니다! 당신은 그런 종류의 일과 관련된 프로그래머가되고 싶지 않을 것입니다.

-브렌든 아이크 (Brendan Eich) - 직장 코더-프로그래밍 기술에 대한 고찰

오늘날 많은 소프트웨어 개발자와 많은 회사에서 객체 지향 프로그래밍이 소프트웨어를 개발할 수 있는 유일한 방법이라고 생각합니다. 객체 지향 프로그래밍에 반대하는 사람은 즉시 업계의 "전통적인 지혜"에 대해 논쟁하고 있다는 사실을 의식하게 됩니다.

프로그래밍 블로그와 포럼에는 대단한 많은 사람들이 객체 지향에 대해 정의하고, 알고 있는것과 느끼고 있는 것에 대해 논의하고 확신하는 사람들이 많습니다. 객체지향에 표준 정의는 없다는 사실을 간과한 채로요.

사실 객체 지향 프로그래밍이라 불리는 것은 종종 불필요한 복잡성으로 인한 무거운 부담을 만들어 냅니다.

컴퓨터 과학자와 프로그래머로서 우리는 편견을 없애고 주어진 문제에 대한 최상의 해결책을 찾는 법을 배워야합니다.

오늘날 PHP의 주요 장점 중 하나는 명령형, 기능성, 객체 지향, 절차 및 반사 패러다임에 대한 지원입니다. PHP는 여러 가지 도구를 갖춘 거대한 도구 상자로, 한가지 방법 만이 아니라 여러 가지 방법으로 많은 문제를 해결할 수 있습니다.

응용 프로그램 내에서 서로 다른 문제를 하나의 특정 프로그래밍 패러다임에 강제로 끼워맞춘다면 우리는 창의적으로 생각할 수 없고, 효과적으로 일할 수 없습니다.!

작은 역사 수업

특정 프로그래밍 패러다임을 이해하는 가장 좋은 방법 중 하나는 그것이 어떻게 진화했는지를 보는 것입니다. 개발 이유는 무엇입니까? 새로운 사고 방식이 필요한 다른 프로그래밍 패러다임에는 어떤 문제가 있습니까? 실제 문제입니까 아니면 단순히 학문 문제입니까? 그리고 어떻게 진화 했습니까?

X의 말이나 Y의 정의에 상관없이 패러다임의 맥락에서 중요한 것은 그것들을 만든 역사입니다.

소프트웨어 설계는 두 가지 방법으로 구성 할 수 있습니다. 한 가지 방법은 간단하게 결함이 없도록하는 것입니다. 그리고 다른 방법은 명백한 결함이 없도록 너무 복잡하게 만드는 것입니다.

>

-C.A.R. Hoare

예전에, 50 년대 말에 객체 지향 프로그래밍이 출현하기 전, 많은 소프트웨어가 구조화되지 않은 프로그래밍을 강조하는 프로그래밍 언어 (때로는 1세대 및 2세대 언어라고 함)를 사용하여 개발되었습니다. 비구조적 프로그래밍은 역사적으로 가장 초기의 프로그래밍 패러다임입니다. 비구조적 프로그래밍은 "스파게티"코드를 제작 한 것에 대해 비판을 받았었습니다.

비구조적 프로그래밍을 사용하는 고급 및 저수준 프로그래밍 언어가 있습니다. 여기에는 BASIC의 초기 버전, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, 기계어, 초기 어셈블러 시스템 (절차적 메타 연산자가 없는 시스템) 및 일부 스크립팅 언어가 포함됩니다.

구조화되지 않은 언어로 작성된 프로그램은 일반적으로 순차적으로 정렬 된 명령 또는 명령문이 일반적으로 각 행(줄) 에 하나씩 있는 형태로 구성됩니다. 행은 보통 번호가 매겨져 있거나 레이블이 있거나 둘 다 있습니다. 이 레이블을 사용하면 실행 흐름이 (goto 문 등을 이용해서) 프로그램의 모든 행으로 이동할 수 있습니다.

그런 다음 60년대에 Edsger W. Dijkstra의 유명한 서한으로 인해 구조화 된 프로그래밍이 등장했습니다. Go To statements considered harmful.

구조적 프로그래밍은 서브 루틴, 블록 구조 및 루프를 사용하여 소프트웨어의 명확성, 품질 및 개발을 향상시키는 프로그래밍 패러다임입니다. 이것은 GOTO 문과 같은 간단한 점프를 사용하는 것과 대조적입니다.

이후 구조적 프로그래밍에서 절차적 프로그래밍이 파생되었습니다. 절차적 프로그래밍은 "프로시저 호출"이라는 개념을 기반으로 합니다. "프로시저 호출"은 "함수 호출"의 또다른 이름입니다. 절차는 루틴, 서브 루틴 또는 메소드라고도 합니다. 프로시저는 단순히 실행할 일련의 연산을 순서대로 가지고 있습니다. 프로시저는 자신을 포함해서 어떤 프로시져도 호출할 수 있습니다.

처음에는 모든 프로시저들은 프로그램의 어느 부분에서나 전역 데이터를 사용할 수 있었습니다. 작은 프로그램에서는 이것이 문제가 되지 않았지만, 업무가 복잡해지고 프로그램의 크기가 커짐에 따라 프로그램의 한 부분에 대한 작은 변경은 다른 많은 부분에 큰 영향을 미쳤습니다.

프로그램의 변경을 위해서는 많은 의존성을 확인해야 하는 것을 누구의 계획에도 없었던 일입니다. 하나의 프로시저에서 사소한 변경이 일어나면 원본 코드에 의존하는 수많은 프로시저에서 연쇄적으로 오류가 발생합니다.

데이터를 "개체"라고 하는 분리된 범위로 나눌 수있는 새로운 기술이 발전했습니다. 같은 범위에 속하는 특정 프로시저만 동일한 데이터에 액세스 할 수 있습니다. 이를 캡슐화라고 합니다. 결과는 훨씬 더 체계적인 코드였습니다.

처음에는 객체를 객체라고 부르지 않았으며, 단지 별도의 범위로 간주되었습니다. 나중에 의존성이 줄어들고 이러한 범위 내의 프로 시저와 변수 간의 연결이 분리된 영역으로 간주되고 나서 "객체"및 "객체 지향 프로그래밍"의 개념을 탄생했습니다.

이후 자바(Java) 의 개발로 인해 "프로시저"나 "함수"는 더이상 "함수" 라고 부르지 않고 자바의 "buzzwords" 인 "메소드" 로 이름이 변경되었습니다. 변수 또한 더이상 "변수" 라고 부르지 않고 "속성(attribute 혹은 property)" 라고 이름이 바뀌었습니다. "메소드"와 "속성" 은 둘 다 "분리된 영역" 안에 있을 때 부르는 이름입니다.

따라서 객체는 본질적으로 단순히 "분리된 영역 안에 있는 메소드 및 속성" 이라고 하는 함수 및 변수의 모음입니다.

메소드와 속성이 별도의 범위 내에서 격리되는 방법은 "클래스"를 사용하는 것입니다. 일단 인스턴스화되면 클래스를 객체라고 합니다.

객체는 서로를 참조 할 수 있으며 이러한 참조를 통해 내부의 메소드 (함수)는 서로 "통신"할 수 있습니다. 객체는 다른 객체로부터 메소드를 "상속"하여 확장 할 수 있으며 이를 "상속"이라고합니다. 코드를 재사용하고 공개 클래스와 인터페이스를 통해 소프트웨어의 독립적인 확장을 가능하게 하는 방법입니다. 객체의 관계는 계층 구조를 만듭니다. 상속은 프로그래밍 언어 Simula 67에 대해 1967 년에 발명되었습니다.

객체는 다른 객체의 메소드를 상속하고 추가되거나 변경된 기능을 "재정의"할 수 있는데 이를 "다형성"이라고 합니다.

이러한 다양한 아이디어가 구현되는 방식은 프로그래밍 언어마다 다릅니다.

객체 지향 프로그래밍은 이전과 다른 방식으로 코드를 구성하는 것입니다. 프로시저 프로그래밍의 확장이며 데이터를 숨기고 (캡슐화) 전역 범위를 피하는 것입니다. 실제로 원래 코드(상속)에 영향을 주지 않고 원본 객체의 청사진(blueprint)을 "빌려" 기능을 확장하는 것입니다. 그리고 원래 코드 (다형성)에 영향을 미치지 않고 함수를 재정의하는 것입니다.

객체 지향 모델을 사용하면 프로그램을 쉽게 구성 할 수 있습니다. 실제로 이것이 의미하는 바는 스파게티 코드를 작성하는 구조화 된 방법을 제공한다는 것입니다.

-Paul Graham : Ansi Common Lisp

잘못된 방법 : 항상 객체 지향 프로그래밍을 사용하십시오. thumbs down

다른 사람의 코드를 두려워하기

프레임 워크 사용에 대해 종종 들리는 주장은 사람들이 다른 사람들이 처음부터 작성한 코드베이스를 다루기를 원하지 않는다는 것입니다.
그러나 이것은 PHP 커뮤니티의 웹 개발자들 사이에서 주로 발생하는 이상한 사고 방식입니다. 그것은 전문성과 경험의 부족을 뜻할 뿐입니다.
소프트웨어를 작성하고 다른 사람들의 코드를 다루는 것은 정상입니다. 프로 개발자의 일상 업무의 일부입니다. 두려워 할 것이 아닙니다.

프로 개발자는 다른 사람의 코드를 보며 이전 개발자가 프레임워크 A, 혹은 프레임워크 B를 썼을 때 며칠이나 걸렸을 지에 대해 말하기 시작하지 않습니다.
이것은 전문 프로그래머의 사고 방식이 아닙니다. 아무도 그러지 않습니다.
아마도 PHP 웹 개발에 대한 진입 장벽이 이런 종류의 사고 방식의 일부일 것입니다. 어쨌든, 그것은 일을 잘 못하는 사람을 나타내는 표시입니다.
프로그래밍의 많은 부분은 사람들이 다른 사람들의 코드를 다루어야 합니다. 기존 코드베이스를 개선해야 하며 때로는 완전히 재작성해야 할 때도 있습니다.

프로그래밍 대가들의 생각을 알고 싶다면코더 작업-프로그래밍 기술에 대한 고찰 을 읽어보십시오.

세계에서 가장 크고 성공적인 소스코드 중 일부는 서로 만난 적이 없는 수백 명의 사람들이 개발했습니다. 소스코드는 어떤 프레임워크도 없이 작성되었고, 완전히 절차적인 언어로 작성되었습니다. 절차적 패러다임 외에는 이런 일을 꿈도 꿀 수 없습니다.
Linux Kernel은 어떠한 프레임 워크도 사용하지 않고 14,000명 이상의 기여자가 완전히 절차적인 프로그래밍 방식을 사용하여 2천만 줄 이상의 코드로 작성되었습니다.

다른 예제로는 BSD 혹은 Linux GNU userland 의 프로그램들을 들 수 있습니다. 모두 어떤 프레임워크 없이 절차적인 프로그래밍으로 작성되었습니다.

최초 개발자가 포기한 전 세계 수백개의 오픈소스 프로젝트 중 일부만 다른 실력있는 개발자에 의해 다시 선택됩니다. 이러한 프로젝트들은 문서가 거의 없고, 만약 있다면 코드에 주석이 없고 지침이나 가이드라인이 없습니다.

전체 PHP 소스코드는 어떤 종류의 프레임 워크도 사용하지 않고 순수한 절차 프로그래밍 언어 인 C로 작성됩니다. PHP에서 클래스를 정의하거나 당신이 가장 좋아하는 PHP 프레임 워크를 실행할 때마다 결국에는 (내부적으로) 순수하게 절차적으로 작동하게 됩니다.

물론, 끔찍한 코드, 처음부터 설계되지 않은 코드 또는 점점 비대해졌으나 클라이언트는 재작성하고 싶지 않은 코드도 있습니다. 너무 나빠서 더이상 머리나 꼬리를 떼어내기 어려울 상황도 있습니다. 그렇지만 이런 상황을 막을 수 있는 프레임워크는 없습니다. 이것은 자주 일어나는 프로그램의 자연스러운 성장 과정입니다. 어떤 프레임워크도 조각화를 막지는 못합니다.

물론 아무도 의도하지는 않았으나 끔찍한 spagetti 코드도 있습니다. 때론 이것은 경험 부족의 결과입니다. 만약 프레임워크를 사용하더라도 스파게티 코드는 여전할 것이고 개발의 중간 단계 혹은 어떤 경우든 간에 많은 시간을 보내고 나서야 실패할 수 있습니다. 객체지향적으로 만들어도 스파게티 코드는 여전히 스파게티 코드입니다.

프로그래머로서 우리 모두는 이러한 상황을 막으려고 노력합니다. 하지만 이건 정상이며, 이것이 프로그래밍의 기술 입니다. 이런 것이 프로그래머가 되는 과정 중 일부 입니다.

잘못된 방법 : 다른 사람들의 코드를 두려워합니다. Thumbs down

종교적으로 PHP-FIG 표준을 준수하기

FIG는 "프레임 워크 상호 운용성 그룹"을 의미합니다.

PHP-FIG는 2009년에 php|tek 에서 많은 프레임워크 개발자들에 의해 만들어졌습니다. 이후 다양한 다른 회원들이 참여하고 투표를 한 끝에 처음에 5명으로 시작했으나 총 20명까지 늘어났습니다.

PHP-FIG에 관한 많은 논란이 있습니다. 어떤 사람들은 PHP-FIG를 PHP 자체 이후로 PHP 커뮤니티에서 일어난 최고의 일이라고 생각하는 반면, 다른 사람들은 그 그룹을 잊혀지는 것이 가장 좋다고 여깁니다.

PHP-FIG의 문제점 중 하나는 FAQ에서 다음과 같이 나타납니다.

그룹의 기본 개념은 프로젝트 담당자가 프로젝트 간의 공통성에 대해 이야기하고 함께 작업 할 수 있는 방법을 찾는 것입니다. 우리의 주요 독자는 각자 다르지만 나머지 PHP 커뮤니티들도 지켜보고 있음을 잘 알고 있습니다. 우리가 하는 일을 채택하고 싶다면 환영하지만 그것이 목표는 아닙니다. 그룹 내 아무도 개발자로서 어떻게 어플리케이션을 빌드하는지 말하지 않습니다.

그렇지만 우리가 그룹 구성원들이 한 일을 봤을 때 우리는 명백히 위 진술과 반대임을 알 수 있습니다. 이 멤버들은 PHP-FIG 를 "PHP 표준 그룹" 으로 만들려고 애쓰고 있으며, 이것이 이 그룹의 원래 이름 이기도 합니다. 이들은 책, 웹사이트, 블로그, 포럼 등에서 PHP-FIG가 하는 일을 "모던 PHP" 로 분류하고 다른 방법들은 모던 PHP가 아니라고 정의합니다.

PHP-FIG의 문제점 중 하나는 많은 프레임 워크와 오픈 소스 프로젝트를 여러 기준으로 채택했지만, 이러한 표준은 실제 산업에서는 아주 쓸모업는 프레임워크 관점의 많은 문제를 처리한다는 점입니다.

많은 사람들이 고객이 구매하고 사용하고자 하는 매우 효율적이고 안전하며 비용 효율적인 소프트웨어를 산업에 맞게 개발합니다. 이런 것들을 프레임워크 광신자들의 요구에 부합해야 하는 표준으로 방해하면 안됩니다. (프레임워크 기준에 맞추려고) 노력한다면 그것은 사업에 재앙이 될 것입니다.

어떤 종류의 표준 그룹이 필요하다면 프레임워크 및 오픈 소스 CMS 프로젝트 개발자뿐만 아니라 전체 PHP 커뮤니티의 관심사를 반영해야합니다. 그것은 PHP 프로그래밍 언어 자체를 사용하는 개발자들에 의해 대표되어야 하며 투표권을 더 큰 회원들이 가지도록 반영해야 합니다.

PHP-FIG에서 개발한 표준을 채택하기로 선택한 경우 소프트웨어 코드에 영향을 미치는 표준들 - 오토로더, 표준 PSR-0, PSR-4 및 기타 여러 표준과 같은 여러 표준을 이해해야 합니다.

많은 산업군은 높은 확장성, 런타임 신뢰성, 비용 효율적인 소프트웨어를 필요로 하나 PHP-FIG의 표준으로서는 개발할 수 없습니다.

잘못된 방법 : 종교적으로 PHP-FIG를 따릅니다. Thumbs down

보안 무시

프로그래머의 문제점은 너무 늦을때까지 프로그래머가 뭘 하는 지 말할 수 없다는 점입니다.

-- Seymour Cray on defprogramming.com

시큐어 코딩은 프로그램을 악의적이거나 장난스러운 사람들, 혹은 다른 프로그램들의 공격을 방어하는 습관입니다. 시큐어 코딩은 데이터 도난 혹은 손상으로부터 보호합니다. 추가적으로 안전하지 않은 프로그램은 공격자가 서버, 사용자 신원, 혹은 부정적인 영향을 미칠 수 있는 어떤 것들에 접근할 수 있게 해서 단 한명의 유저가 수천명의 사용자에게 비밀 일부 유출 , 서비스 손실, 혹은 시스템 손상을 가져올 수 있게 합니다.

모든 컴퓨터 프로그램은 보안 공격의 잠재적인 대상입니다. 공격자는 응용 프로그램에서 보안 취약점을 찾으려고 시도합니다. 그런 다음 이 취약점을 사용하여 비밀을 훔치고 프로그램과 데이터를 손상 시키며 서버와 네트워크를 제어하려고 시도합니다. 고객의 재산과 명성이 위태로워집니다.

보안은 소프트웨어에 추가 할 수있는 것이 아닙니다!

안전하지 않은 어플리케이션을 보호하기 위해 광범위한 재설계가 필요할 수 있습니다. 소프트웨어에 대한 위협의 특성을 구별하고 어플리케이션 계획 및 개발 단계에서 시큐어 코딩 방법을 함께 고려해야 합니다.

공격자의 관심이 점점 (데스크탑에서) 웹 어플리케이션으로 옮겨가므로 보안적으로 안전한 소프트웨어 리소스를 확보하는 것이 더욱 중요해졌습니다. 2009 SANS 연구에 따르면 인터넷에서 찾아낸 총 공격 중 60%가 웹 어플리케이션을 공격하는 것이었습니다.

PHP는 동시에 프로그래밍 언어와 웹 프레임 워크라는 점에서 특이합니다. 즉 PHP에는 웹을 위한 내장 기능이 언어 자체에 내장되어 있고, 이는 안전하지 않은 코드를 작성하기가 매우 쉬운 결과로 나타납니다.

보안은 기본

복잡성을 걷어내세요. 개발자의 생명을 갉아먹고 제품을 계획, 빌드 혹은 테스트하기 어렵게 만들고, 보안문제가 발생하며 사용자 및 관리자의 불만을 유발합니다.

-- Ray Ozzie

적절한 보안 요구사항을 포함해서 어플리케이션을 설계하고 구현하려면 시큐어 코딩을 사용하고, 보안 위험은 매일매일 작업할 때, 생각할 때, 개발 절차 내에 녹아들어가야 합니다.

일반적으로 소프트웨어 개발이 끝난 후 보안 문제를 해결하는 것보다 처음부터 시큐어 소프트웨어를 만드는 것이 더 저렴합니다. 보안 위반 관련 비용을 제외하고도요.

잘못된 방법 : 보안 소프트웨어를 기본으로 개발하지 않습니다. Thumbs down

자주하는 질문

작성된 문서를 오해하기 쉬우므로 몇 가지 문제를 명확하게 설명하겠습니다.

Q: 이 사이트의 요점은 무엇이며 왜 대립 접근 방식입니까?

A: 현재에 관행과 극단적인 견해애 대해 토론과 생각을 이끌어내기 위해서입니다.

Q: 객체 지향 프로그래밍이 나쁘거나 틀렸다고 말하는 건가요?

A: 물론 아닙니다! 우리는 문제를 해결하는 데 무조건적으로 객체 지향만을 생각하고 사용하는 것이 나쁘다고 말하고 있습니다. 이분법적인 논리가 아닙니다.

하나의 어플리케이션도 내에서도 서로 다른 문제가 존재합니다. 다중 패러다임은 때로는 최상의 솔루션이며, 모두 해결하려는 문제가 무언지에 달려 있습니다.

특정 문제에 꼭 맞지 않는 해결책을 사용하면 문제가 발생합니다.

Q: 모든 프레임워크가 나쁘다는 말입니까?

A: 특정 프레임워크를 판단하려고 하지 않습니다. 우리는 PHP 위 (추상화 계층) 에서 프레임워크를 항상 사용해야 하는지에 대해 다루고 있습니다.

Q: 프레임 워크가 빠르게 작동하고 실행된다면 왜 그렇게 나쁜가요?

A: 만약 상황과 장기적으로 어떤 영향을 끼치는지 분석한 후에 "빠르게 작동하고 실행하는 것"이 유일한 문제라면 그건 나쁘지 않은 선택입니다. 하지만 프로그래밍 혹은 소프트웨어 개발에서 그런식의 (누르기만 하면 해결되는) 포인트 앤 클릭 방식의 해결책은 찾기 어렵습니다.

빠르게 작동하고 실행되는 것은 소프트웨어 설계가 아닙니다. 그건 눈 앞에 닥친 문제를 분석하지 않았다는 뜻이며 그 선택이 장기적으로 어떤 시사점을 주는지 이해하지 못하고 있다는 뜻입니다.

Q: 써드파티 패키지가 잘못되었다고 말하는 건가요?

A: 아니요. 다른 사람이 만든 라이브러리 사용을 장려하고 있습니다. 어떤 제한이나 제약을 가하지 않고 자신의 프로젝트에 쉽게 통합할 수 있는 코드는 훌륭합니다!

Q: 누구세요?

A: 이 웹 사이트는 PHP 커뮤니티의 아이디어와 극단주의에 관한 것이며 개인의 명성이나 명예를 얻기 위한 것이 아닙니다. 이름을 지정하면 사람들이 웹사이트가 아니라 개인에게 집중하게 됩니다. 아이디어에 계속 집중하십시오.

Q: 어떤 소프트웨어 개발을 해 본 적이 있으신가요?

A: 이 웹 사이트에 표현 된 아이디어, 생각 및 결론은 많은 경험이 필요하지 않습니다. 많은 사람들이 이 주제에 대해 말하고 있기 때문에 조금만 주요 주제에 주목하면 됩니다.

더 읽어보기

  • 아래 링크는 모두 영어로 되어 있습니다.
  • 직접 읽어보고 느끼는 것이 나을 것 같아 설명은 일부러 번역하지 않았습니다.

PHP The Wrong Way on Hacker News : 해커뉴스에서 PHP The Wrong Way 를 논함

Why bad scientific code beats code following "best practices" : 잘못된 과학 코드가 "모범 사례"에 따라 코드를 능가하는 이유

How to program without OOP : OOP없이 프로그래밍하는 방법

Coders at work - Reflections on the Craft of Programming : 일할 떄의 코더 - 프로그래밍 기술에 대한 고찰

The traits of a proficient programmer : 숙련된 프로그래머의 특성

OWASP Secure Coding Guidelines : OWASP 보안 코딩 지침

Security by Design Principles : 디자인 원칙 별 보안

Survive The Deep End: PHP Security : 깊은 곳에서 살아남기 : PHP 보안

Refactoring Improving the Design of Existing Code : 기존 코드의 디자인을 개선하는 리팩토링

The Practice of Programming : 프로그래밍 실습

The pragmatic programmer : 실용적인 프로그래머

Understanding programming languages : 프로그래밍 언어 이해

기여하기

GitHub 에서 기여해 주세요.

  • Clone 하고 수정하세요.
  • Pull Request 를 보내주세요.

_sections/LANGUAGE_ 디렉토리에 섹션을 추가하거나 기존 섹션을 수정해 주세요.

한국어 기여하기

Php The Wrong Way 한국어 GitHub 에서 기여해 주세요.

  • Clone 하고 수정하세요.
  • Pull Request 를 보내주세요.

results matching ""

    No results matching ""