Artikel ini dikaji semula oleh Deji Akala dan Marco Pivetta. Terima kasih kepada semua pengulas rakan sebaya SitePoint untuk mendapatkan kandungan terbaik di sitepoint!
Kesalahan ini boleh didapati dalam jaminan kualiti, tetapi juga mungkin benar -benar diabaikan. Walaupun ditemui, menghantar kod kembali dan penetapan boleh mengambil banyak masa. 
"poka yoke"
.mata utama
Contoh perkakasan yang kurang poka yoke adalah port PS/2, yang mempunyai bentuk yang sama untuk penyambung papan kekunci dan penyambung tetikus. Mereka hanya boleh dibezakan dengan menggunakan kod warna, jadi mudah untuk secara tidak sengaja menukar penyambung dan memasukkannya ke dalam pelabuhan yang salah, kerana mereka semua sesuai dengan cara yang sama.
Walau bagaimanapun, sila ambil perhatian bahawa Poka Yoke tidak bertujuan untuk mengelakkan penyalahgunaan yang disengajakan. Matlamatnya adalah untuk mengelakkan kesilapan yang tidak dijangka, bukan untuk melindungi kod dari penggunaan berniat jahat. Selagi seseorang mempunyai akses kepada kod anda, mereka sentiasa dapat memintas langkah keselamatan anda jika mereka benar -benar mahu.
Sebelum membincangkan langkah-langkah tertentu yang boleh diambil untuk menjadikan kod lebih banyak bukti kesilapan, adalah penting untuk mengetahui bahawa mekanisme poka yoke biasanya boleh dibahagikan kepada dua kategori:
Sebaliknya, mekanisme pengesanan ralat wujud di luar kod kami. Mereka memantau aplikasi kami untuk kesilapan yang berpotensi dan memberi amaran kepada kami. Contohnya adalah untuk mengesan sama ada peranti yang disambungkan ke port PS/2 adalah jenis perisian yang betul, dan jika tidak, amaran dipaparkan kepada pengguna mengenai sebab mengapa ia tidak berfungsi. Perisian ini tidak dapat menghalang kesilapan kerana penyambung boleh ditukar ganti apabila dipasang, tetapi ia dapat mengesan kesilapan dan memberi amaran kepada kami supaya ralat dapat diperbaiki.
Di seluruh artikel ini, kami akan meneroka beberapa kaedah yang boleh digunakan untuk melaksanakan pencegahan ralat dan pengesanan kesilapan dalam aplikasi kami. Tetapi ingat bahawa senarai ini hanyalah titik permulaan. Bergantung pada aplikasi khusus anda, mungkin ada langkah tambahan yang dapat membuat kod anda lebih banyak bukti ralat. Juga, adalah penting untuk mengingati kos pendahuluan Poka Yoke dan pastikan ia berbaloi untuk projek khusus anda. Bergantung pada kerumitan dan saiz aplikasi, beberapa langkah boleh terlalu mahal berbanding dengan kos ralat yang berpotensi. Oleh itu, anda dan pasukan anda perlu menentukan langkah -langkah yang terbaik untuk anda ambil.
Contoh pencegahan ralat
(skalar) pengisytiharan jenis
Dengan memberikan jenis tertentu kepada parameter fungsi, menghalang susunan parameter menjadi lebih sukar apabila memanggil fungsi.
Contohnya, mari kita lihat pemberitahuan ini yang mungkin kita mahu hantar kepada pengguna:
<?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;
}
}
Jika kita menyuntik jenis yang salah, ralat tidak dapat dikesan sehingga aplikasi cuba untuk benar -benar memproses pemberitahuan. Pada masa itu, kami mungkin mendapat beberapa mesej ralat yang tidak dapat difahami mengenai jenis yang tidak dijangka, tetapi tidak ada yang segera menunjuk kepada kod kami yang menyuntik rentetan bukannya bilangan bulat.
Oleh itu, biasanya lebih menarik untuk memaksa permohonan itu untuk kemalangan secepat mungkin supaya kesilapan tersebut dapat dikesan seawal mungkin semasa pembangunan.
Dalam kes ini, kita hanya dapat menambah beberapa pengisytiharan jenis, dan apabila kita menghilangkan jenis parameter, PHP akan berhenti dengan segera dan memberi amaran kepada kita tentang kesilapan maut:
Tetapi perhatikan bahawa secara lalai, PHP akan cuba membuang parameter yang salah kepada jenis yang diharapkan. Untuk mengelakkan ini, adalah penting bahawa kami membolehkan ketegangan_types supaya kami benar -benar akan menerima ralat maut apabila ralat berlaku. Oleh itu, pengisytiharan jenis skalar bukanlah bentuk poka yoke yang ideal, tetapi mereka adalah permulaan yang baik untuk mengurangkan kesilapan. Walaupun Strict_types dilumpuhkan, mereka masih boleh berfungsi sebagai petunjuk jenis parameter yang diharapkan.
<?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;
}
}
Di samping itu, kami mengisytiharkan jenis pulangan untuk kaedah tersebut. Ini menjadikannya lebih mudah untuk menentukan nilai yang boleh anda harapkan apabila memanggil fungsi tertentu.
Jenis pulangan yang ditakrifkan juga membantu mengelakkan menggunakan sejumlah besar pernyataan suis apabila memproses nilai pulangan, kerana kaedah kami dapat mengembalikan pelbagai jenis tanpa jenis pulangan yang diisytiharkan secara eksplisit. Oleh itu, mereka yang menggunakan kaedah kami mesti memeriksa jenis mana yang sebenarnya dikembalikan dalam kes tertentu. Kenyataan suis ini jelas dilupakan dan membawa kepada kesilapan yang tidak dapat dikesan. Menggunakan jenis pulangan, kesilapan tersebut akan dikurangkan.
Objek nilai
PHP boleh memberi amaran kepada kita apabila kita menghilangkan perintah parameter apabila semua parameter mempunyai jenis skalar yang berbeza, tetapi dalam kebanyakan kes kita mungkin mempunyai beberapa parameter dengan jenis yang sama. 
Kerana parameter kami kini mempunyai jenis yang sangat spesifik, hampir mustahil untuk mengelirukan mereka.
class UserId {
private $userId;
public function __construct(int $userId) {
$this->userId = $userId;
}
public function getValue() : int
{
return $this->userId;
}
}
class Subject {
private $subject;
public function __construct(string $subject) {
$this->subject = $subject;
}
public function getValue() : string
{
return $this->subject;
}
}
class Message {
private $message;
public function __construct(string $message) {
$this->message = $message;
}
public function getMessage() : string
{
return $this->message;
}
}
class Notification {
/* ... */
public function __construct(
UserId $userId,
Subject $subject,
Message $message
) {
$this->userId = $userId;
$this->subject = $subject;
$this->message = $message;
}
public function getUserId() : UserId { /* ... */ }
public function getSubject() : Subject { /* ... */ }
public function getMessage() : Message { /* ... */ }
}
Sebagai contoh, kita mungkin mempunyai peraturan bahawa mana -mana pengguna yang diberikan harus sentiasa positif.
kita dapat mengesahkan peraturan ini setiap kali kita mendapat userid sebagai input, tetapi sebaliknya, ia juga boleh dilupakan dengan mudah di satu tempat atau yang lain.
Walaupun kesilapan ini menyebabkan ralat sebenar berlaku di lapisan lain aplikasi, mesej ralat mungkin tidak jelas menunjukkan ralat yang sebenarnya berlaku dan sukar untuk debug.
Untuk mengelakkan kesilapan tersebut, kami boleh menambah beberapa pengesahan kepada pembina userid:
Dengan cara ini, kita sentiasa dapat memastikan bahawa apabila menggunakan objek userid, ia mempunyai keadaan yang sah. Ini menghalang kami daripada sentiasa menghormati data kami di semua peringkat aplikasi kami.
<?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;
}
}
Perhatikan bahawa kita boleh menambah pengisytiharan jenis skalar dan bukannya menggunakan is_int, tetapi ini akan memaksa kita untuk mengaktifkan strict_types di mana -mana kita menggunakan userid.
Jika kita tidak mengaktifkan Strict_types, PHP secara automatik akan cuba untuk membuang jenis lain ke INT apabila menyampaikannya ke UserId. Ini boleh menjadi masalah, sebagai contoh, kita mungkin menyuntik nombor titik terapung, yang sebenarnya boleh menjadi pemboleh ubah yang salah kerana ID pengguna bukan nombor titik terapung.
Dalam kes lain, seperti ketika kita boleh menggunakan objek nilai harga, melumpuhkan ketat boleh mengakibatkan ralat pembulatan, kerana PHP secara automatik akan menukar pembolehubah titik terapung ke int.
Immutability
Walaupun kaedah ini mempunyai kelebihannya, ia juga mempunyai beberapa kelemahan. Mari kita lihat contoh menghantar pemberitahuan kepada pengguna melalui mesej teks dan e -mel: 
Kami menyebabkan kesan sampingan yang tidak dijangka kerana objek pemberitahuan diluluskan dengan rujukan. Dengan memendekkan panjang mesej dalam SMSNotificationssender, objek pemberitahuan yang dirujuk dikemas kini sepanjang permohonan, yang bermaksud ia juga dipendekkan apabila dihantar kemudian oleh EmailNotifications.
<?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;
}
}
Dengan cara ini, apabila kita menukar kelas pemberitahuan oleh, sebagai contoh, memendekkan panjang mesej, perubahan tidak lagi disebarkan di seluruh aplikasi, dengan itu menghalang sebarang kesan sampingan yang tidak dijangka.
tetapi perhatikan bahawa sukar (jika tidak mustahil) untuk membuat objek yang benar -benar tidak berubah dalam PHP. Tetapi untuk menjadikan kod kami lebih banyak bukti kesilapan, sudah membantu jika kita menambah "tidak berubah" dengan kaedah dan bukannya menetapkan kaedah, kerana pengguna kelas tidak lagi perlu ingat untuk mengklon objek itu sendiri sebelum membuat perubahan.
Kadang -kadang kita mungkin mempunyai fungsi atau kaedah yang boleh mengembalikan nilai atau batal tertentu. Nilai pulangan yang tidak dapat disangkal ini boleh menyebabkan masalah, kerana mereka hampir selalu perlu memeriksa sama ada mereka kosong sebelum kita boleh menggunakannya. Sekali lagi, ini adalah sesuatu yang boleh kita lupakan dengan mudah. Untuk mengelakkan sentiasa perlu menyemak nilai pulangan, kita boleh mengembalikan objek kosong sebaliknya.
Contohnya, kita boleh mempunyai tempat membeli -belah di mana diskaun digunakan atau tiada diskaun digunakan:
Apabila mengira harga akhir shoppingcart, kita kini perlu memeriksa sama ada getDiscount () mengembalikan null atau diskaun sebenar sebelum kita boleh memanggil kaedah applyTo:
<?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;
}
}
Jika kita tidak melakukan cek ini, kita mungkin menerima amaran PHP dan/atau kesan yang tidak dijangka lain apabila getDiscount () mengembalikan batal.
<?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;
}
}
Sebaliknya, jika kita mengembalikan objek kosong apabila diskaun tidak ditetapkan, kita boleh memadamkan cek ini sepenuhnya:
Sekarang, apabila kita memanggil getDiscount (), kita sentiasa mendapat objek diskaun walaupun tidak ada diskaun yang tersedia. Dengan cara ini kita boleh menggunakan diskaun kepada jumlah kami, dan walaupun tanpa diskaun, kami tidak lagi memerlukan pernyataan IF:
class UserId {
private $userId;
public function __construct(int $userId) {
$this->userId = $userId;
}
public function getValue() : int
{
return $this->userId;
}
}
class Subject {
private $subject;
public function __construct(string $subject) {
$this->subject = $subject;
}
public function getValue() : string
{
return $this->subject;
}
}
class Message {
private $message;
public function __construct(string $message) {
$this->message = $message;
}
public function getMessage() : string
{
return $this->message;
}
}
class Notification {
/* ... */
public function __construct(
UserId $userId,
Subject $subject,
Message $message
) {
$this->userId = $userId;
$this->subject = $subject;
$this->message = $message;
}
public function getUserId() : UserId { /* ... */ }
public function getSubject() : Subject { /* ... */ }
public function getMessage() : Message { /* ... */ }
}
Ketergantungan pilihan
class UserId {
private $userId;
public function __construct($userId) {
if (!is_int($userId) || $userId <= 0) {
throw new \InvalidArgumentException(
'UserId should be a positive integer.'
);
}
$this->userId = $userId;
}
public function getValue() : int
{
return $this->userId;
}
}
contohnya, kelas berikut:
Terdapat dua masalah dengan kaedah ini:
interface NotificationSenderInterface
{
public function send(Notification $notification);
}
class SMSNotificationSender implements NotificationSenderInterface
{
public function send(Notification $notification) {
$this->cutNotificationLength($notification);
// 发送短信...
}
/**
* 确保通知不超过短信长度。
*/
private function cutNotificationLength(Notification $notification)
{
$message = $notification->getMessage();
$messageString = substr($message->getValue(), 0, 160); // 修正截取长度
$notification->setMessage(new Message($messageString));
}
}
class EmailNotificationSender implements NotificationSenderInterface
{
public function send(Notification $notification) {
// 发送电子邮件...
}
}
$smsNotificationSender = new SMSNotificationSender();
$emailNotificationSender = new EmailNotificationSender();
$notification = new Notification(
new UserId(17466),
new Subject('Demo notification'),
new Message('Very long message ... over 160 characters.')
);
$smsNotificationSender->send($notification);
$emailNotificationSender->send($notification);
kita mesti sentiasa memeriksa sama ada terdapat logger dalam kaedah dosomething ().
Dengan cara ini antara muka umum kita menjadi kurang mengelirukan, dan apabila seseorang membuat contoh baru SomeService, mereka tahu bahawa kelas memerlukan contoh LoggerInterface, jadi mereka tidak akan lupa untuk menyuntik contoh.
class Notification {
public function __construct( ... ) { /* ... */ }
public function getUserId() : UserId { /* ... */ }
public function withUserId(UserId $userId) : Notification {
return new Notification($userId, $this->subject, $this->message); // 使用新的Notification实例
}
public function getSubject() : Subject { /* ... */ }
public function withSubject(Subject $subject) : Notification {
return new Notification($this->userId, $subject, $this->message); // 使用新的Notification实例
}
public function getMessage() : Message { /* ... */ }
public function withMessage(Message $message) : Notification {
return new Notification($this->userId, $this->subject, $message); // 使用新的Notification实例
}
}Di samping itu, kami meninggalkan pernyataan jika untuk memeriksa sama ada logger disuntik, yang menjadikan dosomething kami lebih mudah untuk membaca dan mengurangkan kemungkinan kesilapan apabila seseorang membuat perubahan kepadanya.
Jika pada suatu ketika kita mahu menggunakan SomeService tanpa logger, kita boleh menggunakan logik yang sama seperti pernyataan kembali, tetapi hanya gunakan objek kosong:
<?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;
}
}
Pada akhirnya, ini mempunyai kesan yang sama dengan menggunakan kaedah setLogger () pilihan, tetapi ia menjadikan kod kami lebih mudah untuk diikuti dan mengurangkan kemungkinan kesilapan dalam bekas suntikan ketergantungan.
Untuk menjadikan kod kami lebih mudah digunakan, lebih baik untuk menyimpan bilangan kaedah awam di kelas minimum. Dengan cara ini penggunaan kod kami menjadi kurang mengelirukan, kami mengekalkan kurang kod, dan kurang berkemungkinan untuk memecahkan keserasian ke belakang apabila refactoring.
Contohnya, memindahkan wang antara dua akaun bank:
Walaupun pangkalan data yang mendasari dapat memberikan urus niaga untuk memastikan bahawa jika deposit tidak dapat dibuat, tidak ada dana yang akan ditarik balik, dan sebaliknya, pangkalan data tidak dapat menghalang kami daripada lupa untuk memanggil $ account1- & gt; menarik diri () atau $ account2 -& gt; deposit (), yang akan menyebabkan keseimbangan tidak betul.
<?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;
}
}
bernasib baik, kita dapat menyelesaikan masalah ini dengan mudah dengan menggantikan dua kaedah berasingan kita dengan kaedah transaksi tunggal:
Akibatnya, kod kami menjadi lebih mantap kerana hanya sebahagiannya menyelesaikan urus niaga yang lebih mudah untuk kesilapan.
class UserId {
private $userId;
public function __construct(int $userId) {
$this->userId = $userId;
}
public function getValue() : int
{
return $this->userId;
}
}
class Subject {
private $subject;
public function __construct(string $subject) {
$this->subject = $subject;
}
public function getValue() : string
{
return $this->subject;
}
}
class Message {
private $message;
public function __construct(string $message) {
$this->message = $message;
}
public function getMessage() : string
{
return $this->message;
}
}
class Notification {
/* ... */
public function __construct(
UserId $userId,
Subject $subject,
Message $message
) {
$this->userId = $userId;
$this->subject = $subject;
$this->message = $message;
}
public function getUserId() : UserId { /* ... */ }
public function getSubject() : Subject { /* ... */ }
public function getMessage() : Message { /* ... */ }
}
Contoh pengesanan ralat
mereka wujud sebahagian besar masa di luar aplikasi kami dan berjalan secara teratur untuk memantau kod kami atau perubahan khusus kepada mereka.
Ujian unit
Kerana seseorang masih lupa untuk menjalankan ujian unit kami, disarankan untuk menggunakan perkhidmatan seperti Travis CI dan Gitlab CI untuk menjalankannya secara automatik apabila mereka membuat perubahan. Dengan cara ini, pemaju akan diberitahu secara automatik apabila perubahan besar berlaku, yang juga membantu kami memastikan perubahan berfungsi seperti yang diharapkan ketika mengkaji permintaan tarik.
Selain pengesanan ralat, ujian unit juga merupakan cara yang baik untuk memberikan contoh bagaimana sebahagian daripada kod tertentu dijangka berfungsi, yang seterusnya menghalang orang lain daripada membuat kesilapan apabila menggunakan kod kami.
laporan liputan kod dan ujian mutasi
Satu lagi cara yang lebih baik untuk memastikan kami mempunyai ujian unit yang mencukupi untuk kod kami adalah untuk menubuhkan beberapa ujian mutasi, seperti menggunakan humbug. Seperti namanya, ujian ini direka untuk mengesahkan bahawa kami mempunyai liputan kod yang mencukupi dengan sedikit mengubah kod sumber kami, kemudian menjalankan ujian unit kami dan memastikan bahawa ujian yang relevan mula gagal disebabkan oleh mutasi.
Menggunakan pelaporan liputan kod dan ujian mutasi, kami dapat memastikan bahawa ujian unit kami meliputi kod yang cukup untuk mengelakkan kesilapan atau kesilapan yang tidak dijangka.
Penganalisis kod dapat mengesan kesilapan dalam aplikasi awal dalam proses pembangunan. Sebagai contoh, IDE seperti PHPStorm menggunakan penganalisis kod untuk memberi amaran kepada kami tentang kesilapan dan memberi cadangan apabila kami menulis kod kami. Ini terdiri daripada kesilapan sintaks mudah untuk mengesan kod berulang.
Di samping penganalisis terbina dalam di kebanyakan IDE, pihak ketiga atau penganalisis tersuai boleh dimasukkan ke dalam proses membina permohonan untuk menemui isu-isu tertentu. Senarai penganalisis yang tidak lengkap yang sesuai untuk projek PHP boleh didapati di alat Exakat/PHP-Static-analisis, mulai dari pengkhianat penganalisis standard kepada penganalisis yang memeriksa kelemahan keselamatan.
Penyelesaian dalam talian wujud, seperti Sensiolabs Insights.
Berbeza dengan kebanyakan mekanisme pengesanan ralat lain, mesej log dapat membantu kami mengesan kesilapan dalam aplikasi apabila ia berjalan dalam masa nyata dalam pengeluaran.
Walaupun kebanyakan aplikasi merekodkan sekurang -kurangnya beberapa mesej, maklumat yang mereka berikan menjadi benar -benar menarik apabila mereka secara proaktif menganalisis dan memantau mereka menggunakan alat seperti Kibana atau Nagios. Alat sedemikian memberi kita gambaran tentang kesilapan dan amaran yang berlaku dalam aplikasi apabila pengguna secara aktif menggunakan aplikasi itu, dan bukannya ketika menguji secara dalaman. Kami mempunyai artikel yang sangat baik untuk memantau aplikasi PHP menggunakan timbunan Elk ini.
Jangan menindas ralat
Inilah sebabnya mengapa kebanyakan penganalisis kod memberi amaran kepada anda apabila mereka mengesan bahawa anda menggunakan @ kesilapan penindasan, kerana ia dapat menyembunyikan kesilapan yang tidak dapat dielakkan muncul semula apabila pelawat sebenarnya menggunakan permohonan itu.
Secara amnya, adalah lebih baik untuk menetapkan tahap error_reporting php ke e_all supaya walaupun amaran yang sedikit akan dilaporkan. Walau bagaimanapun, pastikan mesej -mesej ini direkodkan di suatu tempat dan tersembunyi di hadapan pengguna supaya maklumat sensitif mengenai seni bina aplikasi atau kelemahan keselamatan yang berpotensi tidak terdedah kepada pengguna akhir.
Selain konfigurasi error_reporting, pastikan anda sentiasa mengaktifkan ketat_types supaya php tidak cuba untuk membuang parameter fungsi secara automatik ke jenis yang diharapkan, kerana ini adalah apabila menukar dari satu jenis ke yang lain (mis. Dari kesilapan bulat terapung ketika menukar ke int ) biasanya menyebabkan sukar untuk mengesan kesilapan.
Oleh kerana poka yoke lebih konsep daripada teknologi tertentu, ia juga boleh digunakan untuk kawasan di luar PHP (tetapi berkaitan dengan PHP).
Di peringkat infrastruktur, alat seperti vagrant boleh digunakan untuk berkongsi tetapan pembangunan yang sama seperti persekitaran pengeluaran, yang dapat menghalang banyak kesilapan.
Menggunakan pembinaan pelayan seperti Jenkins dan GOCD juga boleh membantu mencegah kesilapan apabila menggunakan perubahan pada aplikasi kami, kerana ini sering termasuk sejumlah besar langkah-langkah yang diperlukan yang bergantung kepada aplikasi, yang dapat dilupakan dengan mudah.
Apabila membina API REST, kita boleh menggunakan poka yoke bersama untuk menjadikan API kami lebih mudah digunakan. Sebagai contoh, kita dapat memastikan bahawa ralat sentiasa dikembalikan apabila melepasi parameter yang tidak diketahui dalam pertanyaan URL atau badan permintaan. Ini mungkin kelihatan pelik kerana kami jelas ingin mengelakkan "memecahkan" pelanggan API kami, tetapi biasanya lebih baik untuk memberi amaran kepada pemaju menggunakan API kami secepat mungkin mengenai penggunaan yang salah supaya pepijat dapat ditetapkan awal dalam proses pembangunan.
Sebagai contoh, mungkin terdapat parameter warna pada API kami, tetapi seseorang yang menggunakan API kami secara tidak sengaja menggunakan parameter warna. Tanpa sebarang amaran, kesilapan ini dapat dengan mudah dihasilkan sehingga pengguna akhir memperhatikannya kerana tingkah laku yang tidak dijangka. Untuk memahami bagaimana membina API yang tidak akan mengecewakan anda kemudian, buku yang baik boleh membantu.Konfigurasi Aplikasi
Cegah ralat pengguna
konsep poka yoke juga boleh digunakan untuk mencegah atau mengesan kesilapan pengguna. Sebagai contoh, dalam perisian pembayaran, algoritma bit semak boleh digunakan untuk mengesahkan akaun yang dimasukkan oleh pengguna. Ini menghalang pengguna daripada secara tidak sengaja memasuki akaun dengan kesilapan kesilapan. 
Walaupun Poka Yoke lebih konsep daripada satu set alat tertentu, kita boleh menggunakan pelbagai prinsip untuk proses kod dan pembangunan kami untuk memastikan bahawa kesilapan dicegah atau dikesan seawal mungkin. Sering kali, mekanisme ini akan khusus untuk aplikasi itu sendiri dan logik perniagaannya, tetapi kita boleh menggunakan beberapa teknik dan alat mudah untuk membuat sebarang kod lebih banyak bukti ralat.
Perkara yang paling penting ialah walaupun kita jelas ingin mengelakkan kesilapan dalam pengeluaran, mereka sangat berguna dalam pembangunan dan kita tidak perlu takut untuk membesarkannya secepat mungkin supaya kesilapan dapat dikesan dengan lebih mudah. Kesalahan ini boleh dibangkitkan oleh kod itu sendiri atau dengan proses berasingan yang berjalan secara berasingan dari aplikasi kami dan memantau dari luar.
Untuk mengurangkan lagi kesilapan, kita harus berusaha untuk menjadikan antara muka umum kod itu mudah dan jelas.
Jika anda mempunyai petua lain tentang cara memohon Poka Yoke untuk pembangunan PHP atau pengaturcaraan umum, jangan ragu untuk berkongsi komen!
Poka-yoke adalah istilah Jepun yang diterjemahkan sebagai "pencegahan kesilapan". Dalam konteks pengaturcaraan, ia adalah pendekatan reka bentuk pertahanan yang direka untuk mencegah kesilapan berlaku. Ia melibatkan pelaksanaan langkah -langkah keselamatan untuk membantu mengelakkan kesilapan dan memastikan fungsi digunakan dengan betul. Tujuan utama Poka-Yoke dalam pengaturcaraan adalah untuk meningkatkan kualiti perisian dan mengurangkan kesilapan, dengan itu menjimatkan masa dan sumber semasa proses pembangunan.
Kaedah pengaturcaraan tradisional biasanya memberi tumpuan kepada mewujudkan kod fungsional, pengendalian ralat dan penetapan ralat biasanya dilakukan selepas perkembangan awal. Sebaliknya, Poka-Yoke mengambil pendekatan aktif, menggabungkan mekanisme pencegahan ralat dalam peringkat pembangunannya sendiri. Ini membawa kepada kod yang lebih berkuasa dan boleh dipercayai, mengurangkan keperluan untuk banyak debugging dan ujian kemudian.
Ya, Poka-yoke adalah konsep yang boleh digunakan untuk mana-mana bahasa pengaturcaraan. Ia bukan alat atau teknologi tertentu, tetapi cara pemikiran atau kaedah pengaturcaraan. Tidak kira bahasa yang anda gunakan, anda boleh melaksanakan prinsip Poka-Yoke untuk menjadikan kod anda lebih tahan ralat.
Contoh poka-yoke dalam pengaturcaraan termasuk pengesahan input (untuk memastikan data diformat dengan betul sebelum diproses), menggunakan pernyataan untuk memeriksa keadaan program pada titik-titik tertentu, dan melaksanakan kegagalan yang selamat (untuk meminimumkan sekiranya berlaku kegagalan ) Tindakan lalai untuk kerosakan).
Dengan menghalang kesilapan semasa fasa pembangunan, poka-yoke membantu meningkatkan kualiti keseluruhan produk perisian. Ia mengurangkan bilangan kesilapan dan kecacatan, mengakibatkan perisian yang lebih stabil dan boleh dipercayai. Ini bukan sahaja meningkatkan pengalaman pengguna, tetapi juga mengurangkan kos dan masa debugging dan penyelenggaraan.
Semasa melaksanakan poka-yoke mungkin mengambil masa tambahan semasa fasa pembangunan, ia dapat menjimatkan banyak masa dalam jangka masa panjang. Dengan menghalang kesilapan sebelum berlaku, ia mengurangkan masa yang dibelanjakan untuk menyahpepijat dan menetapkan kesilapan, dengan itu mengurangkan masa penghantaran dan meningkatkan kecekapan pembangunan.
Dalam pembuatan, poka-yoke dapat membantu mencegah kesilapan dan kecacatan, sehingga menghasilkan produk berkualiti tinggi. Ia juga boleh meningkatkan kecekapan dan produktiviti dengan mengurangkan masa dan sumber untuk kerja semula dan pembaikan.
Untuk mula melaksanakan poka-yoke dalam amalan pengaturcaraan anda, anda mesti terlebih dahulu mengenal pasti kesilapan umum atau titik kegagalan yang berpotensi dalam kod anda. Kemudian, mengembangkan strategi untuk mencegah kesilapan ini, atau mengendalikannya dengan anggun apabila ia berlaku. Ini mungkin termasuk pengesahan input, pernyataan, kegagalan gagal, atau teknik pencegahan ralat lain.
Ya, poka-yoke boleh digunakan dengan berkesan untuk pembangunan tangkas. Sebenarnya, ia sesuai dengan prinsip yang tangkas (penyampaian perisian runnable yang kerap) kerana ia membantu memastikan setiap lelaran perisian adalah sebagai bebas kesilapan yang mungkin.
Tidak, poka-yoke bermanfaat untuk projek-projek apa-apa saiz. Malah untuk projek -projek kecil, mencegah kesilapan semasa fasa pembangunan dapat menjimatkan masa dan sumber dan menghasilkan produk akhir yang berkualiti tinggi.
Atas ialah kandungan terperinci Poka Yoke - Penjimatan Projek dengan Pengaturcaraan Hyper -Defensive. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
