최근에는 수많은 레거시 PHP 애플리케이션을 작업 할 기회가 있었습니다.
수정해야하는 일반적인 안티 패턴을 발견했습니다. 이 기사는 이전 PHP 애플리케이션을 <여기에 반짝이는 프레임 워크 이름 삽입>으로 다시 작성하는 것이 아니라, 더 쉽게 유지 보수하고 작업하는 데 번거롭지 않게 만드는 방법에 대한 것입니다.
https://adrien.poupa.fr/modernizing-a-legacy-php-application/
반 패턴 # 1 : 코드의 자격 증명
이것은 확실히 내가 본 가장 일반적인 최악의 패턴입니다. 많은 프로젝트에는 버전 코드에 데이터베이스 사용자 이름 및 비밀번호와 같은 민감한 정보가 있습니다.
코드가 특정 환경에 연결되어 있고 코드에 대한 액세스 권한이 있는 모든 사용자가 일반적으로 프로덕션 환경에 대한 자격 증명을 볼 수 있기 때문에 로컬 설정을 만들 수 없기 때문에 이는 분명히 나쁜 습관입니다.
이 문제를 해결하기 위해 모든 응용 프로그램에서 작동하는 내가 선호하는 방법은 vlucas의 phpdotenv 패키지를 설치하는 것입니다.이 패키지를 사용하면 환경 파일을 만들고 환경 수퍼 변수를 사용하여 변수에 액세스 할 수 있습니다.
즉, 버전이 지정되고 자격 증명을 저장할 .env 파일의 템플릿 역할을 할 .env.example 파일이라는 두 개의 파일을 만듭니다. .env는 버전이 지정되지 않으므로 .env 파일을 .gitignore에 추가하십시오. 공식 문서는 이것을 잘 설명합니다.
.env.example에 자격 증명이 나열됩니다.
DB_HOST= DB_DATABASE= DB_USERNAME= DB_PASSWORD=
.env에는 자격 증명이 있습니다.
DB_HOST=localhost DB_DATABASE=mydb DB_USERNAME=root DB_PASSWORD=root
공통 파일에서 .env 파일을 로드합니다.
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__); $dotenv->load();
그런 다음 예를 들어 $_ENV ['DB_HOST']를 사용하여 자격 증명에 액세스 할 수 있습니다.
프로덕션 상태로 패키지를 사용하지 않는 것이 좋습니다. 다음 중 하나를 사용하는 것이 좋습니다.
자격 증명이 포함 된 파일은 여기에 표시된 대로 Git 기록에서 제거 할 수 있습니다.
반 패턴 # 2 : Composer를 사용하지 않음
예전에는 PHPMailer와 같은 큰 라이브러리가 있는 lib 폴더를 사용하는 것이 매우 일반적이라는 것을 알았습니다. 이것은 버전 관리와 관련하여 큰 문제가 아니므로 이러한 종속성은 Composer로 관리해야 합니다. 이렇게 하면 실행 중인 특정 패키지의 버전을 매우 쉽게 확인하고 필요에 따라 업데이트 할 수 있습니다.
그러니 계속해서 작성을 시작하려면 모든 것이 필요합니다.
안티 패턴 # 3 : 로컬 없음
내가 작업 한 대부분의 애플리케이션에는 프로덕션 환경이 하나뿐이었습니다.
그러나 이제 Anti-pattern #1을 수정 했으므로 로컬을 쉽게 설정할 수 있습니다. 업로드 경로와 같은 하드 코딩 된 구성이 여전히 있을 수 있지만 이제 .env로 이동할 수 있습니다.
새로운 로컬 환경을 만들기 위해 당연히 Docker를 사용합니다. 설치를 원하지 않거나 설치할 수 없는 이전 PHP 버전을 자주 사용하기 때문에 레거시 프로젝트에 특히 적합합니다.
PHPDocker와 같은 서비스를 사용하거나 가벼운 docker-compose.yml 파일을 사용할 수 있습니다.
반 패턴 # 4 : 공용 폴더를 사용하지 않음
대부분의 오래된 프로젝트는 루트에서 액세스 할 수 있습니다. 즉, 프로젝트의 루트에 저장된 모든 파일을 공개적으로 읽을 수 있습니다. 이는 악의적 인 사용자 (예 : kiddies 스크립트)가 포함 된 모든 파일에서 스크립트에 직접 액세스하는 경우 종료를 정의하지 않았을 수 있으므로 포함 된 파일에 직접 액세스하려고 할 때 특히 나쁩니다.
이는 벤더 폴더를 노출하는 것이 좋지 않기 때문에 .env 파일 또는 Composer를 사용하는 것과 분명히 호환되지 않습니다. 예,이를 가능하게 하는 조정이 있지만 가능하면 모든 클라이언트 지향 PHP 파일을 공용 폴더로 이동하고 웹 서버 구성을 변경하여 애플리케이션의 루트가되도록하십시오.
내 일반적인 응용 프로그램에서 다음을 갖게 됩니다.
반 패턴 # 5 : 노골적인 보안 문제
프레임 워크를 사용하지 않는 PHP 애플리케이션, 특히 오래된 애플리케이션은 다음과 같은 노골적인 보안 문제가 발생하기 쉽습니다.
// Password still in old hash: does not start with $ // Password is correct: convert it and log the user if (strpos($oldPasswordHash, '$') !== 0 && hash_equals($oldPasswordHash, sha1($clearPasswordInput))) { $newPasswordHash = password_hash($clearPasswordInput, PASSWORD_DEFAULT); // Update the password column // User logged in: return success } // Password already converted if (password_verify($clearPasswordInput, $currentPasswordHash)) { // User logged in: return success } // User not logged in: return failure
반 패턴 # 6 : 테스트 없음
이것은 레거시 앱에서 매우 일반적입니다. 전체 애플리케이션에 대한 단위 테스트 작성을 시작하는 것은 비현실적이라고 생각하지만 기능 테스트를 작성할 수 있습니다.
위의 이미지에 표시된 고수준 테스트는 애플리케이션의 후속 리팩토링으로 인해 문제가 발생하지 않도록 하는 데 도움이 됩니다. 예를 들어 브라우저를 시작하고 애플리케이션에 로깅 한 다음 결과 페이지에서 HTTP 성공 코드 및 / 또는 특정 성공 메시지를 예상하는 것처럼 간단 할 수 있습니다. PHPUnit을 사용하여 이를 수행하거나 Cypress와 같은 다른 도구 또는 codeception을 사용할 수 있습니다.
안티 패턴 # 7 : 잘못된 오류 처리
무언가가 고장 난 경우 (또는 가장 가능성이 높은 경우) 신속하게 인식하고 싶습니다. 하지만 대부분의 레거시 앱은 오류를 제대로 처리하지 못하며, 어떤 일이 있어도 계속되는 PHP의 용서에 의존합니다.
오류를 수정하기 위해 가능한 한 많은 오류를 포착하고 기록 할 수 있기를 원합니다. 주제에 대한 좋은 기사가 있습니다.
특정 예외를 throw하면 오류 위치를 더 쉽게 찾을 수 있습니다.
반 패턴 # 8 : 전역 변수
레거시 프로젝트를 수행 할 때까지 다시는 볼 수 없을 것이라고 생각했습니다. 그리고 그들은 코드의 동작을 예측할 수 없게 읽고 이해합니다. 결국 그들은 악합니다.
대신 의존성 주입을 사용하는 것이 좋습니다. 왜냐하면 어느 인스턴스가 어디에 사용되는지 제어 할 수 있기 때문입니다. Pimple과 같은 패키지가 작업을 잘 수행합니다.
다음에 개선 할 사항은 무엇입니까?
애플리케이션의 미래 또는 사용 가능한 예산에 따라 이를 개선하기 위해 몇 가지 추가 단계를 수행 할 수 있습니다.
첫째, 앱이 PHP의 고대 버전 (7 미만)에서 실행 중인 경우 업데이트를 고려해야 합니다. 대부분의 경우 정말 고통스럽지 않아야 하며, 가장 긴 작업은 아마도 응용 프로그램에서 사용하는 모든 mysql_ 호출을 제거하는 것입니다. 빠르고 더러운 수정을 위해 이 라이브러리와 같은 것을 사용할 수 있지만 가장 좋은 해결책은 모든 쿼리를 PDO에 다시 작성하여 매개 변수가 동시에 이스케이프되도록하는 것입니다.
앱이 MVC 패턴을 사용하지 않는 경우 (예 : 비즈니스 로직과 템플릿이 분리되어있는 경우) Smarty와 같은 템플릿 라이브러리 (PHP는 템플릿 언어이지만 최신 라이브러리가 훨씬 더 좋습니다)를 도입하는 것이 좋습니다. , 나뭇 가지 또는 블레이드.
마지막으로, 여유가 있다면 Laravel 또는 Symfony와 같은 최신 PHP 프레임 워크로 재 작성하는 것이 장기적으로 훨씬 좋습니다. 안전하고 정상적인 PHP 개발을 수행하는 데 필요한 모든 도구를 사용할 수 있습니다. 응용 프로그램의 크기에 따라 크기가 크면, 심하게 끝날 수 있는 (아마도) 빅뱅 재 작성을 피하기 위해 교 살자 패턴을 사용하는 것이 좋습니다. 이렇게 하면 현재 작업 중인 코드의 일부를 새 시스템으로 마이그레이션 하고 작업해야 할 때까지 이전 작업 중인 코드를 그대로 유지할 수 있습니다.
등록된 댓글이 없습니다.
