웹 개발의 중대한 실수

이 기사에서는 특히 중대형 프로젝트를 처리할 때 PHP 프로그래머가 웹 개발에서 흔히 간과하는 몇 가지 주요 실수를 요약합니다. 대표적인 오류로는 다양한 개발 환경을 구분하지 못하는 것, 캐시와 백업을 사용하지 못하는 것 등이 있습니다.

다음은 PHP를 예로 들어 설명하고 있지만 핵심 아이디어는 모든 웹 프로그래머에게 적용됩니다.

애플리케이션 수준 오류

1. 개발 단계에서는 오류 보고가 꺼집니다

유일하게 묻고 싶은 것은: 왜? 개발하는 동안 오류 보고를 꺼야 하는 이유는 무엇입니까?

PHP에는 다양한 수준의 오류 보고 기능이 있으며 개발 단계에서 이 기능을 모두 활성화해야 합니다.

오류가 발생하지 않을 것이라고 생각한다면 프로그램을 이상화하는 것입니다. 현실 세계에서는 오류가 불가피합니다. error_reporting과 display_error는 완전히 다른 두 가지 방법입니다. error_reporting()은 오류 수준을 설정하고, display_errors는 오류 메시지를 출력할지 여부를 설정합니다.

개발 단계에서는 오류 보고 수준을 다음 설정과 같이 가장 높은 수준으로 설정해야 합니다: error_reporting(E_ALL); 및 ini_set('display_errors', true);

2. 오류 범람

앞서 언급한 것과는 달리 많은 프로그래머는 오류를 없애는 것을 좋아합니다. 오류가 발생한다는 것을 알지만 오류를 숨기면 일찍 집에 가서 잠을 잘 수 있습니다. 앞으로 더 심각한 실수가 일어날 것이라는 것을 알고 있습니다.

3. 코드 어디에도 사용 로그가 없습니다

소프트웨어 개발 초기에는 사용 로그를 염두에 두어야 하며, 끝까지 로그 기능을 보충할 수 없습니다. 프로젝트의. 많은 프로그래머가 로그를 기록하기 위해 이런저런 방법을 사용하겠지만 실제로 로그를 사용하여 아무도 확인하지 않는 로그 시스템의 용도는 무엇입니까?

4. 캐시를 사용하지 않습니다

애플리케이션 시스템에서는 서버 측, 애플리케이션 측, 데이터베이스 측 등 여러 시스템 수준에서 캐시를 사용할 수 있습니다. 로깅과 마찬가지로 캐싱도 처음부터 시스템에 적용해야 합니다. 개발 중에는 캐싱을 비활성화하고 제품 출시 후에는 캐싱을 활성화할 수 있습니다.

5. 모범 사례와 디자인 패턴을 버리는

자체 비밀번호 암호화 알고리즘을 사용하는 사람을 몇 명이나 보셨나요? 안타깝지만, 그들 중에는 자신이 그것에 대해 더 잘 알 것이라고 생각하는 사람들이 많습니다.

전임자들이 만든 모범 사례와 디자인 패턴은 스스로 바퀴를 재발명하는 것보다 더 쉽고 효과적입니다. 우리 개발자는 이러한 디자인 패턴에 능숙하고 이를 프로젝트에 합리적으로 적용하기만 하면 됩니다. 일부 암호화 알고리즘과 같이 사용됩니다.

6. 자동화된 테스트를 사용하지 않습니다.

테스트는 로그와 마찬가지로 모든 웹 프로젝트에서 사용됩니다. 아무도 관리하고 사용하지 않으면 테스트는 쓸모가 없습니다.

테스트 프로젝트를 실행하는 것은 지루한 작업입니다. 다행히 자동화된 테스트를 수행하는 데 도움이 되는 일련의 도구가 있습니다. PHP 개발에는 사용하기 매우 편리한 Jenkins라는 좋은 테스트 도구가 있습니다.

7. 코드 리뷰가 없습니다

팀으로 작업하는 것은 매우 큰 도전입니다. 멤버마다 작업 습관과 방법이 다르기 때문에 좋은 사양이 없으면 프로젝트 개발이 어렵습니다. 많은 우회로가 필요할 것입니다.

팀의 모든 구성원은 단위 테스트처럼 서로의 코드를 검토해야 프로젝트가 더욱 깔끔하고 일관되게 됩니다.

8. 이상적인 상황만 고려하는 프로그래밍

자신의 코드나 다른 사람의 코드가 고객에게 전달된 후 문제나 혼란을 겪은 적이 있습니까? 물론 나는 그러지 않았다.

이러한 상황은 개발자가 게으르고 이상적인 상황만 고려하기 때문에 자주 발생하며, 이로 인해 데이터베이스 충돌, PHP 치명적인 오류 또는 서버 해킹이 발생할 수 있습니다. 프로그래머는 코드를 작성할 때 최선의 시나리오뿐만 아니라 최악의 시나리오도 고려해야 합니다. 포괄적으로 생각해야만 코드가 모든 상황을 다룰 수 있습니다.

9. 객체지향 프로그래밍 아이디어를 올바르게 적용하지 못함

대부분의 PHP 초보자는 객체지향 아이디어를 처음에는 이해하기 어렵기 때문에 코드에 사용하지 않습니다.

물론 객체지향 개념은 단순히 몇몇 클래스를 함께 구성하는 것이 아닙니다.

객체, 속성, 메서드, 상속 및 캡슐화는 OOP의 가장 기본적인 개념입니다. 개발자가 객체 지향 디자인 패턴을 올바르게 사용하면 더 깔끔하고 확장 가능한 코드를 작성할 수 있습니다.

10. "즉석" 프로그래밍

대부분의 개발자는 "빠르게, 고객이 최대한 빨리 실행할 수 있는 새로운 기능이 필요합니다."라는 상황에 직면하게 됩니다. 소스 코드를 다운로드한 다음 실행 중인 서버에 직접 업로드합니다. 이 프로그래밍 방법을 "온더플라이(On-The-Fly)" 프로그래밍이라고 합니다.

소프트웨어, 특히 중대형 프로젝트를 개발할 때 분석, 프로그래밍, 릴리스에 대한 워크플로를 따라야 합니다. 이렇게 하면 향후 소프트웨어 버그가 크게 줄어들 것입니다. 이 "비행 모드"는 권장되지 않습니다.

데이터베이스 수준 오류

11. 데이터베이스 읽기와 쓰기를 분리하지 못함

복잡한 시스템을 오랫동안 운영하기 위해서는 프로그래머라면 누구나 데이터베이스의 신뢰성을 고려해야 합니다. 시스템 확장성, 트래픽 양이 많지 않기 때문에 시스템은 99% 확장을 고려할 필요가 없습니다.

데이터베이스 읽기와 쓰기를 분리해야 하는 이유는 무엇인가요?

모든 시스템에서 데이터베이스는 대규모 트래픽의 영향으로 가장 먼저 병목 현상이 발생하기 마련입니다. 그래서 대부분의 경우 트래픽을 분산시키기 위해 여러 데이터베이스를 사용하고, 개발자들은 마스터-슬레이브 모델이나 마스터-마스터 모델을 사용하는 경우가 많습니다. 마스터-슬레이브는 가장 널리 사용되는 데이터베이스 압력 공유 모드입니다. 지정된 선택 문을 각 슬레이브 서버로 라우팅하므로 마스터 서버에 대한 압력이 많이 줄어듭니다.

12. 코드는 하나의 데이터베이스에만 연결할 수 있습니다.

이전 오류와 매우 유사하지만 개발자는 어떤 이유로 여러 데이터베이스에 연결해야 하는 경우가 있습니다. - 로그, 활동 정보 스트림, 실시간 데이터 분석 등의 로드 데이터를 서로 다른 데이터베이스에 배치하여 기본 데이터베이스에 대한 부담을 완화합니다.

13. 데이터베이스 취약점 탐지 실패

데이터베이스 취약점을 탐지하지 못한다면 대부분의 해커들에게 서버 문을 열어주는 셈이다.

많은 취약점 중에서 데이터베이스 취약점이 가장 취약하며, 가장 흔한 취약점은 SQL 인젝션입니다. 따라서 정기적으로 데이터베이스 취약점 탐지를 수행하는 것이 여전히 필요합니다.

14. 데이터 테이블에는 인덱스가 없습니다.

인덱스는 데이터 테이블에서 매우 중요한 역할을 합니다. 적절한 인덱스는 각 테이블의 성능을 향상시킬 수 있습니다. 언제 생성할지.

15. 트랜잭션 메커니즘을 사용하지 않습니다.

데이터 무결성은 웹 시스템에 매우 중요합니다. 데이터 일관성에 오류가 발생하면 전체 시스템이 붕괴되어 복구가 어렵습니다. 데이터베이스 트랜잭션 메커니즘을 적절하게 사용하면 이 문제를 효과적으로 해결할 수 있습니다. 예를 들어 사용자 데이터를 저장하려는 경우 table1에는 이메일, 사용자 이름, 비밀번호가 있고 table2에는 이름, 성, 성별 나이가 있습니다. 트랜잭션을 사용하여 두 테이블을 업데이트할 때 데이터가 동시에 업데이트되거나 동시에 업데이트되지 않도록 할 수 있습니다.

16. 민감한 데이터는 암호화하지 않습니다

데이터베이스의 민감한 정보를 암호화하지 않거나, 간단한 알고리즘으로 암호화하면 2014년에는 반드시 마주하게 될 문제입니다. 문제는 해커가 데이터베이스에 침입하면 사용자의 비밀번호나 기타 중요한 정보가 한눈에 보인다는 것입니다.

PHP5.5는 다음과 같이 사용되는 해시 암호화 방법을 제공합니다.

$hash = password_hash( $password, PASSWORD_BCRYPT );

17. 백업 없음

이런 경우에는 아래 그림을 참조하세요. 상황에 따라 백업이 없으면 모든 것이 끝나게 됩니다.

18. 모니터링이 없으면

모니터링이 없으면 다음에 어떤 일이 일어날지 알 수 없습니다.

모니터링을 할 수 있는 사람 수는 다음과 같습니다. 이 애플리케이션 서비스에 직접 액세스하시겠습니까?

서버가 부하가 높은 상태에서 실행되고 있나요?

다른 데이터베이스 서버로 시스템을 확장해야 합니까?

지원시스템의 실패지점은 어디인가요?

현재 시스템이 오프라인인가요?