백엔드 개발: 안정적인 인터페이스를 작성하는 방법

졸업하고 현재 회사에 입사한 지 거의 1년이 되었습니다. 저는 백엔드 개발자로서 두 단계에 걸쳐 부서의 새로운 프로젝트의 개발 및 출시 과정에 완전히 참여했습니다. 괴로운 것은 출시 전후의 버그 수정 단계입니다. 온갖 갑작스럽고 설명할 수 없는 버그에 직면하면 어지럽고 조급해지며, 고치면 할수록 혼란스러워지는 경우가 많습니다. 실험적인 버그 수정, 하나의 버그를 수정한 후 두 개의 버그가 나타납니다. 왜 항상 버그를 수정하려고 합니까? 처음 온라인에 접속하기 전에는 왜 그렇게 많은 버그가 있습니까?

며칠 전에 Douban 기사를 읽었습니다. 요약되지 않은 것은 경험이 아니라 단지 경험일 뿐입니다. 프로그래머는 사업이 오면 코드를 작성할 수 없고, 버그가 있을 때 버그를 수정할 수는 없습니다. 이렇게 하면 기술 개선이 어려워지므로 매번 버그가 이렇게 많은 것은 당연합니다. 어떤 개발자들은 수년 동안 일해왔지만 아직도 인터페이스 수가 500개에 달할 때가 있습니다. 초기에는 코드를 작성하고 후반에는 버그를 수정하느라 바쁘기 때문이죠.

첫 번째 단계부터 비즈니스와 프레임워크에 익숙해졌고 두 번째 단계에서는 작은 모듈을 담당하며 데이터베이스와 프로그램을 설계하려고 했습니다. 어제는 실수를 했습니다. 저도 막연하게 느꼈던 부분이 있어서 간단하지만 여러분과 여러분의 독자들에게 조금이나마 영감을 줄 수 있을 것 같아 정리해보겠습니다. (이 글은 기본적인 수준의 간단한 버그에만 초점을 맞추고, 높은 동시성, 대용량 데이터와 같은 복잡한 문제는 다루지 않습니다.)

1. 인터페이스에는 왜 버그가 있나요?

내가 열심히 작성했던 인터페이스는 테스트 해보니 잘 되었는데, 다른 사람이 조정하자마자 왜 문제가 발생하는 걸까요? ? (여기에 이모티콘이 있을 테니 알아서 판단하세요.) 물론 운영 환경의 문제일 수도 있지만, 프로그램이 서버에 획일적으로 배포되는 것은 일반적으로 설계자나 운영 및 유지 관리의 책임입니다. .프로그래밍 언어나 운영체제의 문제는 모두 지금은 우리가 작성한 버그만 고려합니다.

사실 실행 중인 프로그램에는 리소스(CPU, 메모리 등) + 알고리즘(프로그램 실행 프로세스) + 데이터(사용자 입력, 데이터베이스, 타사 인터페이스 등)의 세 가지만 포함됩니다. 일반적으로 우리는 리소스를 신뢰할 수 있다고 생각하며, 신뢰할 수 없는 알고리즘이나 데이터 이상으로 인해 버그가 주로 발생합니다.

한 단계 더 나아가 기계는 0/1에 따라 엄격하게 명령을 실행합니다. 지난 번에는 정상적으로 실행된 알고리즘이 이번에는 왜 실패했을까요? 본질적으로 데이터가 변경되어 알고리즘이 이러한 상황을 처리하지 못했기 때문입니다. 따라서 인터페이스의 안정성을 보장하기 위해 우리는 데이터의 신뢰성 보장과 알고리즘의 견고성 확보라는 두 가지 측면을 주로 고려합니다. 알고리즘의 견고성은 데이터의 모든 상황에서 두 가지가 분리될 수 없다는 점을 고려하는 것입니다.

2. 버그가 적은 인터페이스를 작성하는 방법은 무엇입니까?

앞서 분석했듯이 데이터 변경은 인터페이스 버그의 가장 일반적이고 필수적인 원인입니다. 그 중 사용자 입력은 데이터 변경의 주요 원인입니다. 프로그램에는 사용자 입력이 있어야 합니다. 그렇지 않으면 의미가 없습니다.

프로그래밍 세계에는 다음과 같은 유명한 말이 있습니다. 사용자 입력을 절대 믿지 마세요. 사용자가 이름을 기대하는 입력 상자에 무엇을 입력할지 결코 알 수 없습니다. 프런트 엔드가 필터링했다고 해서 안심하지 마십시오. 한편으로는 사용자가 크롤러 및 기타 수단을 사용하여 인터페이스에 직접 액세스할 수도 있습니다. 또한 통신 오류도 있습니다. 프런트 엔드에서 잘못된 인터페이스로 호출할 수 있으며 이 오류는 더 미묘할 수 있습니다.

첫 번째 제안: 형식과 내용을 포함하여 사용자 입력을 엄격하게 확인하세요.

기능이 정상이면 괜찮을 것이라고 생각하여 사용자 입력을 하나씩 확인하기에는 너무 게으른 사람들이 많다는 것을 알고 있습니다. 그러나 이로 인해 나중에 버그 수정에 더 많은 경험이 생기는 경우가 많습니다. 테스트 중에 버그가 보고되는 경우가 많습니다. 반복해서 확인한 결과 프런트 엔드가 잘못된 매개변수를 전달했거나 사용자 입력을 합리적으로 제한하지 않았음을 발견할 수 있습니다. 물론 매우 엄격하여 프런트 엔드에서 수정하도록 할 수도 있습니다. 하지만 이 프로세스는 이미 많은 시간과 에너지를 낭비했습니다. 처음에 직접 확인하고 적절한 오류 메시지를 반환하면 나중에 많은 에너지를 절약할 수 있습니다.

이것은 PHP와 같은 동적 언어의 경우 특히 그렇습니다. 예를 들어 Laravel 프레임워크를 사용할 때 먼저 모든 인터페이스 입구에서 $request->validate()를 사용하여 모든 입력 데이터의 형식을 확인합니다. 필요한 경우 코드를 작성합니다. 시간 범위, 요청한 데이터가 유효한지 등과 같은 입력 내용을 추가로 확인합니다.

두 번째 제안: 사용자의 번거로운 작업, 반복 제출, 지연된 제출을 고려하세요

반복 제출은 대부분의 백엔드가 생각할 수 있는 상황, 즉 인터페이스의 멱등성을 고려해야 하며 일부 리소스는 한 번만 작동할 수 있습니다. , 검증을 거쳐야 하는데, 실제로는 반복 제출뿐 아니라, 동일한 이벤트를 두 사람이 반복적으로 처리하는 상황도 발생합니다.

지연된 제출에 대해서는 실제로 테스터가 버그를 보고한 후에야 깨닫게 된 문제 패턴이었습니다. 예를 들어, get 인터페이스를 통해 사용자에게 특정 리소스를 반환하는 경우 사용자는 post 인터페이스를 통해 리소스 ID를 반환하고 수정 사항을 제출할 수 있습니다. ID는 합법적이므로 엄격한 폐쇄 루프를 형성하는 것으로 보입니다. 그러나 사용자가 이 페이지에 머물며 제출을 지연하는 경우 해당 리소스가 이 기간 동안 만료되었거나 리소스가 다른 사람에 의해 수정되어 사용자가 성공적으로 수정한 것일 수 있습니다. 버그. 실제로 좀 더 생각해 보면 이는 높은 동시성 시나리오의 리소스 오류와 유사하다는 것을 알 수 있습니다.

세 번째 제안: 데이터베이스 및 타사 인터페이스의 반환 데이터를 확인하세요

사용자 입력 외에도 일반적인 데이터 소스에는 데이터베이스 및 타사 인터페이스가 포함됩니다. 상대적으로 말하자면, 이러한 데이터 인터페이스는 훨씬 더 안정적일 것이며 콘텐츠 형식은 더욱 표준화될 것입니다. 그러나 인터페이스의 안정성을 위해서는 몇 가지 테스트를 수행하는 것이 가장 좋습니다. 예를 들어 데이터가 비어 있는 경우가 많으면 프로그램 실행을 즉시 종료하고 해당 정보를 폐기해야 합니다.

그런데, 데이터베이스의 경우에도 버그가 발생했는데, 이는 마스터-슬레이브 지연으로 인한 데이터 업데이트 문제입니다. 경험이 부족해서 이런 종류의 작업을 잘 못합니다. 문제가 있어서 더 이상 글을 쓰지 않겠습니다.

네 번째 제안: 프로그램 알고리즘은 비정상적인 상황을 최대한 커버합니다.

이것은 실제로 처음 세 가지에 대한 보충이며 다소 불법적입니다. 사용자 입력에 따라 프로그램을 직접 종료하고 오류 메시지를 반환할 수 있지만 경우에 따라 프로그램을 계속 실행하고 특수 처리를 거쳐야 할 수도 있습니다. 이러한 상황에서는 처음부터 최대한 철저하게 처리해야 합니다. 나중에는 버그가 줄어들고 유지 관리가 더 쉬워집니다.

3. 더 효율적인 인터페이스 작성 방법

마지막으로 인터페이스 효율성과 코드 품질에 대해 조금 적어보겠습니다.

1. 인터페이스 효율성에 영향을 미치는 주요 요인은 데이터베이스 운영
제한된 경험에 따르면 인터페이스 시간이 긴 것은 기본적으로 불합리한 데이터베이스 운영 때문입니다. 대부분의 비즈니스 코드에는 성능 문제가 없습니다. for 루프에서 데이터베이스를 쿼리하는 코드를 많이 보았지만, 먼저 모든 데이터를 한 번에 꺼낸 다음 하나씩 처리하는 것은 피해야 합니다. 예를 들어, 프레임워크 계층에서 모든 데이터베이스 작업을 기록합니다. 인터페이스를 디버깅할 때 모든 데이터베이스 작업과 해당 시간 소비를 볼 수 있으며 병합된 쿼리는 그에 따라 최적화되어야 합니다. .

2. Exception의 합리적인 사용, 로그

이 글은 주로 PHP 언어에 대한 것입니다. 반환에 의존 코드가 복잡하고 호출 수준이 깊을 때 프로그램을 중단하고 오류 정보를 전송하는 것은 유지하기가 매우 어렵습니다. 이는 예외 메커니즘보다 훨씬 덜 직관적이고 편리합니다. 또한 나중에 문제를 쉽게 발견하고 디버깅할 수 있도록 중요한 정보를 로그에 기록해야 하며, 이는 무죄를 입증하는 데에도 사용될 수 있습니다.

3. 코드는 합리적으로 분할하고 추상화해야 합니다.

코드를 복사하여 붙여넣지 말고, 반복되는 기능은 분리해야 합니다. 변경 및 확장을 설계할 때 합리적으로 고려합니다. 복잡한 기능을 한꺼번에 구현하는 대신 작고 집중된 기능을 작성하는 방식으로 작성된 코드는 수정, 테스트 및 확장이 쉽습니다. 저도 이 일을 잘 못합니다. 온라인에 접속한 후에는 코드가 모두 지저분하고 유지 관리가 어렵습니다. 다음에는 더 많이 생각하고 더 많이 연습해야 합니다.