POKA 요크 - 과다 방어 프로그래밍으로 프로젝트를 절약합니다-PHP 튜토리얼-php.cn

제조 외에도 포카 요크는 소비자 전자 제품에 자주 사용됩니다. 예를 들어, SIM 카드는 비대칭 모양으로 인해 SIM 트레이에만 삽입 될 수 있습니다.

포카 요크가없는 하드웨어 예제는 PS/2 포트이며, 키보드 커넥터와 마우스 커넥터와 정확히 동일한 모양을 갖습니다. 색상 코드를 사용 하여만 구별 할 수 있으므로 실수로 커넥터를 교체하고 같은 방식으로 적합하므로 잘못된 포트에 쉽게 삽입 할 수 있습니다.

하드웨어에 사용되는 것 외에도 포카 요크의 개념을 프로그래밍에도 적용 할 수 있습니다. 아이디어는 코드의 공개 인터페이스를 가능한 한 이해하기 쉽고 코드를 잘못 사용 할 때 즉시 오류를 던지는 것입니다. 이것은 분명해 보이지만 실제로는 종종 이와 관련하여 결함이있는 코드를 만납니다. Poka Yoke - Saving Projects with Hyper-Defensive Programming 그러나 포카 요크는 의도적 인 학대를 예방하기위한 것이 아닙니다. 목표는 코드를 악의적 인 사용으로부터 보호하지 않고 예기치 않은 오류를 방지하는 것입니다. 누군가가 귀하의 코드에 액세스 할 수있는 한, 실제로 원하는 경우 보안 조치를 우회 할 수 있습니다.

코드를 오류 방지하기 위해 어떤 특정 조치를 취할 수 있는지 논의하기 전에 Poka 요크 메커니즘이 일반적으로 두 가지 범주로 나눌 수 있음을 아는 것이 중요합니다.

오류 방지 오류 감지

오류 방지 기술은 가능한 빨리 오류를 감지하는 데 도움이됩니다. 그들은 인터페이스와 동작을 가능한 한 간단하고 간단하게 만들어 아무도 실수로 우리의 코드를 잘못 사용할 수 없도록 설계되었습니다. SIM 카드의 예를 생각해보십시오.

반면에 오류 감지 메커니즘은 코드 외부에 존재합니다. 그들은 잠재적 오류에 대한 응용 프로그램을 모니터링하고 경고합니다. 예를 들어 PS/2 포트에 연결된 장치가 올바른 유형의 소프트웨어인지 여부를 감지하는 것이며, 그렇지 않은 경우 작동하지 않는 이유에 대한 경고가 표시됩니다. 이 특정 소프트웨어는 연결할 때 커넥터가 상호 교환 될 수 있으므로 오류를 방지 할 수 없지만 오류를 감지하고 오류를 수정할 수 있도록 경고 할 수 있습니다.

이 기사의 나머지 부분에서는 응용 프로그램에서 오류 예방 및 오류 감지를 구현하는 데 사용할 수있는 몇 가지 방법을 살펴 봅니다. 그러나이 목록은 시작점 일뿐입니다. 특정 애플리케이션에 따라 코드를보다 오류 방지 할 수있는 추가 조치가있을 수 있습니다. 또한, 포카 요크의 선불 비용을 기억하고 특정 프로젝트에 가치가 있는지 확인하는 것이 중요합니다. 응용 프로그램의 복잡성과 크기에 따라 잠재적 오류 비용에 비해 일부 측정 값이 너무 비쌀 수 있습니다. 따라서 귀하와 귀하의 팀은 귀하가 취할 수있는 가장 적합한 조치를 결정해야합니다.

오류 방지 예

이전에 PHP 5에서 유형 힌트라고 불리는 유형 선언은 PHP 7에서 오류 방지 기능 및 메소드 서명을 시작하는 쉬운 방법입니다.

함수 매개 변수에 특정 유형을 할당하여 함수를 호출 할 때 매개 변수 순서를 난독 화하는 것이 더 어려워집니다.

예를 들어 사용자에게 보내고 싶은이 알림을 살펴 보겠습니다.

유형 선언이 없으면 잘못된 유형의 변수를 쉽게 주입하여 응용 프로그램을 중단 할 수 있습니다. 예를 들어, $ userID가 문자열이어야한다고 가정 할 수 있으며 실제로 정수가되어야 할 수도 있습니다.

잘못된 유형을 주입하면 응용 프로그램이 실제로 알림을 처리하려고 할 때까지 오류가 감지되지 않을 수 있습니다. 그때까지 우리는 예상치 못한 유형에 대한 이해할 수없는 오류 메시지를 얻을 수 있지만 정수 대신 문자열을 주입하는 코드를 즉시 가리키는 것은 없습니다.

<code class="language-php"><?php
class Notification {
    private $userId;
    private $subject;
    private $message;

    public function __construct(
        $userId,
        $subject,
        $message
    ) {
        $this->userId = $userId;
        $this->subject = $subject;
        $this->message = $message;
    }

    public function getUserId()
    {
        return $this->userId;
    }

    public function getSubject()
    {
        return $this->subject;
    }

    public function getMessage()
    {
        return $this->message;
    }
}
</code>

따라서 따라서, 개발 중에 가능한 한 빨리 이러한 오류를 감지 할 수 있도록 적용이 가능한 빨리 충돌하도록 강제하는 것이 일반적으로 더 흥미 롭습니다.

이 경우 일부 유형 선언을 추가 할 수 있으며 매개 변수 유형을 난독 화하면 PHP가 즉시 중지되고 치명적인 오류를 경고합니다.

그러나 기본적으로 PHP는 예상 유형에 잘못된 매개 변수를 캐스팅하려고합니다. 이를 방지하기 위해서는 오류가 발생하면 실제로 치명적인 오류를받을 수 있도록 strict_types를 활성화하는 것이 중요합니다. 따라서 스칼라 유형 선언은 이상적인 포카 요크 형태는 아니지만 오류를 줄이는 것이 좋습니다. strict_types가 비활성화 되더라도 여전히 예상 유형의 매개 변수를 표시 할 수 있습니다.

또한 메소드의 리턴 유형을 선언합니다. 이를 통해 특정 함수를 호출 할 때 기대할 수있는 값을 쉽게 결정할 수 있습니다.

운영 정의 된 반환 유형은 또한 반환 값을 처리 할 때 많은 수의 스위치 문을 사용하지 않도록 도와줍니다. 우리의 메소드는 명시 적으로 선언 된 반환 유형없이 다양한 유형을 반환 할 수 있기 때문입니다. 따라서 우리의 방법을 사용하는 사람들은 특정 경우에 실제로 반환되는 유형을 확인해야합니다. 이 스위치 명령문은 분명히 잊혀지고 감지 할 수없는 오류로 이어집니다. 반환 유형을 사용하면 이러한 오류가 크게 줄어 듭니다.

value 객체 스칼라 유형 힌트를 쉽게 해결할 수없는 한 가지 문제는 여러 함수 매개 변수를 갖는 것이 해당 매개 변수의 순서를 혼동 할 수 있다는 것입니다.

<code class="language-php"><?php
declare(strict_types=1);

class Notification {
    private $userId;
    private $subject;
    private $message;

    public function __construct(
        int $userId,
        string $subject,
        string $message
    ) {
        $this->userId = $userId;
        $this->subject = $subject;
        $this->message = $message;
    }

    public function getUserId() : int
    {
        return $this->userId;
    }

    public function getSubject() : string
    {
        return $this->subject;
    }

    public function getMessage() : string
    {
        return $this->message;
    }
}
</code>

모든 매개 변수가 다른 스칼라 유형을 가질 때 매개 변수 순서를 난독 화 할 때 PHP는 경고 할 수 있지만 대부분의 경우 동일한 유형의 매개 변수가있을 수 있습니다.

이 문제를 해결하기 위해 값 객체로 매개 변수를 랩핑 할 수 있습니다.

우리의 매개 변수는 이제 매우 구체적인 유형을 가지고 있기 때문에 혼동하는 것은 거의 불가능합니다.

스칼라 유형 선언 대신 값 객체를 사용하는 또 다른 장점은 더 이상 각 파일에서 strict_types를 활성화 할 필요가 없다는 것입니다. 우리가 그것을 기억할 필요가 없다면, 실수로 그것을 잊을 수는 없습니다.

검증

우리는 userID를 입력으로 얻을 때 마다이 규칙을 분명히 확인할 수 있지만 반면에, 한 곳에서 쉽게 잊어 버릴 수도 있습니다.

이 오류로 인해 응용 프로그램의 다른 계층에서 실제 오류가 발생하더라도 오류 메시지는 실제로 발생한 오류가 실제로 발생하고 디버그하기 어려운 오류를 명확하게 나타내지 않을 수 있습니다.

이러한 오류를 방지하기 위해 userID 생성자에 약간의 검증을 추가 할 수 있습니다.

이 방법으로 우리는 항상 userID 객체를 사용할 때 유효한 상태를 유지할 수 있습니다. 이것은 우리가 응용 프로그램의 모든 수준에서 우리의 데이터를 지속적으로 재확인하지 못하게합니다.

는 IS_INT를 사용하는 대신 스칼라 유형 선언을 추가 할 수 있지만 userID를 사용하는 곳마다 strict_types를 활성화 할 수 있습니다.

strict_types를 활성화하지 않으면 PHP는 userID로 전달할 때 다른 유형을 int로 자동으로 캐스트하려고합니다. 예를 들어, 이것은 플로팅 포인트 번호를 주입 할 수 있습니다. 사용자 ID가 부동 소수점 번호가 아니기 때문에 실제로 잘못된 변수 일 수 있습니다.

가격 값 객체를 사용할 때와 같은 다른 경우에는 strict_types를 비활성화하면 PHP가 부동 소수점 변수를 int로 자동 변환하므로 반올림 오류가 발생할 수 있습니다.

불변성

기본적으로 객체는 PHP에서 참조로 전달됩니다. 이것은 우리가 객체를 변경할 때 응용 프로그램 전체에서 즉시 변경됨을 의미합니다.

<code class="language-php"><?php
class Notification {
    private $userId;
    private $subject;
    private $message;

    public function __construct(
        $userId,
        $subject,
        $message
    ) {
        $this->userId = $userId;
        $this->subject = $subject;
        $this->message = $message;
    }

    public function getUserId()
    {
        return $this->userId;
    }

    public function getSubject()
    {
        return $this->subject;
    }

    public function getMessage()
    {
        return $this->message;
    }
}
</code>

이 방법에는 장점이 있지만 몇 가지 단점도 있습니다. 문자 메시지 및 이메일을 통해 사용자에게 알림을 보내는 예를 살펴 보겠습니다.

알림 개체가 참조로 전달되기 때문에 예기치 않은 부작용을 일으키고 있습니다. smsnotificationsender에서 메시지 길이를 단축시킴으로써 참조 된 알림 객체는 응용 프로그램 전체에서 업데이트되므로 나중에 emailnotificationsender에 의해 나중에 보낼 때 단축됩니다.

이 문제를 해결하기 위해 알림 개체를 불변으로 만들 수 있습니다. 변경 방법을 제공하는 방법을 제공하는 대신 원래 알림의 사본을 작성하여 변경 사항을 추가 한 다음 변경 사항을 적용 할 수 있습니다.

이 방법으로, 예를 들어, 메시지 길이를 단축하여 알림 클래스를 변경할 때마다 변경은 더 이상 응용 프로그램 전체에서 전파되지 않으므로 예상치 못한 부작용을 방지합니다.

그러나 PHP에서 물체를 진정으로 불변으로 만드는 것은 어렵습니다 (불가능하지는 않지만). 그러나 코드를보다 오류 방지하기 위해서는 세트 메소드 대신 메소드와 함께 "불변"을 추가하면 클래스 사용자가 더 이상 변경하기 전에 객체를 복제 할 필요가 없기 때문에 이미 도움이됩니다.

예를 들어, 할인이 적용되거나 할인이 적용되지 않는 쇼핑 카트가있을 수 있습니다.

쇼핑 카트의 최종 가격을 계산할 때, 우리는 이제 getDiscount ()가 null 또는 실제 할인을 반환하는지 여부를 확인해야합니다.

이 점검을하지 않으면 getDiscount ()가 null을 반환 할 때 PHP 경고 및/또는 기타 예기치 않은 효과를받을 수 있습니다.

반면에, 할인이 설정되지 않았을 때 빈 객체를 반환하면이 점검을 완전히 삭제할 수 있습니다. Poka Yoke - Saving Projects with Hyper-Defensive Programming 이제 GetDiscount ()를 호출 할 때, 우리는 할인을 사용할 수없는 경우에도 항상 할인 객체를 얻습니다. 이런 식으로 우리는 총계에 할인을 적용 할 수 있으며, 할인이 없어도 더 이상 if 문이 필요하지 않습니다.

선택적 종속성 귀중한 반환 값을 피하려는 이유로 선택적 종속성을 피할 수 있지만 모든 종속성을 필요로합니다.

예를 들어 다음 클래스 :

이 방법에는 두 가지 문제가 있습니다

<code class="language-php"><?php
class Notification {
    private $userId;
    private $subject;
    private $message;

    public function __construct(
        $userId,
        $subject,
        $message
    ) {
        $this->userId = $userId;
        $this->subject = $subject;
        $this->message = $message;
    }

    public function getUserId()
    {
        return $this->userId;
    }

    public function getSubject()
    {
        return $this->subject;
    }

    public function getMessage()
    {
        return $this->message;
    }
}
</code>

우리는 dosomething () 메소드에 로거가 있는지 지속적으로 확인해야합니다.

서비스 컨테이너에 Someservice 클래스를 설정할 때 누군가가 실제로 로거를 설정하는 것을 잊을 수도 있고, 클래스에 로거를 설정할 수있는 옵션이 있다는 것을 알지 못할 수도 있습니다.

<code class="language-php"><?php
declare(strict_types=1);

class Notification {
    private $userId;
    private $subject;
    private $message;

    public function __construct(
        int $userId,
        string $subject,
        string $message
    ) {
        $this->userId = $userId;
        $this->subject = $subject;
        $this->message = $message;
    }

    public function getUserId() : int
    {
        return $this->userId;
    }

    public function getSubject() : string
    {
        return $this->subject;
    }

    public function getMessage() : string
    {
        return $this->message;
    }
}
</code>

우리는 LoggerInterface를 필요한 종속성으로 만들어이 문제를 단순화 할 수 있습니다.

이런 식으로 우리의 공개 인터페이스는 덜 혼란스러워지고 누군가가 새로운 인스턴스를 만들 때마다 클래스에 LoggerInterface의 인스턴스가 필요하다는 것을 알고 있으므로 인스턴스를 주입하는 것을 잊지 않을 것입니다.

또한, 우리는 Logger가 주입되었는지 확인하기 위해 IF 문을 생략했기 때문에, 우리의 dosomething ()를 읽기 쉽고 누군가가 오류를 변경할 때 오류 가능성을 줄였습니다.

어느 시점에서 로거없이 someservice를 사용하려면 return 문과 동일한 논리를 적용 할 수 있지만 빈 객체를 사용하십시오 : .

<code class="language-php"><?php
class Notification {
    private $userId;
    private $subject;
    private $message;

    public function __construct(
        $userId,
        $subject,
        $message
    ) {
        $this->userId = $userId;
        $this->subject = $subject;
        $this->message = $message;
    }

    public function getUserId()
    {
        return $this->userId;
    }

    public function getSubject()
    {
        return $this->subject;
    }

    public function getMessage()
    {
        return $this->message;
    }
}
</code>

궁극적으로, 이것은 옵션 SetLogger () 메소드를 사용하는 것과 동일한 효과를 가지지 만 코드를 쉽게 따르고 종속성 분사 컨테이너의 오류 가능성을 줄입니다.

공개 인터페이스 코드를보다 쉽게 사용하기 위해 클래스의 공개 메소드 수를 최소로 유지하는 것이 가장 좋습니다. 이런 식으로 우리의 코드 사용은 덜 혼란스러워지고 코드가 줄어들고 리팩토링 할 때 뒤로 호환 될 가능성이 줄어 듭니다.

공개 방법을 최소로 유지하기 위해 공개 방법을 거래로 간주 할 수 있습니다.

예를 들어 두 은행 계좌간에 돈을 송금하십시오

기본 데이터베이스는 예금을 만들 수없는 경우 자금이 인출되지 않도록 할 수 있도록 거래를 제공 할 수 있지만 그 반대로 데이터베이스는 $ Account1- & gt; reploy () 또는 $ Account2를 잊지 못하게 할 수 없습니다. -& gt; eposit (). 균형이 잘못되게됩니다.

운 좋게도, 우리는 두 개의 별도 방법을 단일 트랜잭션 방법으로 바꾸면이 문제를 쉽게 해결할 수 있습니다. Poka Yoke - Saving Projects with Hyper-Defensive Programming 결과적으로, 트랜잭션을 부분적으로 완료하는 것이 오류가 발생하기 쉽기 때문에 코드가 더욱 강력 해집니다.

오류 감지 예 오류 방지 메커니즘과 달리 오류 감지 메커니즘은 오류를 방지하기위한 것이 아닙니다. 대신, 그들은 우리가 문제를 감지 할 때 우리에게 경고하도록 설계되었습니다.

그들은 우리의 응용 프로그램 밖에서 대부분의 시간을 존재하며 정기적으로 실행하여 코드 또는 특정 변경 사항을 모니터링합니다.

단위 테스트 단위 테스트는 새 코드가 제대로 작동하도록 보장 할 수 있지만 누군가 시스템의 일부를 리팩터링 할 때 기존 코드가 여전히 예상대로 작동하는지 확인하는 데 도움이 될 수 있습니다.

누군가가 여전히 단위 테스트를 실행하는 것을 잊어 버릴 수 있기 때문에 Travis CI 및 Gitlab CI와 같은 서비스를 사용하여 변경할 때 자동으로 실행하는 것이 좋습니다. 이러한 방식으로 주요 변경이 발생하면 개발자에게 자동으로 통지되며 풀 요청을 검토 할 때 변경 사항이 예상대로 작동하는지 확인하는 데 도움이됩니다.

<code class="language-php"><?php
declare(strict_types=1);

class Notification {
    private $userId;
    private $subject;
    private $message;

    public function __construct(
        int $userId,
        string $subject,
        string $message
    ) {
        $this->userId = $userId;
        $this->subject = $subject;
        $this->message = $message;
    }

    public function getUserId() : int
    {
        return $this->userId;
    }

    public function getSubject() : string
    {
        return $this->subject;
    }

    public function getMessage() : string
    {
        return $this->message;
    }
}
</code>

오류 감지 외에도 단위 테스트는 코드의 특정 부분이 어떻게 작동하는지에 대한 예를 제공하는 좋은 방법이며, 이로 인해 코드를 사용할 때 다른 사람들이 실수를하지 못하게합니다.

코드 적용 범위 보고서 및 돌연변이 테스트 우리는 항상 충분한 테스트를 작성하는 것을 잊을 수 있기 때문에 Coverals와 같은 서비스를 사용하여 단위 테스트를 실행할 때 코드 커버리지 보고서를 자동으로 생성하는 것이 좋습니다. 코드 적용 범위가 다운 될 때마다 Coveralls는 우리에게 알림을 보내서 일부 단위 테스트를 추가 할 수 있으며 시간이 지남에 따라 코드 적용 범위가 어떻게 변경되는지 확인할 수 있습니다.

코드에 대한 단위 테스트가 충분한 지 확인하는 또 다른 더 좋은 방법은 Humbug 사용과 같은 돌연변이 테스트를 설정하는 것입니다. 이름에서 알 수 있듯이,이 테스트는 소스 코드를 약간 변경 한 다음 단위 테스트를 실행하고 돌연변이로 인해 관련 테스트가 실패하기 시작하도록 충분한 코드 커버리지를 확인하도록 설계되었습니다.

코드 적용 범위보고 및 돌연변이 테스트를 사용하여 단위 테스트가 예상치 못한 오류 또는 오류를 방지하기에 충분한 코드를 포함 할 수 있습니다.

코드 분석기 코드 분석기는 개발 프로세스 초기에 응용 프로그램의 오류를 감지 할 수 있습니다. 예를 들어, Phpstorm과 같은 IDE는 코드 분석기를 사용하여 오류를 경고하고 코드를 작성할 때 제안을 제공합니다. 이는 간단한 구문 오류에서부터 반복 코드 감지에 이르기까지 다양합니다.

대부분의 IDE의 내장 분석기 외에도 타사 또는 사용자 정의 분석기를 응용 프로그램의 빌드 프로세스에 통합하여 특정 문제를 발견 할 수 있습니다. PHP 프로젝트에 적합한 비수분력있는 분석기 목록은 표준 분석기에서 보안 취약성을 확인하는 분석기에 이르기까지 Exakat/PHP-Static-Analysis-Tools에서 찾을 수 있습니다.

Sensiolabs Insights와 같은 온라인 솔루션이 존재합니다.

로그 메시지 대부분의 다른 오류 감지 메커니즘과 달리 로그 메시지는 제작에서 실시간으로 실행될 때 응용 프로그램의 오류를 감지하는 데 도움이 될 수 있습니다.

물론, 우리의 코드는 먼저 예기치 않은 상황이 발생할 때 실제로 메시지를 기록해야합니다. 코드가 로거를 지원하더라도 설정하는 동안 모든 것을 잊기 쉽습니다. 따라서 선택적 종속성을 피해야합니다 (위 참조).

대부분의 응용 프로그램은 최소한 일부 메시지를 기록하지만 Kibana 또는 Nagios와 같은 도구를 사용하여 사전에 분석하고 모니터링 할 때 제공되는 정보가 진정으로 흥미로워집니다. 이러한 도구는 사용자가 내부적으로 테스트 할 때가 아닌 응용 프로그램을 적극적으로 사용할 때 응용 프로그램에서 발생하는 오류 및 경고에 대한 통찰력을 제공합니다. 이 ELK 스택을 사용하여 PHP 응용 프로그램 모니터링에 대한 훌륭한 기사가 있습니다.

오류를 억제하지 마십시오 오류 메시지가 적극적으로 로깅 되더라도 일부 오류는 종종 억제됩니다. "복구 가능한"오류가 발생할 때마다 PHP는 마치 애플리케이션을 실행하여 우리를 도와 주려는 것처럼 계속 실행되는 경향이 있습니다. 그러나 새로운 기능을 개발하거나 테스트 할 때 오류는 일반적으로 코드의 오류를 나타 내기 때문에 종종 매우 유용합니다.

이것은 대부분의 코드 분석기가 @ suppression 오류를 사용한다고 감지 할 때 경고하는 이유입니다. 방문자가 실제로 응용 프로그램을 사용하면 필연적으로 다시 나타나는 오류를 숨길 수 있습니다.

일반적으로 PHP의 Error_reporting 레벨을 E_all로 설정하여 가장 작은 경고조차보고되도록하는 것이 가장 좋습니다. 그러나 이러한 메시지가 어딘가에 기록되어 사용자 앞에 숨겨져있어 애플리케이션 아키텍처 또는 잠재적 보안 취약점에 대한 민감한 정보가 최종 사용자에게 노출되지 않도록하십시오.

error_reporting 구성 외에도 PHP가 기능 매개 변수를 예상 유형으로 자동 캐스팅하려고 시도하지 않도록 항상 strict_types를 활성화해야합니다. 이는 한 유형에서 다른 유형으로 변환 할 때 (예 : int로 변환 할 때 플로트 반올림 오류로부터 ) 일반적으로 오류를 감지하기가 어렵습니다.

Php 이외의 사용 Poka 요크는 특정 기술보다 개념에 더 가깝기 때문에 PHP 이외의 영역 (그러나 PHP와 관련된 영역)에도 적용될 수 있습니다.

인프라 인프라 수준에서 Vagrant와 같은 도구를 사용하여 생산 환경과 동일한 개발 설정을 공유하여 많은 오류를 방지 할 수 있습니다.

Jenkins 및 GOCD와 같은 서버 구축을 사용하면 응용 프로그램에 변경 사항을 배포 할 때 오류를 방지하는 데 도움이 될 수 있습니다. 이는 종종 응용 프로그램에 의존하는 많은 필요한 단계가 포함되어있어 쉽게 잊을 수 있습니다.

휴식 api

REST API를 구축 할 때는 Poka 요크를 사용하여 API를보다 쉽게 사용할 수 있습니다. 예를 들어, URL 쿼리 또는 요청 본문에서 알 수없는 매개 변수를 전달할 때 오류가 항상 반환 될 수 있습니다. API 클라이언트를 "파괴"하지 않기를 원하기 때문에 이것은 이상하게 보일 수 있지만, 개발자가 개발자에게 잘못된 사용에 대해 가능한 빨리 API를 사용하여 개발자에게 개발 프로세스 초기에 버그를 수정할 수 있도록 경고하는 것이 좋습니다.

예를 들어 API에는 색상 매개 변수가있을 수 있지만 API를 사용하는 사람이 실수로 색상 매개 변수를 사용할 수 있습니다. 경고가 없으면이 오류는 최종 사용자가 예상치 못한 동작으로 인해 알아 차릴 때까지 쉽게 생산에 들어갈 수 있습니다. 나중에 실망하지 않는 API를 구축하는 방법을 이해하려면 좋은 책이 도움이 될 수 있습니다.

응용 프로그램 구성 효과적으로 모든 응용 프로그램은 적어도 일부 사용자 정의 구성에 의존합니다. 일반적으로 개발자는 구성을 위해 가능한 많은 기본값을 제공하는 것을 선호하므로 응용 프로그램을 구성하는 것이 덜 작동합니다.

그러나 위의 색상 및 색상 예제와 마찬가지로 구성 매개 변수를 잘못 입력하기 쉽기 때문에 응용 프로그램이 실수로 기본값으로 떨어집니다. 응용 프로그램에 오류가 발생하지 않으면 이러한 오류를 추적하기가 어렵고, 잘못된 구성에 오류를 던지는 가장 좋은 방법은 기본값을 전혀 제공하지 않고 구성 매개 변수가 없을 때 즉시 오류를 던지는 것입니다.

사용자 오류 방지

포카 요크 개념은 사용자 오류를 방지하거나 감지하기 위해 적용될 수도 있습니다. 예를 들어 결제 소프트웨어에서 확인 비트 알고리즘을 사용하여 사용자가 입력 한 계정을 확인할 수 있습니다. 이렇게하면 사용자가 실수로 오타로 계정을 입력하지 못하게됩니다.

결론 Poka 요크는 특정 도구 세트보다 개념에 더 가깝지만, 우리는 오류가 가능한 한 빨리 예방되거나 감지되도록 코드 및 개발 프로세스에 다양한 원칙을 적용 할 수 있습니다. 종종 이러한 메커니즘은 응용 프로그램 자체와 비즈니스 로직에만 해당되지만 몇 가지 간단한 기술과 도구를 사용하여 코드를 더 이상 오류 방지 할 수 있습니다.

가장 중요한 것은 생산 오류를 피하고 싶지만 개발에 매우 유용하며 오류가 더 쉽게 추적 될 수 있도록 가능한 빨리 올리기를 두려워해서는 안된다는 것입니다. 이러한 오류는 코드 자체 또는 응용 프로그램과 별도로 실행되고 외부에서 모니터링하는 별도의 프로세스에 의해 제기 될 수 있습니다.

오류를 더 줄이려면 코드의 공개 인터페이스를 가능한 한 간단하고 명확하게 만들기 위해 노력해야합니다.

POKA 요크를 PHP 개발 또는 일반 프로그래밍에 적용하는 방법에 대한 다른 팁이 있다면 의견을 자유롭게 공유하십시오!

추가 읽기 포카 요크

Poka-Yoke-Toyota Production System Guide는 Toyota 제조 공정에서 Poka 요크의 역할을 설명합니다.

소프트웨어 품질을 향상시키기 위해 Poka-Yoke 기술을 사용하는 방법은 Poka Yoka를 사용하여 소프트웨어 기능의 품질을 향상시키는 방법에 대한 팁을 제공합니다.

Poka-Yoke 코드는 일반 프로그래밍에 Poka 요크를 적용하는 방법에 대한 간략한 개요를 제공합니다.

POKA 요크 - 소프트웨어에 실수 교정을 적용하면 포카 요크를 프로그래밍에 적용하는 방법에 대한 자세한 개요가 제공됩니다.

php

의 포카 요크

매우 방어적인 PHP는 PHP 코드를보다 오류 방지하는 방법에 대해 논의합니다.

PHP의 불변 가치 객체는 실제로 가치 객체를 불변 할 수없는 방법 (또는 최소한 가능한 한 불변)하는 방법을 간략하게 설명합니다.
<:> 좋은 코드 작성 : 코드의인지 부하를 줄이는 방법은 코드를 쉽게 따라갈 수 있도록하는 다양한 방법을 설명하여 코드를 사용할 때 실수를 저지르거나 변경할 때 누군가가 실수 할 가능성을 줄입니다.
Poka-Yoke 및 Hyper-Defensive Programming에 대한 질문

프로그래밍에서 Poka-Yoke의 주요 목적은 무엇입니까?

Poka-Yoke는 "실수 방지"로 번역되는 일본 용어입니다. 프로그래밍의 맥락에서, 그것은 오류가 발생하지 않도록 설계된 방어 설계 접근법입니다. 오류를 피하고 기능이 올바르게 사용되도록 보안 조치를 구현하는 것이 포함됩니다. 프로그래밍의 Poka-Yoke의 주요 목적은 소프트웨어의 품질을 향상시키고 오류를 줄여 개발 프로세스 중에 시간과 자원을 절약하는 것입니다.

Poka-Yoke는 전통적인 프로그래밍 방법과 어떻게 다릅니 까?

전통적인 프로그래밍 방법은 일반적으로 기능 코드 생성에 중점을두고, 오류 처리 및 오류 수정은 일반적으로 초기 개발 후에 수행됩니다. 반면, Poka-Yoke는 자체 개발 단계에서 오류 방지 메커니즘을 결합하여 적극적인 접근 방식을 취합니다. 이로 인해 더 강력하고 신뢰할 수있는 코드가 발생하여 나중에 많은 디버깅 및 테스트가 필요합니다.

포카 요크를 프로그래밍 언어에 적용 할 수 있습니까?
예, Poka-Yoke는 모든 프로그래밍 언어에 적용될 수있는 개념입니다. 특정 도구 나 기술이 아니라 사고 방식이나 프로그래밍 방법입니다. 어떤 언어를 사용하든 Poka-Yoke 원칙을 구현하여 코드를보다 오류에 필적 할 수 있습니다.
프로그래밍에서 Poka-Yoke의 몇 가지 예는 무엇입니까?
프로그래밍에서 Poka-Yoke의 예에는 입력 검증 (처리 전에 데이터가 올바르게 형식화되도록), 어설 션을 사용하여 특정 지점에서 프로그램의 상태를 확인하고 실패의 기본값을 구현합니다 (실패의 경우 최소화하기 위해 ) 손상에 대한 기본 조치).
Poka-Yoke는 소프트웨어 제품의 전반적인 품질을 어떻게 촉진합니까?
Poka-Yoke는 개발 단계에서 오류를 방지함으로써 소프트웨어 제품의 전반적인 품질을 향상시키는 데 도움이됩니다. 오류와 결함의 수를 줄이면 더 안정적이고 안정적인 소프트웨어가 생깁니다. 이는 사용자 경험을 향상시킬뿐만 아니라 디버깅 및 유지 보수 비용과 시간을 줄입니다.
Poka-Yoke는 시간이 많이 걸리는 과정입니까?

Poka-Yoke를 구현하는 데는 개발 단계에서 약간의 시간이 걸릴 수 있지만 장기적으로 많은 시간을 절약 할 수 있습니다. 오류가 발생하기 전에 오류를 방지함으로써 오류를 디버깅하고 수정하는 데 소요되는 시간이 줄어들어 전달 시간이 줄어들고 개발 효율성을 향상시킵니다.
제조에서 포카 요크의 이점은 무엇입니까?
제조에서 Poka-Yoke는 오류와 결함을 예방하여 고품질 제품을 생산하는 데 도움이 될 수 있습니다. 또한 재 작업 및 수리의 시간과 리소스를 줄임으로써 효율성과 생산성을 향상시킬 수 있습니다.
프로그래밍 연습에서 Poka-Yoke 구현을 어떻게 시작합니까?
프로그래밍 관행에서 Poka-Yoke 구현을 시작하려면 먼저 코드에서 일반적인 오류 또는 잠재적 실패 지점을 식별해야합니다. 그런 다음 이러한 오류를 방지하는 전략을 개발하거나 발생할 때 우아하게 처리하십시오. 여기에는 입력 검증, 어설 션, 실패 안전 기본값 또는 기타 오류 방지 기술이 포함될 수 있습니다.
Poka-Yoke가 민첩한 개발에 사용될 수 있습니까?
예, Poka-Yoke는 민첩한 개발에 효과적으로 사용할 수 있습니다. 실제로, 소프트웨어의 모든 반복이 가능한 한 오류가 없는지 확인하는 데 도움이되기 때문에 민첩한 원칙 (러닝 가능한 소프트웨어의 빈번한 전달)에 적합합니다.
Poka-Yoke는 대규모 프로젝트에만 유용합니까?
아니요, Poka-Yoke는 모든 규모의 프로젝트에 유리합니다. 소규모 프로젝트의 경우에도 개발 단계에서 오류를 방지하면 시간과 자원을 절약하고 고품질 최종 제품을 생산할 수 있습니다.

POKA 요크 - 과다 방어 프로그래밍으로 프로젝트를 절약합니다

제조 외에도 포카 요크는 소비자 전자 제품에 자주 사용됩니다. 예를 들어, SIM 카드는 비대칭 모양으로 인해 SIM 트레이에만 삽입 될 수 있습니다.

검증

이것은 대부분의 코드 분석기가 @ suppression 오류를 사용한다고 감지 할 때 경고하는 이유입니다. 방문자가 실제로 응용 프로그램을 사용하면 필연적으로 다시 나타나는 오류를 숨길 수 있습니다.

휴식 api

의 포카 요크

예, Poka-Yoke는 모든 프로그래밍 언어에 적용될 수있는 개념입니다. 특정 도구 나 기술이 아니라 사고 방식이나 프로그래밍 방법입니다. 어떤 언어를 사용하든 Poka-Yoke 원칙을 구현하여 코드를보다 오류에 필적 할 수 있습니다.

제조에서 Poka-Yoke는 오류와 결함을 예방하여 고품질 제품을 생산하는 데 도움이 될 수 있습니다. 또한 재 작업 및 수리의 시간과 리소스를 줄임으로써 효율성과 생산성을 향상시킬 수 있습니다.

예, Poka-Yoke는 민첩한 개발에 효과적으로 사용할 수 있습니다. 실제로, 소프트웨어의 모든 반복이 가능한 한 오류가 없는지 확인하는 데 도움이되기 때문에 민첩한 원칙 (러닝 가능한 소프트웨어의 빈번한 전달)에 적합합니다.

관련 기사