Пока-экийн тухай ойлголт (алдаанаас хамгаалах). Пока-Буулгах аргачлалын хэрэглээ (Хиймэл үйлдвэрлэлийн үзэл баримтлал)

Аргын бусад нэрс: "Poka-yoke", "Үл үзэгдэх алдаанаас урьдчилан сэргийлэх".

Аргын зорилго

Одоо байгаа үйлдвэрлэлд алдаа гарахаас урьдчилан сэргийлэх замаар бүтээгдэхүүний ашиглалтын үнэ цэнийг нэмэгдүүлэх.

Аргын мөн чанар

Хүний буруутай үйлдлээс үүдэлтэй хүсээгүй үйл явдлуудаас урьдчилан сэргийлэх ойлголт нь энгийн. Хэрэв тэдгээр нь одоо байгаа үйлдвэрлэлд гарахыг зөвшөөрөхгүй бол чанар нь өндөр байх болно, сайжруулалт нь бага байх болно. Энэ нь хэрэглэгчийн сэтгэл ханамжийг нэмэгдүүлж, үүний зэрэгцээ үйлдвэрлэлийн зардлыг бууруулахад хүргэдэг.

Үйл ажиллагааны төлөвлөгөө

1. Мэргэжилтнүүдийн багийг бүрдүүлэх: удирдлага, чанарын үйлчилгээ, техникийн үйлчилгээболон үйлдвэрлэл.

2. Шийдвэрлэх шаардлагатай асуудлууд, тэдгээрийн оршин тогтнох шалтгааныг тодорхойлох.

3. Пока-йоке аргыг хэрэглэх дүрмийн дагуу үйлдвэрлэлийг сайжруулах, алдаа гарахаас урьдчилан сэргийлэх арга хэмжээг боловсруулах.

4. Үйлдвэрлэлийн процесст сайжруулсан бэхэлгээ, багаж хэрэгсэл, тоног төхөөрөмжийг ашиглах замаар гарч болзошгүй алдааг арилгах.

Аргын онцлог

Poka-yoke (poka-yoke1) гэгддэг алдаанаас хамгаалах орчин үеийн хувилбар нь Японд үйлдвэрлэлийн алдаанаас урьдчилан сэргийлэх замаар бүтээгдэхүүний чанарыг сайжруулах зорилгоор гарч ирэв. Өмнө нь Японы мэргэжилтнүүд baka-yoke гэсэн нэр томъёог ашигладаг байсан. "Бака-буулга" гэсэн нэр томъёоны шууд орчуулга нь "тэнэг байдлаас хамгаалах", өөрөөр хэлбэл энэ нь хамгаалалтын төхөөрөмж, үүнээс болж согогууд ердөө л үүсдэггүй. Энэхүү үзэл баримтлалын үндсэн заалтуудыг Форд 1908 онд өргөнөөр ашиглаж байсныг тэмдэглэх нь зүйтэй.

-ээс эхлээд алдаанаас урьдчилан сэргийлэх олон арга, арга техник байдаг энгийн өөрчлөлтүүдбүтээгдэхүүн үйлдвэрлэх тоног төхөөрөмж, үйл явцын өөрчлөлт, бүтээгдэхүүний дизайны томоохон шинэчлэлтийг дуусгах.

Хэрэглээний жишээ энгийн хүлээн авалталдааны хамгаалалт

Семинарт бүх статистик, тэмдэглэгээ, хяналтыг үл харгалзан хоёр ижил алдаа байнга давтагддаг: блок суурилуулах явцад А хэсэг нь ихэвчлэн 2-р цонхонд дуусдаг ба эсрэгээр В хэсэг нь 1-р цонхонд дуусдаг.

Алдаанаас хамгаалах энгийн арга - poka-yoke нь аливаа алдааг боломжгүй болгодог шийдлийг олох боломжийг олгодог. 1-р цонхны тохиргоо ба угсралтын элемент А-ийн тохиргоог ийм байдлаар өөрчилсөн тул суулгах явцад солих нь онолын хувьд ч боломжгүй юм.

Алдаанаас хамгаалах арга техникийг хэрэглэх дүрэм

1. Асуудлын эх сурвалж, асуудал үнэхээр үүссэн, дахин гарч болох газар руу аль болох ойртоорой.

2. Бүгдийг нэг дор оруулна шаардлагатай төрлүүдхяналт, урьдчилан сэргийлэх арга хэмжээ дахин гарч ирэхАсуудлууд.

3. Боловсруулах, дизайн хийхдээ ашиглах нарийн төвөгтэй аргуудасуудлыг шийдвэрлэх арга техник, үйлдвэрлэлд энгийн бөгөөд хурдан шийдлийг ашиглах.

4. Нарийн төвөгтэй дүн шинжилгээ хийхгүйгээр, бүх хүмүүсийг шийдэлд оруулахуйц үйлдвэрлэлийг хурдан сайжруулна нийтлэг асуудлуудболон үл нийцэх байдлыг арилгах.

Аргын давуу тал

Тогтмол хэрэглээ янз бүрийн арга замуудалдаанаас урьдчилан сэргийлэх арга техник нь тэдний тоог мэдэгдэхүйц бууруулж, зардлыг бууруулж, хэрэглэгчийн сэтгэл ханамжийг нэмэгдүүлэхэд тусалдаг.

Аргын сул тал

Алдаанаас хамгаалах төхөөрөмжийг үйлдвэрлэлд хүчээр нэвтрүүлэхэд тулгардаг эсэргүүцэл нь үйл явцыг сайжруулах хүчин чармайлтыг ихэвчлэн урам хугардаг.

Хүлээгдэж буй үр дүн

Бүтээгдэхүүний хэрэглээний өндөр үнэ цэнэ.

Яг цаг хугацааны арга

Яг цагт (Eng. Just-in-Time, яг цагт) -үндсэн тулгууруудын нэг юм үйлдвэрлэлийн системТоёота, үйлдвэрлэлийг зохион байгуулах арга. Энэ нь үйлдвэрлэлийн явцад угсрахад шаардлагатай эд ангиудыг асааж байгаатай холбоотой юм үйлдвэрлэлийн шугамяг хэрэгтэй үед нь, хатуу шаардлагатай тоо хэмжээ. Үүний үр дүнд энэ зарчмыг тууштай хэрэгжүүлсэн компани нь сул зогсолтыг арилгах, бараа материалын нөөцийг багасгах, эсвэл бараа материалыг тэглэх боломжтой болдог. Үндсэн шинж чанарууд нь шаардлагатай үед зөвхөн шаардлагатай хангамжтай байх; чанарыг "тэг согог" хүртэл сайжруулах; тоног төхөөрөмжийн цаг, дарааллын хэмжээ, үйлдвэрлэлийн багцын хэмжээг багасгах замаар мөчлөгийн хугацааг багасгах; үйл ажиллагааг аажмаар өөрчлөх; мөн эдгээр үйл ажиллагааг хамгийн бага зардлаар гүйцэтгэнэ.

Цаг хугацаанд нь хийх аргыг 1954 онд зохион бүтээжээ. Toyota корпорацид.Энэ нь тухайн үед Японд давамгайлж байсан эдийн засгийн хязгаарлалтын үндсэн дээр үүссэн. Япон байгалийн нөөц багатай, маш их өндөр үнэҮл хөдлөх хөрөнгийн хувьд Японы пүүсүүд илүүдэл барааг хадгалах агуулах гэх мэт бүдүүлэг байдлаас зайлсхийх хэрэгтэй байв.

JIT програмууд

· Үйлдвэрлэлийн бүс дэх JIT - JIT-ийн тусламжтайгаар удирддаг бүрхүүлүүд үйлдвэрлэлийн үйл явц;

· Хүргэлтийн чиглэлээр JIT;

· Борлуулалтын чиглэлээр JIT - онлайн мэдээллийн системд хүсэлтээ илгээдэг олон хэрэглэгчдийн хангамжийг хангадаг.

Японы удирдлага гурван хүсээгүй бүрэлдэхүүн хэсгээс системтэйгээр зайлсхийснээр яг цагтаа хүрдэг.

MURI - илүүдэл

MUDA - алдагдал

MURA - тэнцвэргүй байдал

Ашиг тусыг тодорхойлж болно энэ арга:

· Зардлын бууралтагуулахын нөөцийн засвар үйлчилгээ (агуулах ажилчид, агуулахын тоног төхөөрөмж, түрээс хадгалах байгууламжгэх мэт).

· Захиалгын хугацааг багасгах(багцын хэмжээ багассан, солих хугацаа, сул зогсолтын улмаас).

· Шилдэг баталгааматериал, ханган нийлүүлэгчдийг үйлдвэрлэгчдэд ойртуулсаны улмаас эд анги, хагас боловсруулсан бүтээгдэхүүн (үүнээс гадна ажлын байр нэмэгдүүлэх, бүс нутгийг хөгжүүлэх).

· Урт хугацааны төлөвлөлтханган нийлүүлэгчид болон бараа бүтээгдэхүүний шилдэг борлуулалт.

· Үйлдвэрлэлийг оновчтой болгохнийлүүлэгчдийг захиалсан бараагаар мэргэшүүлэх замаар.

Боломжит асуудлуудпрограмууд :

· Тээвэрлэлт, тээврийн маршрутын зохион байгуулалтын зардал өндөр (зам дээр ачаалал ихтэй, түгжрэл үүсэх магадлал, тээвэрлэлтээс үүдэлтэй дуу чимээ).

· Нэг ханган нийлүүлэгчээс өндөр хамааралтай (хүргэх хугацааг дагаж мөрдөөгүй тохиолдолд үйлдвэрлэлийн алдагдал гарах боломжтой).

Нийлүүлсэн материалын чанарыг дагаж мөрдөхөөс ихээхэн хамааралтай (зардал оролтын хяналт, гомдол).

· Тогтмол мэдээлэл солилцох шаардлагатай (нийлүүлэгч, үйлдвэрлэгчийн санхүүгийн байдлыг баталгаажуулах үүрэг).

Хүргэлтийн огноог дагаж мөрдөөгүйн улмаас ханган нийлүүлэгчид өндөр торгууль ногдуулдаг. өндөр хамааралтайнэг хэрэглэгчээс.

· Нийлүүлэгчид үйлдвэрлэл, агуулахыг хэрэглэгчдэд ойртуулах хэрэгцээ.

· Их хэмжээний алдагдалхямралын нөхцөлд мэргэшсэн нийлүүлэгчид.

  • Орчуулга

Сайн уу! Би бол Badoo серверийн багийн хөгжүүлэгч Алексей Грезов. Badoo-д бид өөрсдийн кодыг хадгалах, боловсруулах, дахин ашиглахад хялбар болгохыг үргэлж хичээдэг, учир нь эдгээр параметрүүд нь аливаа функцийг хэр хурдан, үр дүнтэй хэрэгжүүлэхийг тодорхойлдог. Энэ зорилгодоо хүрэх нэг арга бол зүгээр л алдаа гаргахгүй код бичих явдал юм. Хамгийн хатуу интерфейс нь дуудлагын дарааллаар алдаа гаргахыг зөвшөөрөхгүй. Хамгийн бага хэмжээ дотоод мужуудхүлээгдэж буй үр дүнг баталгаажуулдаг. Нөгөө өдөр би эдгээр аргуудыг ашиглах нь хөгжүүлэгчдийн амьдралыг хэрхэн хөнгөвчлөх талаар тайлбарласан нийтлэлийг харсан. Ингээд та бүхний анхааралд "пока-ёоке" зарчмын тухай өгүүллийн орчуулгыг хүргэж байна.


At хамтарсан ажилкомандын дунд кодтой эсвэл том хэмжээЗаримдаа хэн нэгний кодыг ойлгох, ашиглахад бэрхшээлтэй байдаг. Энэ асуудал бий янз бүрийн шийдэл. Жишээлбэл, та тодорхой кодчиллын стандартыг дагаж мөрдөх эсвэл бүхэл бүтэн багийн мэддэг тогтолцоог ашиглахыг зөвшөөрч болно. Гэсэн хэдий ч, энэ нь ихэвчлэн хангалтгүй, ялангуяа алдаа засах эсвэл нэмэх шаардлагатай үед шинэ шинж тэмдэгхуучин код руу. Тодорхой ангиудыг ямар зорилгоор зохион бүтээсэн, тэд дангаараа болон хамтдаа хэрхэн ажиллах ёстойг санахад хэцүү байдаг. Ийм мөчид та санамсаргүйгээр нэмж болно сөрөг нөлөөэсвэл өөрөө ч мэдэлгүй алдаа гаргадаг.


Туршилтын явцад эдгээр алдааг олж болно, гэхдээ байдаг бодит боломжТэд үйлдвэрлэл рүү хальтирна гэж. Хэдийгээр тэдгээр нь олдсон ч кодыг буцааж, засахад нэлээд хугацаа шаардагдана.


Тэгвэл бид үүнээс хэрхэн сэргийлэх вэ? "Poka-yoke" зарчмын тусламжтайгаар.

Пока ёке гэж юу вэ?

Пока-ёоке гэдэг нь япон хэлнээс орчуулбал "алдаанаас хамгаалах" (алдаанаас хамгаалах) гэсэн утгатай бөгөөд оросоор "тэнэг хамгаалах" гэж илүү сайн мэддэг. Энэхүү үзэл баримтлал нь туранхай үйлдвэрлэлээс үүссэн бөгөөд энэ нь машины операторыг алдаа гаргахаас зайлсхийхэд тусалдаг аливаа механизмыг хэлдэг.


Үйлдвэрлэлээс гадна poka-yoke нь ихэвчлэн хэрэглээний цахилгаан хэрэгсэлд ашиглагддаг. Жишээлбэл, тэгш бус хэлбэрийн улмаас адаптерт зөвхөн баруун талдаа оруулах боломжтой SIM картыг ав.



Эсрэг жишээ (ашиглахгүйгээр poka-yoke зарчим) нь гар болон хулгана хоёуланд нь ижил холбогч хэлбэртэй PS/2 порт юм. Тэдгээрийг зөвхөн өнгөөр ​​нь ялгаж чаддаг тул амархан андуурдаг.



Гэсэн хэдий ч пока буулга ойлголтпрограмчлалд ашиглаж болно. Гол санаа нь манай кодын нийтийн интерфейсийг аль болох энгийн бөгөөд ойлгомжтой болгож, кодыг буруу ашигласан даруйд алдаа гаргах явдал юм. Энэ нь ойлгомжтой мэт санагдаж болох ч үнэндээ бид ийм кодгүй кодтой байнга тааралддаг.


Poka-yoke нь санаатайгаар хүчирхийллээс урьдчилан сэргийлэх зорилготой биш гэдгийг анхаарна уу. Зорилго нь зөвхөн санамсаргүй алдаанаас зайлсхийх явдал бөгөөд кодыг хорлонтой ашиглахаас хамгаалах явдал биш юм. Ямар нэг байдлаар, хэн нэгэн таны код руу нэвтрэх эрхтэй л бол үнэхээр хүсвэл гал хамгаалагчийг тойрч гарах боломжтой.


Кодыг илүү алдаа гаргахгүй болгох тодорхой арга хэмжээний талаар ярихаас өмнө пока-ёке механизмыг хоёр төрөлд хувааж болохыг мэдэх нь чухал юм.

  • алдаанаас урьдчилан сэргийлэх
  • алдаа илрүүлэх.

Алдаанаас урьдчилан сэргийлэх механизм нь алдааг эрт үе шатанд арилгахад тустай. Интерфэйс болон зан үйлийг аль болох хялбарчилснаар бид хэн ч манай кодыг санамсаргүйгээр буруугаар ашиглахгүй байх баталгаа (SIM картын жишээг бодоорой).


Нөгөө талаас алдаа илрүүлэх механизм нь манай кодын гадна байдаг. Тэд хянахын тулд манай програмуудыг хянадаг болзошгүй алдаамөн тэдний талаар бидэнд анхааруул. Жишээ нь PS/2 порттой холбогдсон төхөөрөмж байгаа эсэхийг тодорхойлох програм хангамж байж болно зөв төрөл, хэрэв үгүй ​​бол яагаад ажиллахгүй байгааг хэрэглэгчдэд хэлнэ. Ийм програм хангамж чадахгүй урьдчилан сэргийлэхалдаа нь холбогч нь ижил, гэхдээ боломжтой нээхтүүнийг мэдээлнэ үү.


Дараах зүйлд бид програмуудынхаа алдаанаас урьдчилан сэргийлэх, илрүүлэхэд ашиглаж болох хэд хэдэн арга техникийг авч үзэх болно. Гэхдээ энэ жагсаалт нь зөвхөн эхлэлийн цэг гэдгийг санаарай. Тусгай хэрэглээнээс хамааран кодыг алдаа гаргахгүй болгох нэмэлт арга хэмжээ авч болно. Энэ нь таны төсөлд poka-yoke хэрэгжүүлэх нь зүйтэй гэдэгт итгэлтэй байх нь бас чухал юм: таны хэрэглээний нарийн төвөгтэй байдал, хэмжээнээс хамааран зарим арга хэмжээ нь алдааны боломжит өртөгтэй харьцуулахад хэтэрхий үнэтэй байж болно. Тиймээс аль арга хэмжээ нь танд хамгийн сайн тохирохыг та болон танай хамт олон шийднэ.

Алдаанаас урьдчилан сэргийлэх жишээ

Тунхаглалын төрөл

Өмнө нь PHP 5-д Type Hinting гэж нэрлэгддэг байсан бөгөөд төрлийн мэдэгдлүүд нь PHP 7-д функц, аргуудыг дуудах үед гарах алдаанаас хамгаалах хялбар арга юм. Функцийн аргументуудад тодорхой төрлүүд оноож өгснөөр аргументуудыг дуудах үед аргументуудын дарааллыг зөрчихөд хэцүү болдог. функц.


Жишээлбэл, хэрэглэгч рүү илгээж болох мэдэгдлийг авч үзье:


userId = $userId; $this->сэдэв = $сэдэв; $this->мессеж = $мессеж; ) нийтийн функц getUserId() ( $this->userId буцаана; ) нийтийн функц getSubject() ( $this->сэдвийг буцаана; ) getMessage() нийтийн функц ($this->месsage буцаана; ))

Төрөл мэдэгдэлгүйгээр та буруу төрлийн хувьсагчийг санамсаргүйгээр оруулах боломжтой бөгөөд энэ нь таны програмыг эвдэж болзошгүй юм. Жишээ нь, бид $userId нь мөр байх ёстой гэж таамаглаж болох боловч үнэн хэрэгтээ энэ нь int байж болно.


Хэрэв бид буруу төрлийг бүтээгчид дамжуулвал програм энэ мэдэгдлээр ямар нэг зүйл хийхийг оролдох хүртэл алдаа анзаарагдахгүй байх магадлалтай. Энэ үед бид ямар нэгэн нууцлаг алдааны мессежийг хүлээн авах бөгөөд энэ нь бидний код руу юу ч зааж өгөхгүй байх магадлалтай бөгөөд бид int-ийн оронд мөрийг дамжуулж байна. Тиймээс хөгжүүлэлтийн явцад ийм алдааг аль болох эрт илрүүлэхийн тулд програмыг аль болох хурдан завсарлах нь илүү дээр юм.


Энэ тохиолдолд бид зүгээр л төрлийн мэдэгдлийг нэмж болно - бид буруу төрлийн параметрийг дамжуулахыг оролдох үед PHP зогсох бөгөөд аюултай алдааны талаар шууд анхааруулах болно:


userId = $userId; $this->сэдэв = $сэдэв; $this->мессеж = $мессеж; ) нийтийн функц getUserId() : int ( $this->userId буцаана; ) нийтийн функц getSubject() : string ( $this->сэдвийг буцаана; ) нийтийн функц getMessage() : string ( $this->message буцаана; ) )

Анхдагчаар PHP нь хүчингүй аргументуудыг хүлээгдэж буй төрлүүддээ оруулахыг оролдох болно гэдгийг анхаарна уу. Үүнээс зайлсхийх, аюултай алдаа гаргахын тулд хатуу бичихийг (strict_types) идэвхжүүлэх нь чухал юм. Ийм учраас скаляр төрлүүдийг зарлах нь poka-yoke-ийн хамгийн тохиромжтой хэлбэр биш боловч алдааг багасгах сайн эхлэл юм. Хүчтэй бичихийг идэвхгүй болгосон ч төрлийн мэдэгдлүүд нь ямар төрлийн аргумент хүлээж байгааг илтгэх болно.


Нэмж дурдахад бид аргууддаа буцаах төрлүүдийг зарласан. Энэ нь тодорхой функцийг дуудах үед ямар утгыг хүлээж болохыг тодорхойлоход хялбар болгодог.


Сайн тодорхойлогдсон буцаах төрлүүд нь буцаах утгуудтай харьцахдаа олон шилжүүлэгч мэдэгдлээс зайлсхийхэд тустай байдаг, учир нь өгөөжийн төрлийг тодорхой зарлаагүй бол манай аргууд өөр өөр төрлийг буцаах боломжтой. Тиймээс, бидний аргыг ашигладаг хэн нэгэн тухайн тохиолдолд ямар төрлийг буцаасан болохыг шалгах шаардлагатай болно. Мэдээжийн хэрэг, та солих мэдэгдлийн талаар мартаж болох бөгөөд энэ нь илрүүлэхэд хэцүү алдаа гаргахад хүргэдэг. Гэхдээ функцийн буцаах төрлийг зарлахад тэдгээр нь хамаагүй бага тохиолддог.

Үнэт зүйлийн объектууд

Төрөл бүрийн мэдэгдлүүдийг шийдэж чадахгүй байгаа асуудал бол функцэд олон аргументтай байх нь тэдгээрийг дуудах үед дарааллыг нь холих боломжийг олгодог явдал юм.


Аргументууд өөр өөр төрөлтэй үед PHP нь дараалалгүй аргументуудын талаар бидэнд анхааруулж болох боловч хэрэв бидэнд ижил төрлийн олон аргумент байгаа бол энэ нь ажиллахгүй.


Энэ тохиолдолд алдаа гарахаас зайлсхийхийн тулд бид аргументуудаа утгын объектуудад боож болно:


class UserId ( private $userId; public function __construct(int $userId) ( $this->userId = $userId; ) public function getValue() : int ( return $this->userId; ) ) class Subject ( private $subject; нийтийн функц __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) , Мессеж $ мессеж) ( $this->userId = $userId; $this->subject = $subject; $this->message = $message; ) public function getUserId() : UserId ( /* ... */ ) нийтийн функц getSubject() : Гарчиг ( /* ... */ ) нийтийн функц getMessage() : Зурвас ( /* ... */ ) )

Бидний аргументууд одоо маш тодорхой төрлийн байдаг тул тэдгээрийг холих нь бараг боломжгүй юм.


Скаляр төрлүүдийг зарлахаас илүү утгын объектыг ашиглахын нэмэлт давуу тал бол бид файл болгонд хүчтэй бичих шаардлагагүй болсон явдал юм. Хэрэв бид үүнийг санах шаардлагагүй бол бид үүнийг мартаж чадахгүй.

Баталгаажуулалт

Үнэт зүйлийн объектуудтай ажиллахдаа бид өгөгдлийн баталгаажуулалтын логикоо объект дотроо багтааж болно. Ийм байдлаар бид хүчингүй төлөвтэй үнэ цэнийн объект үүсгэхээс урьдчилан сэргийлэх боломжтой бөгөөд энэ нь бидний хэрэглээний бусад давхаргад ирээдүйд асуудал үүсгэж болзошгүй юм.


Жишээлбэл, бид аливаа UserId үргэлж эерэг байх ёстой гэсэн дүрэмтэй байж болно. Бид UserId-г оролт болгон авах бүрдээ үүнийг шалгаж болох боловч нөгөө талаас үүнийг нэг газар эсвэл өөр газар амархан мартдаг. Хэдийгээр энэ мартамхай байдал нь манай програмын өөр давхаргад бодит алдаа гаргахад хүргэсэн ч алдааны мэдээнээс яг юу нь буруу болсныг ойлгоход хэцүү байж болох бөгөөд энэ нь дибаг хийхийг улам хүндрүүлнэ.


Иймэрхүү алдаанаас урьдчилан сэргийлэхийн тулд бид UserId бүтээгч дээр зарим баталгаажуулалтыг нэмж болно:


class UserId ( private $userId; нийтийн функц __construct($userId) (хэрэв (!is_int($userId) || $userId)< 0) { throw new \InvalidArgumentException("UserId should be a positive integer."); } $this->userId = $userId; ) нийтийн функц getValue() : int ( $this->userId буцаана; ) )

Тиймээс бид UserId объекттой ажиллахдаа зөв төлөвтэй байгаа гэдэгт үргэлж итгэлтэй байж болно. Энэ нь биднийг програмын янз бүрийн түвшний өгөгдлийг байнга шалгахаас аврах болно.


Бид энд is_int-г ашиглахын оронд скаляр төрлийн мэдэгдлийг нэмж болох боловч энэ нь UserId ашигласан газар бүрт хүчтэй бичихийг шаардах болно гэдгийг анхаарна уу. Хэрэв үүнийг хийхгүй бол PHP нь бусад төрлүүдийг UserId болгон дамжуулах болгонд int руу шилжүүлэхийг оролдох болно. Энэ нь асуудал болж магадгүй, учир нь бид жишээ нь float-д дамжуулж болох бөгөөд энэ нь хэрэглэгчийн ID нь ихэвчлэн хөвөгч биш учраас зөв хувьсагч биш байж магадгүй юм. Жишээлбэл, Price объекттой ажиллах боломжтой бусад тохиолдолд PHP нь float хувьсагчдыг int руу автоматаар хөрвүүлдэг тул хүчтэй бичихийг унтраах нь дугуйлах алдаа гарахад хүргэдэг.

хувиршгүй байдал

Анхдагч байдлаар, PHP дахь объектуудыг лавлагаагаар дамжуулдаг. Энэ нь бид объектод өөрчлөлт оруулахад тэр даруй программ даяар өөрчлөгддөг гэсэн үг юм.


Энэ арга нь давуу талтай хэдий ч зарим сул талуудтай. SMS болон имэйлээр хэрэглэгч рүү илгээсэн мэдэгдлийн жишээг авч үзье.


Interface NotificationSenderInterface ( нийтийн функц илгээх(Мэдэгдэл $мэдэгдэл); ) анги SMSNotificationSender NotificationSenderInterface-ийг хэрэгжүүлдэг ( нийтийн функц илгээх(Мэдэгдэл $мэдэгдэл) ( $this->cutNotificationLength($мэдэгдэл); // SMS илгээх... ) /** * */ хувийн функц cutNotificationLength(Notification $notification) ( $message = $notification->getMessage(); $messageString = substr($message->getValue(), 160) ; $notification->setMessage(new Message($messageString) ); ) ) анги EmailNotificationSender NotificationSenderInterface-ийг хэрэгжүүлдэг ( нийтийн функц илгээх(Мэдэгдэл $мэдээлэл) ( // Имэйл илгээх ... ) ) $smsNotificationSender = шинэ SMSNotificationSender() ; $emailNotificationSender = шинэ EmailNotificationSender(); $мэдэгдэл = шинэ мэдэгдэл(шинэ UserId(17466), шинэ Subject("Demo мэдэгдэл"), шинэ мессеж("Маш урт мессеж... 160 гаруй тэмдэгт.")); $smsNotificationSender->илгээх($мэдэгдэл); $emailNotificationSender->илгээх($мэдэгдэл);

Мэдэгдлийн объектыг лавлагаагаар дамжуулдаг тул энэ нь хүсээгүй гаж нөлөө үзүүлдэг. SMSNotificationSender дахь мессежийн уртыг богиносгох үед холбогдох мэдэгдлийн объектыг програмын турш шинэчилсэн бөгөөд дараа нь EmailNotificationSender руу илгээх үед мессежийг мөн таслав.


Үүнийг засахын тулд Notification объектыг өөрчлөгддөггүй болгоё. Түүнд өөрчлөлт оруулах тодорхой аргуудыг оруулахын оронд эдгээр өөрчлөлтийг хийхээсээ өмнө анхны мэдэгдлийн хуулбарыг хийх аргуудыг нэмж оруулъя:


анги Мэдэгдэл ( нийтийн функц __construct(...) ( /* ... */ ) нийтийн функц getUserId() : UserId ( /* ... */ ) UserId(UserId $userId) бүхий нийтийн функц : Мэдэгдэл ( $c = Clone $this; $c->userId = clone $userId; return $c; ) public function getSubject() : Subject ( /* ... */ ) public function withSubject(Subject $subject) : Мэдэгдэл ( $c = clone) $ this; $c->subject = clone $subject; return $c; ) public function getMessage() : Message ( /* ... */ ) public function withMessage(Message $message): Мэдэгдэл ( $c = clone $) энэ; $c->мессеж = клон $мессеж; $c буцаана;))

Одоо бид мэдэгдлийн ангилалд мессежийн уртыг богиносгох зэрэг өөрчлөлтүүдийг хийх үед тэдгээр нь бүх програмд ​​хамаарахаа больсон нь янз бүрийн гаж нөлөөнөөс урьдчилан сэргийлэхэд тусалдаг.


Гэсэн хэдий ч PHP дээр объектыг үнэхээр хувиршгүй болгох нь маш хэцүү (хэрэв боломжгүй бол) гэдгийг анхаарна уу. Гэхдээ манай кодыг алдаа гаргахгүй болгохын тулд тухайн ангийн хэрэглэгчид өөрчлөлт хийхээсээ өмнө объектыг хувилахаа санах шаардлагагүй тул тогтоосон аргуудын оронд аргуудыг "өөрчлөгдөхгүй" гэж нэмэхэд хангалттай.

Хүчингүй объектуудыг буцаана

Заримдаа бид ямар нэг утга эсвэл null буцаах функц, аргуудтай тааралддаг. Эдгээр хоосон утгууд нь асуудал үүсгэж болзошгүй тул бид тэдэнтэй юу ч хийхээс өмнө бараг үргэлж тэг утгыг шалгах шаардлагатай болдог. Дахин хэлэхэд үүнийг мартах нь амархан.


Буцах утгыг шалгахаас зайлсхийхийн тулд бид оронд нь null объектуудыг буцааж болно. Жишээлбэл, бид хямдралтай эсвэл хөнгөлөлтгүй худалдааны сагстай байж болно:


интерфэйс Хямдрал ( нийтийн функц applyTo(int $total);) интерфэйс ShoppingCart ( нийтийн функц accountTotal() : int; нийтийн функц getDiscount() : ?Хөнгөлөлт; )

ShoppingCart-ийн эцсийн үнийг тооцоолохдоо applyTo аргыг дуудахаасаа өмнө getDiscount() функц нь тэг эсвэл хямдралтай байгаа эсэхийг шалгах хэрэгтэй.


$нийт = $shoppingCart->тооцоололтоо(); хэрэв ($shoppingCart->getDiscount()) ( $total = $shoppingCart->getDiscount()->applyTo($total); )

Хэрэв бид энэ шалгалтыг хийхгүй бол getDiscount() null утгыг буцаах үед бид PHP-ийн анхааруулга болон/эсвэл бусад гаж нөлөөг авах болно.


Нөгөөтэйгүүр, хөнгөлөлт үзүүлээгүй тохиолдолд бид тэг объектыг буцаавал эдгээр шалгалтаас зайлсхийх боломжтой.


class ShoppingCart ( нийтийн функц getDiscount() : Хөнгөлөлт ( буцах !is_null($this->хямдрал) ? $this->хөнгөлөлт: new NoDiscount(); ) ) анги NoDiscount хэрэгжүүлдэг Discount ( нийтийн функц applyTo(int $total) ( буцах) $нийт;))

Одоо бид getDiscount() гэж дуудахдаа хөнгөлөлт байхгүй байсан ч гэсэн үргэлж Discount объектыг авдаг. Ингэснээр бид хөнгөлөлт байхгүй байсан ч нийт дүнгийн хэмжээнд хэрэглэж болох бөгөөд if хэллэг хэрэггүй болно.


$нийт = $shoppingCart->тооцоололтоо(); $totalWithDiscountApplied = $shoppingCart->getDiscount()->applyTo($total);

Нэмэлт хамаарал

Үүнтэй адил шалтгааны улмаас бид тэг буцах утгуудаас зайлсхийхийг хүсч байгаа бөгөөд бүх хамаарлыг шаардлагатай болгосноор нэмэлт хамаарлаас ангижрахыг хүсч байна.


Жишээлбэл, дараахь ангиллыг авч үзье.


анги SomeService нь LoggerAwareInterface ( нийтийн функц setLogger(LoggerInterface $logger) ( /* ... */ ) нийтийн функц doSomething() ( if ($this->logger) ( $this->logger->debug("... "); ) // ямар нэг зүйл хий, хэрэв ($this->logger) ( $this->logger->warning("..."); ) // гэх мэт... ) )

Хоёр асуудал байна:

  1. Бид doSomething() аргадаа логгер байгаа эсэхийг байнга шалгаж байх шаардлагатай.
  2. Манай үйлчилгээний контейнерт SomeService классыг тохируулах үед хэн нэгэн бүртгэл хөтлөгчийг тохируулахаа мартаж магадгүй, эсвэл тэр анги нь үүнийг хийх чадвартай гэдгийг мэдэхгүй байж магадгүй юм.

LoggerInterface-г шаардлагатай хамаарал болгосноор бид кодыг хялбарчилж чадна:


class SomeService ( нийтийн функц __construct(LoggerInterface $logger) ( /* ... */ ) нийтийн функц doSomething() ( $this->logger->debug("..."); // ямар нэг зүйл хий $this-> бүртгэл хөтлөгч->ануулга("..."); // гэх мэт... ) )

Одоо манай нийтийн интерфэйс арай төвөгтэй болсон бөгөөд хэн нэгэн SomeService-ийн шинэ жишээ үүсгэх бүрд анги нь LoggerInterface-ийн жишээг шаарддаг гэдгийг мэддэг тул үүнийг зааж өгөхөө мартах арга байхгүй.


Бид мөн бүртгэл хөтлөгч байгаа эсэхийг байнга шалгах хэрэгцээг арилгасан бөгөөд энэ нь doSomething()-г ойлгоход хялбар бөгөөд хэн нэгэн түүнд өөрчлөлт оруулах бүрт алдаа гарах магадлал багатай болгодог.


Хэрэв бид SomeService-ийг бүртгэл хөтлөгчгүйгээр ашиглахыг хүсвэл null объектыг буцаахтай ижил логикийг ашиглаж болно:


$үйлчилгээ = шинэ SomeService(шинэ NullLogger());

Эцсийн эцэст энэ арга нь нэмэлт setLogger() аргыг ашиглахтай адил үр дүнтэй боловч бидний кодыг хялбарчилж, хамаарлын тарилгын саванд алдаа гарах магадлалыг бууруулдаг.

Нийтийн аргууд

Кодыг ашиглахад хялбар болгохын тулд ангиудад нийтийн аргуудын тоог хязгаарлах нь дээр. Дараа нь код нь ойлгомжгүй болж, бид рефакторинг хийхдээ буцаах нийцтэй байдлаас татгалзах магадлал багатай.


Нийтийн аргуудын тоог хамгийн бага хэмжээнд хүргэхийн тулд гүйлгээний аналоги нь туслах болно. Жишээлбэл, хоёр банкны данс хооронд мөнгө шилжүүлэхийг авч үзье.


$account1->татаж авах(100); $account2->хадгаламж(100);

Хэдийгээр өгөгдлийн сан нь гүйлгээгээр дамжуулан мөнгө байршуулах боломжгүй (эсвэл эсрэгээр) тохиолдолд буцаан олголтыг цуцлахыг баталгаажуулж чаддаг ч $account1->withdraw() эсвэл $account2->deposit() гэж залгахаа мартахаас сэргийлж чадахгүй. ), энэ нь буруу ажиллахад хүргэдэг.


Аз болоход бид хоёр тусдаа аргыг нэг гүйлгээний аргаар сольсноор үүнийг хялбархан засаж чадна:


$account1->шилжүүлэх(100, $account2);

Үүний үр дүнд гүйлгээг хэсэгчлэн дуусгаснаар алдаа гаргахад илүү хэцүү байх тул бидний код илүү найдвартай болж байна.

Алдаа илрүүлэх жишээ

Алдаа илрүүлэх механизм нь тэдгээрээс урьдчилан сэргийлэх зорилготой биш юм. Тэд зөвхөн асуудал илэрсэн үед л бидэнд мэдэгдэх ёстой. Ихэнхдээ тэд манай програмаас гадуур байдаг бөгөөд тодорхой давтамжтайгаар эсвэл тодорхой өөрчлөлтүүдийн дараа кодыг шалгадаг.

Нэгжийн туршилтууд

Нэгжийн тест нь шинэ код зөв ажиллаж байгаа эсэхийг шалгах гайхалтай арга байж болно. Тэд мөн хэн нэгэн системийн хэсгийг дахин засварласны дараа код зөв ажиллаж байгаа эсэхийг шалгахад тусалдаг.


Хэн нэгэн нэгжийн тест хийхээ мартаж болзошгүй тул Travis CI болон GitLab CI зэрэг үйлчилгээг ашиглан өөрчлөлт хийх үед тестийг автоматаар ажиллуулах нь зүйтэй. Тэдний ачаар ямар нэг зүйл эвдэрсэн үед хөгжүүлэгчид мэдэгддэг бөгөөд энэ нь хийсэн өөрчлөлтүүд зориулалтын дагуу ажиллахад тусалдаг.


Алдааг илрүүлэхээс гадна нэгжийн тестүүд нь кодын тодорхой хэсгийг ашиглах гайхалтай жишээ бөгөөд энэ нь эргээд хэн нэгэн бидний кодыг ашиглах үед алдаа гарахаас сэргийлдэг.

Кодын хамрах хүрээний тайлан, мутацийн туршилт

Бид хангалттай тест бичихээ мартаж болох тул комбинзон гэх мэт үйлчилгээг ашиглан кодын хамрах хүрээний тайланг автоматаар үүсгэхийн тулд тест хийхэд хэрэгтэй. Бидний кодын хамрах хүрээ багасах бүрт комбинезон бидэнд мэдэгдэл илгээдэг тул бид дутуу тестүүдийг нэмж оруулах боломжтой. Комбинелийн ачаар бид кодын хамрах хүрээ цаг хугацааны явцад хэрхэн өөрчлөгдөж байгааг ойлгох боломжтой.


Бидэнд хангалттай нэгж тест байгаа эсэхийг шалгах өөр нэг арга бол Humbug гэх мэт мутацийн тестийг ашиглах явдал юм. Нэрнээс нь харахад тэд эх кодыг бага зэрэг өөрчилж, дараа нь нэгжийн тестийг ажиллуулж, бидний кодыг тестэд хангалттай хамруулсан эсэхийг шалгадаг бөгөөд энэ нь хийсэн өөрчлөлтийн улмаас алдаа гаргах болно.


Кодын хамрах хүрээний тайлан, мутацийн туршилтыг ашиглан бид нэгжийн туршилтууд алдаанаас урьдчилан сэргийлэхэд хангалттай эсэхийг баталгаажуулж чадна.

Статик кодын анализаторууд

Код анализаторууд нь бидний программ дахь алдааг боловсруулах үйл явцын эхэн үед илрүүлж чаддаг. Жишээлбэл, PhpStorm гэх мэт IDE нь код анализаторыг ашиглан алдааны талаар анхааруулж, код бичих явцад бидэнд зөвлөгөө өгдөг. Алдаа нь энгийн синтакс алдаанаас эхлээд давтагдах код хүртэл байж болно.


Ихэнх IDE-д суурилуулсан анализаторуудаас гадна гуравдагч талын, тэр ч байтугай захиалгат анализаторуудыг тодорхой асуудлуудыг тодорхойлохын тулд манай програмуудыг бүтээх процесст оруулж болно. PHP төслүүдэд тохирох задлагчдын хэсэгчилсэн жагсаалтыг GitHub дээрээс олж болно.

Мод бэлтгэх

Алдаа илрүүлэх бусад ихэнх механизмуудаас ялгаатай нь бүртгэл нь програмыг үйлдвэрлэлд ажиллаж байх үед алдааг илрүүлэхэд тусалдаг.


Мэдээжийн хэрэг, энэ нь гэнэтийн зүйл тохиолдоход кодыг бүртгэлд бичихийг шаарддаг. Манай код бүртгэл хөтлөгчийг дэмждэг байсан ч программыг тохируулахдаа тэдгээрийг мартаж болно. Тиймээс нэмэлт хамаарлаас зайлсхийх хэрэгтэй (дээрхийг үзнэ үү).


Хэдийгээр ихэнх программууд бүртгэлийн зарим хэсгийг хөтөлдөг ч тэнд бичигдсэн мэдээлэл нь Кибана эсвэл Нагиос гэх мэт хэрэглүүрүүдийг ашиглан дүн шинжилгээ хийж, хянаж байх үед үнэхээр сонирхолтой болдог. Тэд манай програмыг туршиж байх үед биш харин хүмүүс идэвхтэй ашиглаж байх үед ямар төрлийн алдаа, сэрэмжлүүлгийг олж мэдэх боломжтой.

Алдааг дарж болохгүй

Бүртгэлийн алдаа гарсан ч заримыг нь дарах тохиолдол гардаг. PHP нь "сэргээгдэх" алдаа гарах үед үргэлжлүүлэн ажиллах хандлагатай байдаг. Гэсэн хэдий ч алдаанууд нь шинэ функцуудыг хөгжүүлэх эсвэл турших үед хэрэг болно, учир нь тэдгээр нь таны кодын алдааг илтгэдэг. Ийм учраас ихэнх код анализаторууд таныг алдаа дарахын тулд @ ашиглаж байгааг илрүүлэхдээ анхааруулдаг, учир нь энэ нь програмыг ашигласны дараа дахин гарч ирэх алдааг нууж чаддаг.


Ерөнхий дүрмээр бол PHP-ийн алдааны тайлангийн түвшинг E_ALL гэж тохируулах нь хамгийн сайн арга бөгөөд ингэснээр өчүүхэн ч гэсэн анхааруулга мэдээлдэг. Гэсэн хэдий ч, эдгээр мессежийг хаа нэгтээ бүртгэж, хэрэглэгчдээс нууж байгаарай, ингэснээр эцсийн хэрэглэгчдэд таны програмын бүтэц эсвэл болзошгүй эмзэг байдлын талаарх эмзэг мэдээлэл байхгүй болно.


error_reporting-ээс гадна strict_types-ийг үргэлж оруулах нь чухал бөгөөд ингэснээр PHP нь функцын аргументуудыг хүлээгдэж буй төрөлд нь автоматаар дамжуулахыг оролддоггүй, учир нь энэ нь олоход хэцүү алдаа (хөвөгчийг int руу дамжуулах үед дугуйрсан алдаа гэх мэт) үүсгэж болзошгүй. .

PHP-ээс гадуурх хэрэглээ

Poka-yoke нь тодорхой арга техник гэхээсээ илүү ойлголт учраас PHP-ийн бус хэсэгт ч ашиглаж болно.

Дэд бүтэц

Дэд бүтцийн түвшинд Vagrant гэх мэт хэрэгслүүдийг ашиглан үйлдвэрлэлийн орчинтой ижил төстэй хамтын хөгжлийн орчныг бий болгосноор олон алдаанаас урьдчилан сэргийлэх боломжтой.


Jenkins болон GoCD зэрэг бүтээх серверүүдийг ашиглан програмын байршуулалтыг автоматжуулах нь програмд ​​өөрчлөлт оруулах үед алдаа гарахаас сэргийлж чадна, учир нь энэ үйл явц нь олон алхмуудыг агуулж болох бөгөөд заримыг нь мартахад хялбар байдаг.

REST API

REST API үүсгэх үед API-г ашиглахад хялбар болгох үүднээс poka-yoke тарьж болно. Жишээлбэл, URL эсвэл хүсэлтийн хэсэгт үл мэдэгдэх параметр дамжих үед бид алдаа гаргаж байгаа эсэхийг шалгах боломжтой. Бид API үйлчлүүлэгчдээ "эвдүүлэхээс" зайлсхийхийг хүсч байгаа тул энэ нь хачирхалтай мэт санагдаж магадгүй ч хөгжүүлэлтийн явцад алдааг засахын тулд API-г буруугаар ашиглахыг хөгжүүлэгчдэд аль болох хурдан анхааруулах нь дээр.


Жишээлбэл, бидний API-д өнгөний параметр байж болох ч манай API-г ашигладаг хэн нэгэн санамсаргүйгээр өнгөний параметрийг ашиглаж болзошгүй. Ямар ч анхааруулгагүйгээр энэ алдаа нь эцсийн хэрэглэгчид үүнийг анзаарах хүртэл үйлдвэрлэлд амархан орж болно.


Танд төвөг учруулахгүй API-г хэрхэн бүтээх талаар сурахын тулд "Та үзэн ядахгүй API-г бий болгох" номыг уншина уу.

Хэрэглээний тохиргоо

Бараг бүх програмууд нь ямар нэгэн тохируулга шаарддаг. Ихэнхдээ хөгжүүлэгчид аль болох олон үндсэн тохиргоог өгдөг бөгөөд энэ нь тохиргоог хялбар болгодог. Гэсэн хэдий ч өнгө, өнгөний жишээн дээрх шиг тохиргооны тохиргоог буруу бичих нь амархан бөгөөд энэ нь програмыг санамсаргүйгээр өгөгдмөл рүү буцаахад хүргэдэг.


Аппликешн нь ийм алдаа гаргадаггүй тул ийм мөчүүдийг хянахад хэцүү байдаг. Тохиргоо буруу болсныг мэдэгдэх хамгийн сайн арга бол ямар ч анхдагч тохиргоог оруулахгүй байх, тохиргооны параметр алга болмогц алдаа гаргах явдал юм.

Хэрэглэгчийн алдаанаас урьдчилан сэргийлэх

Мөн poka-yoke концепцийг хэрэглэгчийн алдаанаас урьдчилан сэргийлэх, илрүүлэхэд ашиглаж болно. Жишээлбэл, нягтлан бодох бүртгэлийн програм хангамжид хэрэглэгчийн оруулсан дансны дугаарыг шалгах цифрийн алгоритм ашиглан шалгаж болно. Энэ нь таныг дансны дугаарыг буруу бичихээс сэргийлнэ.

Дүгнэлт

Хэдийгээр poka-yoke нь зөвхөн ойлголт бөгөөд тодорхой хэрэгсэл биш боловч алдаанаас урьдчилан сэргийлэх эсвэл тэдгээрийг эрт илрүүлэхэд туслах код болон хөгжүүлэлтийн процесст хэрэглэж болох янз бүрийн зарчмууд байдаг. Ихэнхдээ эдгээр механизмууд нь програмын өөрөө болон бизнесийн логиктой холбоотой байх боловч аливаа кодыг илүү бат бөх болгоход ашиглаж болох хэд хэдэн энгийн арга, хэрэгслүүд байдаг.


Санаж байх ёстой гол зүйл бол бид үйлдвэрлэлийн алдаанаас зайлсхийхийг хүсч байгаа хэдий ч тэдгээр нь хөгжүүлэлтийн явцад маш их хэрэгтэй байж болох бөгөөд тэдгээрийг хянахад хялбар болгохын тулд аль болох хурдан эхлүүлэхээс айх ёсгүй. Эдгээр алдааг код өөрөө эсвэл програмаас тусад нь ажиллуулж, гаднаас нь удирддаг тусдаа процессоор үүсгэж болно.


Алдааны тоог цаашид багасгахын тулд бид кодын нийтийн интерфейсийг аль болох энгийн бөгөөд ойлгомжтой байлгахыг хичээх хэрэгтэй.

Шошго: шошго нэмэх

Поке-эка системийн үүссэн түүх

1961 онд Шинго Yamaha Electric компаниудын үйлдвэрлэлийн бүтцэд дүн шинжилгээ хийхдээ бака-ёке (тэнэггүй) аргыг боловсруулсан. Тэрээр нийтээр хүлээн зөвшөөрөгдсөн статистикийн хяналтын тогтолцоо нь гэрлэхэд саад болохгүй гэсэн дүгнэлтэд хүрчээ. Мэдээжийн хэрэг, түүний тусламжтайгаар дараагийн согогийн магадлалын түвшинг урьдчилан таамаглах боломжтой байсан ч энэ нь зөвхөн баримтын мэдэгдэл байх болно. Шинго хяналтыг процесст өөрөө оруулахаар шийджээ. Эцсийн эцэст, гэрлэлт нь хүний ​​алдааны үр дүнд бий болдог. Алдаа гарах нь мэдээжийн хэрэг, гэхдээ санал хүсэлт бүхий машин, багаж хэрэгсэл бүтээх замаар урьдчилан сэргийлэх боломжтой. Хэсгийг буруу оруулах гэсэн оролдлого нь ажил зогсоход хүргэв. Ажилтан ямар нэгэн ажиллагаа хийхээ мартсан тохиолдолд дохиолол ч ирсэн. Алдаа гарсны дараа түүнийг илрүүлэх, тодорхойлох, дахин гарах магадлалаас бүрэн урьдчилан сэргийлэх ажлыг дагаж мөрдөнө. Ийнхүү Шигео Шинго учир шалтгааныг үр дагавараас буюу алдааг согогоос салгаж, бүтээгдэхүүний чанарыг 100% баталгаажуулав. Эцсийн эцэст, чанарын хяналтыг чанарын хяналтын ширээн дээр дээж авах замаар биш, харин бүх бүтээгдэхүүн дээр шууд машин хэрэгсэл дээр хийсэн. Үр дүн нь удахгүй гараагүй. Тухайлбал, 1977 онд Шинго системийг нэвтрүүлсэн Мацушита Электрик компанийн үйлдвэрлэлийн цехүүд 7 сар ямар ч доголдолгүй ажилласан. С.Шинго гадаад дотоодод "Ноён сайжруулалт" гэдэг нэрийг зүй ёсоор ашиглаж эхэлсэн.

"Тэнэгээс хамгаалах" нэрийг эсэргүүцэж чадаагүй нь үнэн. Нэг удаа Шинго шинэ аргыг ажилчдад танилцуулж байхад нэг ажилчин "Би тэнэг биш!" Би уучлалт гуйж, энэ аргыг шинэ нэрээр нэрлэх ёстой байсан: пока-ёке систем (согогоос хамгаалах, эсвэл 0-гажиг). Энэхүү систем нь үйлдвэрлэлийн үйл явцын үр ашгийг эрс нэмэгдүүлж, хог хаягдлыг бууруулах, зардал, цаг хугацаа алдахад тусалдаг.

Баяртай аргын тухай ойлголт

Согоггүй үйлдвэрлэл нь Poka-Yoke хэмээх алдаанаас хамгаалах арга дээр суурилдаг. "Пока-эка" системийг орос хэл рүү "тэнэггүй" гэж орчуулж болно.

Гол санаа нь согог илэрсэн даруйд үйл явцыг зогсоож, шалтгааныг тодорхойлж, доголдлын эх үүсвэр дахин гарахаас урьдчилан сэргийлэх явдал юм. Тиймээс статистикийн түүвэрлэлт хийх шаардлагагүй. Процедурын гол хэсэг бол алдааны эх үүсвэрийг шалгах нь алдаа согог болохоос нь өмнө илрүүлэхийн тулд үйлдвэрлэлийн процессын идэвхтэй хэсэг болгон хийгддэг явдал юм. Алдааг олж илрүүлэх нь түүнийг засах хүртэл үйлдвэрлэлийг зогсооно, эсвэл алдаа гарахаас урьдчилан сэргийлэхийн тулд үйл явцыг засна. Энэ нь боломжит алдааны эх үүсвэрийг хянах замаар үйл явцын үе шат бүрт хийгддэг. Ингэж байж согогийг дараагийн үе шатанд бус эх сурвалж дээр нь илрүүлж засдаг. Мэдээжийн хэрэг, энэ үйл явц нь шууд санал хүсэлт бүхий багаж хэрэгсэл, механизмыг ашигласнаар боломжтой болсон (энэ явцад алдаа гаргах чадвараас шалтгаалан боловсон хүчний хэрэглээнээс зайлсхийдэг). Гэсэн хэдий ч алдааны боломжит эх үүсвэрийг тодорхойлохын тулд боловсон хүчнийг ашиглах нь чухал юм. Шинго 40 настайдаа статистикийн чанарын хяналтын аргад ихээхэн суралцаж, хэрэглэж байсан ч 20 жилийн дараа буюу 1977 онд эцэст нь тэдний илбийн увидасаас ангижирсан гэж хэлжээ. Шизүока дахь Мацушита угаалгын машины үйлдвэрийн 23 ажилчинтай ус зайлуулах хоолой угсрах шугам "Пока-" төхөөрөмж суурилуулсны ачаар бүтэн сарын турш нэг ч доголдолгүй тасралтгүй ажиллаж байсныг тэр өөрийн нүдээр гэрчлэх үед болсон юм. Йеке", энэ нь согог үүсэхээс сэргийлсэн. Шинго согогийн эх үүсвэрийн хяналт болон Пока-Йеке системийг ашиглан согоггүй байдалд хүрч чадна гэж мэдэгджээ. Тэд хамтдаа "Тэг чанарын хяналт"-ыг бүрдүүлдэг.

Энэхүү "тэг согог" гэсэн ойлголт нь ихэвчлэн Америкийн зөвлөгч Филип Кросбигийн нэртэй холбоотой ойлголтоос өөр юм. Шингогийн үзэл баримтлал нь Америк болон Баруун Европын пүүсүүдийн чанартай кампанит ажилтай холбоотой уриа лоозон, уриа лоозон гэхээсээ илүү сайн үйлдвэрлэлийн инженерчлэл, үйл явцын судалгааг ашиглах замаар 0 доголдолд хүрэхийг онцолдог. Шинго өөрөө Деминг, Журан нарын нэгэн адил Америкийн энэхүү арга барилд санаа зовж байгаагаа илэрхийлж, согогийн статистикийг нийтлэх нь зөвхөн төөрөгдөл бөгөөд үүний оронд ихэнх бүтээгдэхүүний согогийг үүсгэдэг үйлдвэрлэлийн процессын согогтой элементүүдийг хайж олох шаардлагатай гэж үздэг.

"Пока-эка" систем нь согоггүй үйлдвэрлэлийн үндэс суурь юм.

Үйлдвэрлэлийн доголдол нь ихэвчлэн үйл явцын шинж чанарын хэлбэлзэл ихэссэнтэй холбоотой бөгөөд энэ нь эргээд дараахь үр дагавар байж болно.

- буруу боловсруулсан стандарт эсвэл баримтжуулсан журам;

* чанар муутай эсвэл хуучирсан тоног төхөөрөмж ашиглах;

* тохиромжгүй материал ашиглах;

* багаж хэрэгслийн элэгдэл, элэгдэл;

* операторын алдаа.

Сүүлийн нэгийг эс тооцвол эдгээр бүх согогийн шалтгааныг арилгах, урьдчилан сэргийлэх арга хэмжээ авах боломжтой. Операторын алдаанаас урьдчилан сэргийлэх нь нэлээд хэцүү байдаг.

Поке-эка үзэл суртлын гол цөм нь хүн ажлын явцад алдаа гаргах нь зүйн хэрэг юм. Мөн энэ нь операторын мэргэжлийн бус байдлын үзүүлэлт биш юм. Поке-экийн зорилго нь санамсаргүй алдаанаас хамгаалах арга замыг олох явдал юм. Согог үүсэхэд хүргэдэг операторуудын ердийн үйлдлийн жагсаалтыг хүснэгтэд үзүүлэв.

Поке-эка арга нь долоон зарчим дээр суурилдаг.

1 үр ашигтай үйл явцыг бий болгохын тулд бат бөх дизайн ашиглах;

2 багаар ажиллах: энэ бол ажилчдын мэдлэгийг дээд зэргээр ашиглах цорын ганц арга зам юм;

3 алдааг арилгах, мөн бат бөх дизайн ашиглан: энэ нь алдааны тоог тэг рүү ойртуулна;

4 "Яагаад" 5 аргыг хэрэглэснээр согогийн үндсэн шалтгааныг арилгах (Таван "яагаад");

5 яаралтай арга хэмжээ авах, боломжтой бүх нөөцийг ашиглах;

6 үнэ цэнэ нэмдэггүй үйл ажиллагааг хасах;

7 сайжруулалтыг хэрэгжүүлж, цаашид сайжруулах талаар даруй бодох хэрэгтэй.

Poké-eka алдааг олохын тулд операторууд өөрсдөө найдаж болохгүй. Тиймээс ажил гүйцэтгэхдээ мэдрэгчтэй мэдрэгч болон бусад төхөөрөмжийг ашигладаг. Энэ нь операторуудын үл тоомсорлож буй согогийг үр дүнтэй тодорхойлоход тусалдаг.

Поке-эка аргыг орцны хяналт болон бүх процессын аль алинд нь хэрэглэнэ. Үүнийг хэрэгжүүлэх үр нөлөө нь процессын аль үе шатанд - оролтын хяналт эсвэл үйл явцын хяналт - энэ аргыг ашигласан эсэхээс хамаарна. Үүний зэрэгцээ хэрэв зөрчил илэрсэн бол анхааруулах дохио хүлээн авах эсвэл бүр тоног төхөөрөмжийг зогсоож болно.

Орцны удирдлагад поке-эка аргыг нэвтрүүлэхийг идэвхтэй арга гэж нэрлэдэг. Энэ тохиолдолд алдаа илрүүлэх нь тодорхой үйлдлүүд хийгдэхээс өмнө, анхааруулах дохиог ашиглахаас өмнө эсвэл гаралтын удирдлага дээр төхөөрөмжийг зогсоох хүртэл тохиолддог.

Поке-эка аргыг үйлдвэрлэлийн үйл явцын бусад үе шатанд хэрэглэх аргыг реактив гэж нэрлэдэг. Энэ тохиолдолд энэ аргыг хэрэглэнэ:

* үйл явц дууссаны дараа шууд;

* операторын ажил гүйцэтгэх явцад;

* үйл явцын дараагийн шатанд шилжих үед.

Реактив арга нь үр дүнтэй байдаг, учир нь энэ нь гэмтэлтэй зүйлсийг дараагийн алхам руу шилжүүлэхээс урьдчилан сэргийлэхэд тусалдаг боловч идэвхтэй хандалтын үеийнх шиг алдаанаас хамгаалах өндөр түвшинд хүрч чаддаггүй. Согогийн шалтгааныг хайх явцад поке-эка аргыг ашиглах нь өндөр үр дүн өгдөггүй, гэхдээ сонгомол хяналтаас хамаагүй илүү үр дүнтэй байдаг.

Поке-эка аргыг ашиглах өөр аргууд байдаг: хянах, сэрэмжлүүлэх. Хяналтын арга барилаар, хэрэв согог илэрсэн бол төхөөрөмжийг автоматаар зогсооно. Урьдчилан сэргийлэх арга нь янз бүрийн дохиоллын хэрэгслийг (гэрэл ба дуут дохио) ашиглахад суурилдаг бөгөөд энэ нь болзошгүй алдааны талаар операторыг мэдээлдэг. Тоног төхөөрөмжийг зогсоох нь ихэвчлэн урьдчилан сэргийлэх аргын нэг хэсэг биш юм.

Poke-eka-д ашигладаг төхөөрөмжүүдийг ажлын үндсэн аргын дагуу дараахь байдлаар хуваана.

* холбоо барих;

* унших;

* дараалсан хөдөлгөөн.

Бүх гурван төрлийн төхөөрөмжийг хяналтын арга болон анхааруулах арга барилд ашиглаж болно.

Холбоо барих аргын төхөөрөмжүүдийн ажиллах зарчим нь мэдрэмтгий элемент нь шалгаж буй объекттой харьцаж байгаа эсэхийг тодорхойлоход суурилдаг. Хязгаарлалтын унтраалга нь ийм төхөөрөмжүүдийн жишээ юм. Хэрэв контакт эвдэрсэн бол жишээлбэл, дуут дохио гарч ирнэ.

Мөн контактын аргаар ажилладаг төхөөрөмжүүдэд дамжуулагч ба хүлээн авагч, фотоэлектрик унтраалга, пьезоэлектрик мэдрэгч гэх мэт төхөөрөмжүүд орно.Төхөөрөмжүүд нь өндөр технологитой байх албагүй. Энгийн идэвхгүй төхөөрөмжүүд заримдаа хамгийн шилдэг нь байдаг. Тэд процессын явцад хэсгүүдийг буруу байрлалд оруулахыг зөвшөөрдөггүй.

Үйл явц дахь тодорхой тооны үйлдлүүд болон бүтээгдэхүүнд тодорхой тооны хэсгүүд байх үед уншигчдыг ашигладаг. Мэдрэгч нь эд ангиудыг хэд хэдэн удаа тоолж, зөвхөн хэсгүүдийн тоо зөв байвал дараагийн процесс руу дамжуулдаг.

Гурав дахь төрлийн төхөөрөмж нь процессын ажиллагаа дууссан эсэхийг тодорхойлох мэдрэгч юм. Хэрэв үйл ажиллагаа хийгдээгүй эсвэл буруу хийгдсэн бол мэдрэгч нь төхөөрөмжийг зогсоох шаардлагатай гэсэн дохио өгдөг. Олон тооны мэдрэхүйн болон фотоэлектрик төхөөрөмжүүд энэ зарчим дээр ажилладаг бөгөөд энэ нь тоног төхөөрөмжийн таймертай холбоотой байдаг. Ийм төхөөрөмжийг ашиглах нь үйл явцад хэлбэр, хэмжээтэй ижил төстэй олон хэсгүүдийг ашиглах үед хамгийн үр дүнтэй байдаг.

Поке-эка аргыг тууштай хэрэгжүүлснээр операторуудын гаргасан алдааны тоог мэдэгдэхүйц бууруулж, зардлыг бууруулж, хэрэглэгчийн сэтгэл ханамжийг нэмэгдүүлэхэд тусалдаг.

  • Орчуулга

Сайн уу! Би бол Badoo серверийн багийн хөгжүүлэгч Алексей Грезов. Badoo-д бид өөрсдийн кодыг хадгалах, боловсруулах, дахин ашиглахад хялбар болгохыг үргэлж хичээдэг, учир нь эдгээр параметрүүд нь аливаа функцийг хэр хурдан, үр дүнтэй хэрэгжүүлэхийг тодорхойлдог. Энэ зорилгодоо хүрэх нэг арга бол зүгээр л алдаа гаргахгүй код бичих явдал юм. Хамгийн хатуу интерфейс нь дуудлагын дарааллаар алдаа гаргахыг зөвшөөрөхгүй. Дотоод мужуудын хамгийн бага тоо нь хүлээгдэж буй үр дүнг баталгаажуулдаг. Нөгөө өдөр би эдгээр аргуудыг ашиглах нь хөгжүүлэгчдийн амьдралыг хэрхэн хөнгөвчлөх талаар тайлбарласан нийтлэлийг харсан. Ингээд та бүхний анхааралд "пока-ёоке" зарчмын тухай өгүүллийн орчуулгыг хүргэж байна.


Дунд болон том багт код дээр хамтран ажиллах үед заримдаа хэн нэгний кодыг ойлгох, ашиглахад хэцүү байдаг. Энэ асуудал нь янз бүрийн шийдэлтэй. Жишээлбэл, та тодорхой кодчиллын стандартыг дагаж мөрдөх эсвэл бүхэл бүтэн багийн мэддэг тогтолцоог ашиглахыг зөвшөөрч болно. Гэсэн хэдий ч, энэ нь ихэвчлэн хангалтгүй, ялангуяа алдаа засах эсвэл хуучин кодонд шинэ функц нэмэх шаардлагатай үед. Тодорхой ангиудыг ямар зорилгоор зохион бүтээсэн, тэд дангаараа болон хамтдаа хэрхэн ажиллах ёстойг санахад хэцүү байдаг. Ийм үед санамсаргүй байдлаар гаж нөлөө, алдааг өөрөө ч анзааралгүйгээр нэмэх боломжтой.


Эдгээр алдааг туршилтын явцад илрүүлж болох ч үйлдвэрлэлд нэвтэрч орох бодит боломж бий. Хэдийгээр тэдгээр нь олдсон ч кодыг буцааж, засахад нэлээд хугацаа шаардагдана.


Тэгвэл бид үүнээс хэрхэн сэргийлэх вэ? "Poka-yoke" зарчмын тусламжтайгаар.

Пока ёке гэж юу вэ?

Пока-ёоке гэдэг нь япон хэлнээс орчуулбал "алдаанаас хамгаалах" (алдаанаас хамгаалах) гэсэн утгатай бөгөөд оросоор "тэнэг хамгаалах" гэж илүү сайн мэддэг. Энэхүү үзэл баримтлал нь туранхай үйлдвэрлэлээс үүссэн бөгөөд энэ нь машины операторыг алдаа гаргахаас зайлсхийхэд тусалдаг аливаа механизмыг хэлдэг.


Үйлдвэрлэлээс гадна poka-yoke нь ихэвчлэн хэрэглээний цахилгаан хэрэгсэлд ашиглагддаг. Жишээлбэл, тэгш бус хэлбэрийн улмаас адаптерт зөвхөн баруун талдаа оруулах боломжтой SIM картыг ав.



Үүний эсрэг жишээ (poka-yoke зарчмыг ашиглахгүйгээр) нь гар, хулгана хоёуланд нь ижил холбогч хэлбэртэй PS / 2 порт юм. Тэдгээрийг зөвхөн өнгөөр ​​нь ялгаж чаддаг тул амархан андуурдаг.



Poka-yoke-ийн өөр нэг ойлголтыг програмчлалд ашиглаж болно. Гол санаа нь манай кодын нийтийн интерфейсийг аль болох энгийн бөгөөд ойлгомжтой болгож, кодыг буруу ашигласан даруйд алдаа гаргах явдал юм. Энэ нь ойлгомжтой мэт санагдаж болох ч үнэндээ бид ийм кодгүй кодтой байнга тааралддаг.


Poka-yoke нь санаатайгаар хүчирхийллээс урьдчилан сэргийлэх зорилготой биш гэдгийг анхаарна уу. Зорилго нь зөвхөн санамсаргүй алдаанаас зайлсхийх явдал бөгөөд кодыг хорлонтой ашиглахаас хамгаалах явдал биш юм. Ямар нэг байдлаар, хэн нэгэн таны код руу нэвтрэх эрхтэй л бол үнэхээр хүсвэл гал хамгаалагчийг тойрч гарах боломжтой.


Кодыг илүү алдаа гаргахгүй болгох тодорхой арга хэмжээний талаар ярихаас өмнө пока-ёке механизмыг хоёр төрөлд хувааж болохыг мэдэх нь чухал юм.

  • алдаанаас урьдчилан сэргийлэх
  • алдаа илрүүлэх.

Алдаанаас урьдчилан сэргийлэх механизм нь алдааг эрт үе шатанд арилгахад тустай. Интерфэйс болон зан үйлийг аль болох хялбарчилснаар бид хэн ч манай кодыг санамсаргүйгээр буруугаар ашиглахгүй байх баталгаа (SIM картын жишээг бодоорой).


Нөгөө талаас алдаа илрүүлэх механизм нь манай кодын гадна байдаг. Тэд боломжит алдааг хянахын тулд бидний програмуудыг хянаж, бидэнд анхааруулдаг. Жишээ нь, PS/2 порттой холбогдсон төхөөрөмж зөв төрөлтэй эсэхийг тодорхойлох програм хангамж байж болох бөгөөд хэрэв тийм биш бол яагаад ажиллахгүй байгааг хэрэглэгчдэд хэлдэг. Ийм програм хангамж чадахгүй урьдчилан сэргийлэхалдаа нь холбогч нь ижил, гэхдээ боломжтой нээхтүүнийг мэдээлнэ үү.


Дараах зүйлд бид програмуудынхаа алдаанаас урьдчилан сэргийлэх, илрүүлэхэд ашиглаж болох хэд хэдэн арга техникийг авч үзэх болно. Гэхдээ энэ жагсаалт нь зөвхөн эхлэлийн цэг гэдгийг санаарай. Тусгай хэрэглээнээс хамааран кодыг алдаа гаргахгүй болгох нэмэлт арга хэмжээ авч болно. Энэ нь таны төсөлд poka-yoke хэрэгжүүлэх нь зүйтэй гэдэгт итгэлтэй байх нь бас чухал юм: таны хэрэглээний нарийн төвөгтэй байдал, хэмжээнээс хамааран зарим арга хэмжээ нь алдааны боломжит өртөгтэй харьцуулахад хэтэрхий үнэтэй байж болно. Тиймээс аль арга хэмжээ нь танд хамгийн сайн тохирохыг та болон танай хамт олон шийднэ.

Алдаанаас урьдчилан сэргийлэх жишээ

Тунхаглалын төрөл

Өмнө нь PHP 5-д Type Hinting гэж нэрлэгддэг байсан бөгөөд төрлийн мэдэгдлүүд нь PHP 7-д функц, аргуудыг дуудах үед гарах алдаанаас хамгаалах хялбар арга юм. Функцийн аргументуудад тодорхой төрлүүд оноож өгснөөр аргументуудыг дуудах үед аргументуудын дарааллыг зөрчихөд хэцүү болдог. функц.


Жишээлбэл, хэрэглэгч рүү илгээж болох мэдэгдлийг авч үзье:


userId = $userId; $this->сэдэв = $сэдэв; $this->мессеж = $мессеж; ) нийтийн функц getUserId() ( $this->userId буцаана; ) нийтийн функц getSubject() ( $this->сэдвийг буцаана; ) getMessage() нийтийн функц ($this->месsage буцаана; ))

Төрөл мэдэгдэлгүйгээр та буруу төрлийн хувьсагчийг санамсаргүйгээр оруулах боломжтой бөгөөд энэ нь таны програмыг эвдэж болзошгүй юм. Жишээ нь, бид $userId нь мөр байх ёстой гэж таамаглаж болох боловч үнэн хэрэгтээ энэ нь int байж болно.


Хэрэв бид буруу төрлийг бүтээгчид дамжуулвал програм энэ мэдэгдлээр ямар нэг зүйл хийхийг оролдох хүртэл алдаа анзаарагдахгүй байх магадлалтай. Энэ үед бид ямар нэгэн нууцлаг алдааны мессежийг хүлээн авах бөгөөд энэ нь бидний код руу юу ч зааж өгөхгүй байх магадлалтай бөгөөд бид int-ийн оронд мөрийг дамжуулж байна. Тиймээс хөгжүүлэлтийн явцад ийм алдааг аль болох эрт илрүүлэхийн тулд програмыг аль болох хурдан завсарлах нь илүү дээр юм.


Энэ тохиолдолд бид зүгээр л төрлийн мэдэгдлийг нэмж болно - бид буруу төрлийн параметрийг дамжуулахыг оролдох үед PHP зогсох бөгөөд аюултай алдааны талаар шууд анхааруулах болно:


userId = $userId; $this->сэдэв = $сэдэв; $this->мессеж = $мессеж; ) нийтийн функц getUserId() : int ( $this->userId буцаана; ) нийтийн функц getSubject() : string ( $this->сэдвийг буцаана; ) нийтийн функц getMessage() : string ( $this->message буцаана; ) )

Анхдагчаар PHP нь хүчингүй аргументуудыг хүлээгдэж буй төрлүүддээ оруулахыг оролдох болно гэдгийг анхаарна уу. Үүнээс зайлсхийх, аюултай алдаа гаргахын тулд хатуу бичихийг (strict_types) идэвхжүүлэх нь чухал юм. Ийм учраас скаляр төрлүүдийг зарлах нь poka-yoke-ийн хамгийн тохиромжтой хэлбэр биш боловч алдааг багасгах сайн эхлэл юм. Хүчтэй бичихийг идэвхгүй болгосон ч төрлийн мэдэгдлүүд нь ямар төрлийн аргумент хүлээж байгааг илтгэх болно.


Нэмж дурдахад бид аргууддаа буцаах төрлүүдийг зарласан. Энэ нь тодорхой функцийг дуудах үед ямар утгыг хүлээж болохыг тодорхойлоход хялбар болгодог.


Сайн тодорхойлогдсон буцаах төрлүүд нь буцаах утгуудтай харьцахдаа олон шилжүүлэгч мэдэгдлээс зайлсхийхэд тустай байдаг, учир нь өгөөжийн төрлийг тодорхой зарлаагүй бол манай аргууд өөр өөр төрлийг буцаах боломжтой. Тиймээс, бидний аргыг ашигладаг хэн нэгэн тухайн тохиолдолд ямар төрлийг буцаасан болохыг шалгах шаардлагатай болно. Мэдээжийн хэрэг, та солих мэдэгдлийн талаар мартаж болох бөгөөд энэ нь илрүүлэхэд хэцүү алдаа гаргахад хүргэдэг. Гэхдээ функцийн буцаах төрлийг зарлахад тэдгээр нь хамаагүй бага тохиолддог.

Үнэт зүйлийн объектууд

Төрөл бүрийн мэдэгдлүүдийг шийдэж чадахгүй байгаа асуудал бол функцэд олон аргументтай байх нь тэдгээрийг дуудах үед дарааллыг нь холих боломжийг олгодог явдал юм.


Аргументууд өөр өөр төрөлтэй үед PHP нь дараалалгүй аргументуудын талаар бидэнд анхааруулж болох боловч хэрэв бидэнд ижил төрлийн олон аргумент байгаа бол энэ нь ажиллахгүй.


Энэ тохиолдолд алдаа гарахаас зайлсхийхийн тулд бид аргументуудаа утгын объектуудад боож болно:


class UserId ( private $userId; public function __construct(int $userId) ( $this->userId = $userId; ) public function getValue() : int ( return $this->userId; ) ) class Subject ( private $subject; нийтийн функц __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) , Мессеж $ мессеж) ( $this->userId = $userId; $this->subject = $subject; $this->message = $message; ) public function getUserId() : UserId ( /* ... */ ) нийтийн функц getSubject() : Гарчиг ( /* ... */ ) нийтийн функц getMessage() : Зурвас ( /* ... */ ) )

Бидний аргументууд одоо маш тодорхой төрлийн байдаг тул тэдгээрийг холих нь бараг боломжгүй юм.


Скаляр төрлүүдийг зарлахаас илүү утгын объектыг ашиглахын нэмэлт давуу тал бол бид файл болгонд хүчтэй бичих шаардлагагүй болсон явдал юм. Хэрэв бид үүнийг санах шаардлагагүй бол бид үүнийг мартаж чадахгүй.

Баталгаажуулалт

Үнэт зүйлийн объектуудтай ажиллахдаа бид өгөгдлийн баталгаажуулалтын логикоо объект дотроо багтааж болно. Ийм байдлаар бид хүчингүй төлөвтэй үнэ цэнийн объект үүсгэхээс урьдчилан сэргийлэх боломжтой бөгөөд энэ нь бидний хэрэглээний бусад давхаргад ирээдүйд асуудал үүсгэж болзошгүй юм.


Жишээлбэл, бид аливаа UserId үргэлж эерэг байх ёстой гэсэн дүрэмтэй байж болно. Бид UserId-г оролт болгон авах бүрдээ үүнийг шалгаж болох боловч нөгөө талаас үүнийг нэг газар эсвэл өөр газар амархан мартдаг. Хэдийгээр энэ мартамхай байдал нь манай програмын өөр давхаргад бодит алдаа гаргахад хүргэсэн ч алдааны мэдээнээс яг юу нь буруу болсныг ойлгоход хэцүү байж болох бөгөөд энэ нь дибаг хийхийг улам хүндрүүлнэ.


Иймэрхүү алдаанаас урьдчилан сэргийлэхийн тулд бид UserId бүтээгч дээр зарим баталгаажуулалтыг нэмж болно:


class UserId ( private $userId; нийтийн функц __construct($userId) (хэрэв (!is_int($userId) || $userId)< 0) { throw new \InvalidArgumentException("UserId should be a positive integer."); } $this->userId = $userId; ) нийтийн функц getValue() : int ( $this->userId буцаана; ) )

Тиймээс бид UserId объекттой ажиллахдаа зөв төлөвтэй байгаа гэдэгт үргэлж итгэлтэй байж болно. Энэ нь биднийг програмын янз бүрийн түвшний өгөгдлийг байнга шалгахаас аврах болно.


Бид энд is_int-г ашиглахын оронд скаляр төрлийн мэдэгдлийг нэмж болох боловч энэ нь UserId ашигласан газар бүрт хүчтэй бичихийг шаардах болно гэдгийг анхаарна уу. Хэрэв үүнийг хийхгүй бол PHP нь бусад төрлүүдийг UserId болгон дамжуулах болгонд int руу шилжүүлэхийг оролдох болно. Энэ нь асуудал болж магадгүй, учир нь бид жишээ нь float-д дамжуулж болох бөгөөд энэ нь хэрэглэгчийн ID нь ихэвчлэн хөвөгч биш учраас зөв хувьсагч биш байж магадгүй юм. Жишээлбэл, Price объекттой ажиллах боломжтой бусад тохиолдолд PHP нь float хувьсагчдыг int руу автоматаар хөрвүүлдэг тул хүчтэй бичихийг унтраах нь дугуйлах алдаа гарахад хүргэдэг.

хувиршгүй байдал

Анхдагч байдлаар, PHP дахь объектуудыг лавлагаагаар дамжуулдаг. Энэ нь бид объектод өөрчлөлт оруулахад тэр даруй программ даяар өөрчлөгддөг гэсэн үг юм.


Энэ арга нь давуу талтай хэдий ч зарим сул талуудтай. SMS болон имэйлээр хэрэглэгч рүү илгээсэн мэдэгдлийн жишээг авч үзье.


Interface NotificationSenderInterface ( нийтийн функц илгээх(Мэдэгдэл $мэдэгдэл); ) анги SMSNotificationSender NotificationSenderInterface-ийг хэрэгжүүлдэг ( нийтийн функц илгээх(Мэдэгдэл $мэдэгдэл) ( $this->cutNotificationLength($мэдэгдэл); // SMS илгээх... ) /** * */ хувийн функц cutNotificationLength(Notification $notification) ( $message = $notification->getMessage(); $messageString = substr($message->getValue(), 160) ; $notification->setMessage(new Message($messageString) ); ) ) анги EmailNotificationSender NotificationSenderInterface-ийг хэрэгжүүлдэг ( нийтийн функц илгээх(Мэдэгдэл $мэдээлэл) ( // Имэйл илгээх ... ) ) $smsNotificationSender = шинэ SMSNotificationSender() ; $emailNotificationSender = шинэ EmailNotificationSender(); $мэдэгдэл = шинэ мэдэгдэл(шинэ UserId(17466), шинэ Subject("Demo мэдэгдэл"), шинэ мессеж("Маш урт мессеж... 160 гаруй тэмдэгт.")); $smsNotificationSender->илгээх($мэдэгдэл); $emailNotificationSender->илгээх($мэдэгдэл);

Мэдэгдлийн объектыг лавлагаагаар дамжуулдаг тул энэ нь хүсээгүй гаж нөлөө үзүүлдэг. SMSNotificationSender дахь мессежийн уртыг богиносгох үед холбогдох мэдэгдлийн объектыг програмын турш шинэчилсэн бөгөөд дараа нь EmailNotificationSender руу илгээх үед мессежийг мөн таслав.


Үүнийг засахын тулд Notification объектыг өөрчлөгддөггүй болгоё. Түүнд өөрчлөлт оруулах тодорхой аргуудыг оруулахын оронд эдгээр өөрчлөлтийг хийхээсээ өмнө анхны мэдэгдлийн хуулбарыг хийх аргуудыг нэмж оруулъя:


анги Мэдэгдэл ( нийтийн функц __construct(...) ( /* ... */ ) нийтийн функц getUserId() : UserId ( /* ... */ ) UserId(UserId $userId) бүхий нийтийн функц : Мэдэгдэл ( $c = Clone $this; $c->userId = clone $userId; return $c; ) public function getSubject() : Subject ( /* ... */ ) public function withSubject(Subject $subject) : Мэдэгдэл ( $c = clone) $ this; $c->subject = clone $subject; return $c; ) public function getMessage() : Message ( /* ... */ ) public function withMessage(Message $message): Мэдэгдэл ( $c = clone $) энэ; $c->мессеж = клон $мессеж; $c буцаана;))

Одоо бид мэдэгдлийн ангилалд мессежийн уртыг богиносгох зэрэг өөрчлөлтүүдийг хийх үед тэдгээр нь бүх програмд ​​хамаарахаа больсон нь янз бүрийн гаж нөлөөнөөс урьдчилан сэргийлэхэд тусалдаг.


Гэсэн хэдий ч PHP дээр объектыг үнэхээр хувиршгүй болгох нь маш хэцүү (хэрэв боломжгүй бол) гэдгийг анхаарна уу. Гэхдээ манай кодыг алдаа гаргахгүй болгохын тулд тухайн ангийн хэрэглэгчид өөрчлөлт хийхээсээ өмнө объектыг хувилахаа санах шаардлагагүй тул тогтоосон аргуудын оронд аргуудыг "өөрчлөгдөхгүй" гэж нэмэхэд хангалттай.

Хүчингүй объектуудыг буцаана

Заримдаа бид ямар нэг утга эсвэл null буцаах функц, аргуудтай тааралддаг. Эдгээр хоосон утгууд нь асуудал үүсгэж болзошгүй тул бид тэдэнтэй юу ч хийхээс өмнө бараг үргэлж тэг утгыг шалгах шаардлагатай болдог. Дахин хэлэхэд үүнийг мартах нь амархан.


Буцах утгыг шалгахаас зайлсхийхийн тулд бид оронд нь null объектуудыг буцааж болно. Жишээлбэл, бид хямдралтай эсвэл хөнгөлөлтгүй худалдааны сагстай байж болно:


интерфэйс Хямдрал ( нийтийн функц applyTo(int $total);) интерфэйс ShoppingCart ( нийтийн функц accountTotal() : int; нийтийн функц getDiscount() : ?Хөнгөлөлт; )

ShoppingCart-ийн эцсийн үнийг тооцоолохдоо applyTo аргыг дуудахаасаа өмнө getDiscount() функц нь тэг эсвэл хямдралтай байгаа эсэхийг шалгах хэрэгтэй.


$нийт = $shoppingCart->тооцоололтоо(); хэрэв ($shoppingCart->getDiscount()) ( $total = $shoppingCart->getDiscount()->applyTo($total); )

Хэрэв бид энэ шалгалтыг хийхгүй бол getDiscount() null утгыг буцаах үед бид PHP-ийн анхааруулга болон/эсвэл бусад гаж нөлөөг авах болно.


Нөгөөтэйгүүр, хөнгөлөлт үзүүлээгүй тохиолдолд бид тэг объектыг буцаавал эдгээр шалгалтаас зайлсхийх боломжтой.


class ShoppingCart ( нийтийн функц getDiscount() : Хөнгөлөлт ( буцах !is_null($this->хямдрал) ? $this->хөнгөлөлт: new NoDiscount(); ) ) анги NoDiscount хэрэгжүүлдэг Discount ( нийтийн функц applyTo(int $total) ( буцах) $нийт;))

Одоо бид getDiscount() гэж дуудахдаа хөнгөлөлт байхгүй байсан ч гэсэн үргэлж Discount объектыг авдаг. Ингэснээр бид хөнгөлөлт байхгүй байсан ч нийт дүнгийн хэмжээнд хэрэглэж болох бөгөөд if хэллэг хэрэггүй болно.


$нийт = $shoppingCart->тооцоололтоо(); $totalWithDiscountApplied = $shoppingCart->getDiscount()->applyTo($total);

Нэмэлт хамаарал

Үүнтэй адил шалтгааны улмаас бид тэг буцах утгуудаас зайлсхийхийг хүсч байгаа бөгөөд бүх хамаарлыг шаардлагатай болгосноор нэмэлт хамаарлаас ангижрахыг хүсч байна.


Жишээлбэл, дараахь ангиллыг авч үзье.


анги SomeService нь LoggerAwareInterface ( нийтийн функц setLogger(LoggerInterface $logger) ( /* ... */ ) нийтийн функц doSomething() ( if ($this->logger) ( $this->logger->debug("... "); ) // ямар нэг зүйл хий, хэрэв ($this->logger) ( $this->logger->warning("..."); ) // гэх мэт... ) )

Хоёр асуудал байна:

  1. Бид doSomething() аргадаа логгер байгаа эсэхийг байнга шалгаж байх шаардлагатай.
  2. Манай үйлчилгээний контейнерт SomeService классыг тохируулах үед хэн нэгэн бүртгэл хөтлөгчийг тохируулахаа мартаж магадгүй, эсвэл тэр анги нь үүнийг хийх чадвартай гэдгийг мэдэхгүй байж магадгүй юм.

LoggerInterface-г шаардлагатай хамаарал болгосноор бид кодыг хялбарчилж чадна:


class SomeService ( нийтийн функц __construct(LoggerInterface $logger) ( /* ... */ ) нийтийн функц doSomething() ( $this->logger->debug("..."); // ямар нэг зүйл хий $this-> бүртгэл хөтлөгч->ануулга("..."); // гэх мэт... ) )

Одоо манай нийтийн интерфэйс арай төвөгтэй болсон бөгөөд хэн нэгэн SomeService-ийн шинэ жишээ үүсгэх бүрд анги нь LoggerInterface-ийн жишээг шаарддаг гэдгийг мэддэг тул үүнийг зааж өгөхөө мартах арга байхгүй.


Бид мөн бүртгэл хөтлөгч байгаа эсэхийг байнга шалгах хэрэгцээг арилгасан бөгөөд энэ нь doSomething()-г ойлгоход хялбар бөгөөд хэн нэгэн түүнд өөрчлөлт оруулах бүрт алдаа гарах магадлал багатай болгодог.


Хэрэв бид SomeService-ийг бүртгэл хөтлөгчгүйгээр ашиглахыг хүсвэл null объектыг буцаахтай ижил логикийг ашиглаж болно:


$үйлчилгээ = шинэ SomeService(шинэ NullLogger());

Эцсийн эцэст энэ арга нь нэмэлт setLogger() аргыг ашиглахтай адил үр дүнтэй боловч бидний кодыг хялбарчилж, хамаарлын тарилгын саванд алдаа гарах магадлалыг бууруулдаг.

Нийтийн аргууд

Кодыг ашиглахад хялбар болгохын тулд ангиудад нийтийн аргуудын тоог хязгаарлах нь дээр. Дараа нь код нь ойлгомжгүй болж, бид рефакторинг хийхдээ буцаах нийцтэй байдлаас татгалзах магадлал багатай.


Нийтийн аргуудын тоог хамгийн бага хэмжээнд хүргэхийн тулд гүйлгээний аналоги нь туслах болно. Жишээлбэл, хоёр банкны данс хооронд мөнгө шилжүүлэхийг авч үзье.


$account1->татаж авах(100); $account2->хадгаламж(100);

Хэдийгээр өгөгдлийн сан нь гүйлгээгээр дамжуулан мөнгө байршуулах боломжгүй (эсвэл эсрэгээр) тохиолдолд буцаан олголтыг цуцлахыг баталгаажуулж чаддаг ч $account1->withdraw() эсвэл $account2->deposit() гэж залгахаа мартахаас сэргийлж чадахгүй. ), энэ нь буруу ажиллахад хүргэдэг.


Аз болоход бид хоёр тусдаа аргыг нэг гүйлгээний аргаар сольсноор үүнийг хялбархан засаж чадна:


$account1->шилжүүлэх(100, $account2);

Үүний үр дүнд гүйлгээг хэсэгчлэн дуусгаснаар алдаа гаргахад илүү хэцүү байх тул бидний код илүү найдвартай болж байна.

Алдаа илрүүлэх жишээ

Алдаа илрүүлэх механизм нь тэдгээрээс урьдчилан сэргийлэх зорилготой биш юм. Тэд зөвхөн асуудал илэрсэн үед л бидэнд мэдэгдэх ёстой. Ихэнхдээ тэд манай програмаас гадуур байдаг бөгөөд тодорхой давтамжтайгаар эсвэл тодорхой өөрчлөлтүүдийн дараа кодыг шалгадаг.

Нэгжийн туршилтууд

Нэгжийн тест нь шинэ код зөв ажиллаж байгаа эсэхийг шалгах гайхалтай арга байж болно. Тэд мөн хэн нэгэн системийн хэсгийг дахин засварласны дараа код зөв ажиллаж байгаа эсэхийг шалгахад тусалдаг.


Хэн нэгэн нэгжийн тест хийхээ мартаж болзошгүй тул Travis CI болон GitLab CI зэрэг үйлчилгээг ашиглан өөрчлөлт хийх үед тестийг автоматаар ажиллуулах нь зүйтэй. Тэдний ачаар ямар нэг зүйл эвдэрсэн үед хөгжүүлэгчид мэдэгддэг бөгөөд энэ нь хийсэн өөрчлөлтүүд зориулалтын дагуу ажиллахад тусалдаг.


Алдааг илрүүлэхээс гадна нэгжийн тестүүд нь кодын тодорхой хэсгийг ашиглах гайхалтай жишээ бөгөөд энэ нь эргээд хэн нэгэн бидний кодыг ашиглах үед алдаа гарахаас сэргийлдэг.

Кодын хамрах хүрээний тайлан, мутацийн туршилт

Бид хангалттай тест бичихээ мартаж болох тул комбинзон гэх мэт үйлчилгээг ашиглан кодын хамрах хүрээний тайланг автоматаар үүсгэхийн тулд тест хийхэд хэрэгтэй. Бидний кодын хамрах хүрээ багасах бүрт комбинезон бидэнд мэдэгдэл илгээдэг тул бид дутуу тестүүдийг нэмж оруулах боломжтой. Комбинелийн ачаар бид кодын хамрах хүрээ цаг хугацааны явцад хэрхэн өөрчлөгдөж байгааг ойлгох боломжтой.


Бидэнд хангалттай нэгж тест байгаа эсэхийг шалгах өөр нэг арга бол Humbug гэх мэт мутацийн тестийг ашиглах явдал юм. Нэрнээс нь харахад тэд эх кодыг бага зэрэг өөрчилж, дараа нь нэгжийн тестийг ажиллуулж, бидний кодыг тестэд хангалттай хамруулсан эсэхийг шалгадаг бөгөөд энэ нь хийсэн өөрчлөлтийн улмаас алдаа гаргах болно.


Кодын хамрах хүрээний тайлан, мутацийн туршилтыг ашиглан бид нэгжийн туршилтууд алдаанаас урьдчилан сэргийлэхэд хангалттай эсэхийг баталгаажуулж чадна.

Статик кодын анализаторууд

Код анализаторууд нь бидний программ дахь алдааг боловсруулах үйл явцын эхэн үед илрүүлж чаддаг. Жишээлбэл, PhpStorm гэх мэт IDE нь код анализаторыг ашиглан алдааны талаар анхааруулж, код бичих явцад бидэнд зөвлөгөө өгдөг. Алдаа нь энгийн синтакс алдаанаас эхлээд давтагдах код хүртэл байж болно.


Ихэнх IDE-д суурилуулсан анализаторуудаас гадна гуравдагч талын, тэр ч байтугай захиалгат анализаторуудыг тодорхой асуудлуудыг тодорхойлохын тулд манай програмуудыг бүтээх процесст оруулж болно. PHP төслүүдэд тохирох задлагчдын хэсэгчилсэн жагсаалтыг GitHub дээрээс олж болно.

Мод бэлтгэх

Алдаа илрүүлэх бусад ихэнх механизмуудаас ялгаатай нь бүртгэл нь програмыг үйлдвэрлэлд ажиллаж байх үед алдааг илрүүлэхэд тусалдаг.


Мэдээжийн хэрэг, энэ нь гэнэтийн зүйл тохиолдоход кодыг бүртгэлд бичихийг шаарддаг. Манай код бүртгэл хөтлөгчийг дэмждэг байсан ч программыг тохируулахдаа тэдгээрийг мартаж болно. Тиймээс нэмэлт хамаарлаас зайлсхийх хэрэгтэй (дээрхийг үзнэ үү).


Хэдийгээр ихэнх программууд бүртгэлийн зарим хэсгийг хөтөлдөг ч тэнд бичигдсэн мэдээлэл нь Кибана эсвэл Нагиос гэх мэт хэрэглүүрүүдийг ашиглан дүн шинжилгээ хийж, хянаж байх үед үнэхээр сонирхолтой болдог. Тэд манай програмыг туршиж байх үед биш харин хүмүүс идэвхтэй ашиглаж байх үед ямар төрлийн алдаа, сэрэмжлүүлгийг олж мэдэх боломжтой.

Алдааг дарж болохгүй

Бүртгэлийн алдаа гарсан ч заримыг нь дарах тохиолдол гардаг. PHP нь "сэргээгдэх" алдаа гарах үед үргэлжлүүлэн ажиллах хандлагатай байдаг. Гэсэн хэдий ч алдаанууд нь шинэ функцуудыг хөгжүүлэх эсвэл турших үед хэрэг болно, учир нь тэдгээр нь таны кодын алдааг илтгэдэг. Ийм учраас ихэнх код анализаторууд таныг алдаа дарахын тулд @ ашиглаж байгааг илрүүлэхдээ анхааруулдаг, учир нь энэ нь програмыг ашигласны дараа дахин гарч ирэх алдааг нууж чаддаг.


Ерөнхий дүрмээр бол PHP-ийн алдааны тайлангийн түвшинг E_ALL гэж тохируулах нь хамгийн сайн арга бөгөөд ингэснээр өчүүхэн ч гэсэн анхааруулга мэдээлдэг. Гэсэн хэдий ч, эдгээр мессежийг хаа нэгтээ бүртгэж, хэрэглэгчдээс нууж байгаарай, ингэснээр эцсийн хэрэглэгчдэд таны програмын бүтэц эсвэл болзошгүй эмзэг байдлын талаарх эмзэг мэдээлэл байхгүй болно.


error_reporting-ээс гадна strict_types-ийг үргэлж оруулах нь чухал бөгөөд ингэснээр PHP нь функцын аргументуудыг хүлээгдэж буй төрөлд нь автоматаар дамжуулахыг оролддоггүй, учир нь энэ нь олоход хэцүү алдаа (хөвөгчийг int руу дамжуулах үед дугуйрсан алдаа гэх мэт) үүсгэж болзошгүй. .

PHP-ээс гадуурх хэрэглээ

Poka-yoke нь тодорхой арга техник гэхээсээ илүү ойлголт учраас PHP-ийн бус хэсэгт ч ашиглаж болно.

Дэд бүтэц

Дэд бүтцийн түвшинд Vagrant гэх мэт хэрэгслүүдийг ашиглан үйлдвэрлэлийн орчинтой ижил төстэй хамтын хөгжлийн орчныг бий болгосноор олон алдаанаас урьдчилан сэргийлэх боломжтой.


Jenkins болон GoCD зэрэг бүтээх серверүүдийг ашиглан програмын байршуулалтыг автоматжуулах нь програмд ​​өөрчлөлт оруулах үед алдаа гарахаас сэргийлж чадна, учир нь энэ үйл явц нь олон алхмуудыг агуулж болох бөгөөд заримыг нь мартахад хялбар байдаг.

REST API

REST API үүсгэх үед API-г ашиглахад хялбар болгох үүднээс poka-yoke тарьж болно. Жишээлбэл, URL эсвэл хүсэлтийн хэсэгт үл мэдэгдэх параметр дамжих үед бид алдаа гаргаж байгаа эсэхийг шалгах боломжтой. Бид API үйлчлүүлэгчдээ "эвдүүлэхээс" зайлсхийхийг хүсч байгаа тул энэ нь хачирхалтай мэт санагдаж магадгүй ч хөгжүүлэлтийн явцад алдааг засахын тулд API-г буруугаар ашиглахыг хөгжүүлэгчдэд аль болох хурдан анхааруулах нь дээр.


Жишээлбэл, бидний API-д өнгөний параметр байж болох ч манай API-г ашигладаг хэн нэгэн санамсаргүйгээр өнгөний параметрийг ашиглаж болзошгүй. Ямар ч анхааруулгагүйгээр энэ алдаа нь эцсийн хэрэглэгчид үүнийг анзаарах хүртэл үйлдвэрлэлд амархан орж болно.


Танд төвөг учруулахгүй API-г хэрхэн бүтээх талаар сурахын тулд "Та үзэн ядахгүй API-г бий болгох" номыг уншина уу.

Хэрэглээний тохиргоо

Бараг бүх програмууд нь ямар нэгэн тохируулга шаарддаг. Ихэнхдээ хөгжүүлэгчид аль болох олон үндсэн тохиргоог өгдөг бөгөөд энэ нь тохиргоог хялбар болгодог. Гэсэн хэдий ч өнгө, өнгөний жишээн дээрх шиг тохиргооны тохиргоог буруу бичих нь амархан бөгөөд энэ нь програмыг санамсаргүйгээр өгөгдмөл рүү буцаахад хүргэдэг.


Аппликешн нь ийм алдаа гаргадаггүй тул ийм мөчүүдийг хянахад хэцүү байдаг. Тохиргоо буруу болсныг мэдэгдэх хамгийн сайн арга бол ямар ч анхдагч тохиргоог оруулахгүй байх, тохиргооны параметр алга болмогц алдаа гаргах явдал юм.

Хэрэглэгчийн алдаанаас урьдчилан сэргийлэх

Мөн poka-yoke концепцийг хэрэглэгчийн алдаанаас урьдчилан сэргийлэх, илрүүлэхэд ашиглаж болно. Жишээлбэл, нягтлан бодох бүртгэлийн програм хангамжид хэрэглэгчийн оруулсан дансны дугаарыг шалгах цифрийн алгоритм ашиглан шалгаж болно. Энэ нь таныг дансны дугаарыг буруу бичихээс сэргийлнэ.

Дүгнэлт

Хэдийгээр poka-yoke нь зөвхөн ойлголт бөгөөд тодорхой хэрэгсэл биш боловч алдаанаас урьдчилан сэргийлэх эсвэл тэдгээрийг эрт илрүүлэхэд туслах код болон хөгжүүлэлтийн процесст хэрэглэж болох янз бүрийн зарчмууд байдаг. Ихэнхдээ эдгээр механизмууд нь програмын өөрөө болон бизнесийн логиктой холбоотой байх боловч аливаа кодыг илүү бат бөх болгоход ашиглаж болох хэд хэдэн энгийн арга, хэрэгслүүд байдаг.


Санаж байх ёстой гол зүйл бол бид үйлдвэрлэлийн алдаанаас зайлсхийхийг хүсч байгаа хэдий ч тэдгээр нь хөгжүүлэлтийн явцад маш их хэрэгтэй байж болох бөгөөд тэдгээрийг хянахад хялбар болгохын тулд аль болох хурдан эхлүүлэхээс айх ёсгүй. Эдгээр алдааг код өөрөө эсвэл програмаас тусад нь ажиллуулж, гаднаас нь удирддаг тусдаа процессоор үүсгэж болно.


Алдааны тоог цаашид багасгахын тулд бид кодын нийтийн интерфейсийг аль болох энгийн бөгөөд ойлгомжтой байлгахыг хичээх хэрэгтэй.

Шошго:

  • PHP
  • төрлийн сануулга
  • баталгаажуулалт
Шошго нэмэх

Poka-yoke (poka yoke шиг сонсогдож байна) нь инээдтэй сонсогддог Япон хэллэг юм туранхай үйлдвэрлэлийн хэрэгслүүдийн нэг. Энэ нь бид өдөр бүр тааралддаг нь харагдаж байна. Зөвхөн орос хэл дээр энэ нь "тэг алдааны зарчим" эсвэл " тэнэг».

Англи хэл дээр "poka-yoke" гэж шууд орчуулагддаг. алдаанаас зайлсхийх", өөрөөр хэлбэл. "Алдаа гаргахаас зайлсхий" Практикт тохируулсан орчуулгыг ашигладаг - алдаа нотлохэсвэл алдаа нотлох(алдаанаас хамгаалах).

Пока-ёке гэдэг нь үйлдвэрлэлийн явцад алдаа гарахаас зайлсхийх, эсвэл дараагийн процесст согог хэлбэрээр орохгүйн тулд тэдгээрийг цаг тухайд нь тодорхойлоход тусалдаг арга, төхөөрөмж юм.

Тэнэггүй төхөөрөмжүүд нь зөвхөн алдаанаас хамгаалаад зогсохгүй хүний ​​хүчин зүйлээс үүдэлтэй алдаанаас:

  • хайхрамжгүй байдал
  • мартамхай байдал
  • болгоомжгүй байдал
  • мунхаглал
  • ядрах
  • тэр байтугай хорлон сүйтгэх ажиллагаа.
Хүмүүс алдаа гаргадаг бөгөөд пока-ёке төхөөрөмж нь тэднийг алдаа гаргахаас хамгаалдаг.

Пока-йокийн ажиллах зарчим нь дараахь шинж чанартай байдаг.

  1. 100% баталгаажуулалтын хамрах хүрээ
  2. хурдан санал хүсэлт
  3. хямд, энгийн байдал.
Poka-yoke төхөөрөмжүүд нь ямар ч согоггүй байх зарчмаар ажилладаг - нэг ч согогийг бүү алдаарай.

Пока-ёке аргыг бий болгосон түүх

Poka-yoke нь хүний ​​хүчин зүйл дээр тулгуурлан алдааг арилгах зорилготой. Алдаанаас хамгаалах аргыг аж ахуйн нэгжүүдэд пока-ёке хэмээх ойлголт үүсэхээс өмнө аль нэг хэлбэрээр ашиглаж ирсэн. Энэ системийг Тоёота компанид албан ёсоор оруулсан.

Пока-йоке аргыг зохион бүтээгч нь Японы инженер Шигео Шинго (1909-1990) бөгөөд үйлдвэрлэлийн чиглэлээр мэргэшсэн мэргэжилтэн, Тоёотагийн үйлдвэрлэлийн системийг бүтээгчдийн нэг юм. Шигео Шинго нэгэн аргыг боловсруулсан Чанарын хяналтыг тэглэх(ZQC), эсвэл Тэг согог(тэг согог).

"Тэг согог" арга нь үйлдвэрлэлийн үйл явцыг хянах замаар согогоос урьдчилан сэргийлдэг гэсэн итгэл дээр суурилдаг. машин эсвэл хүн алдаа гаргасан ч доголдол гарахгүй.

Чанарын хяналтын гол зорилго нь эцсийн бүтээгдэхүүнийг согогтой эсэхийг шалгахаас үйлдвэрлэлийн үе шат бүрт согог гарахаас урьдчилан сэргийлэх явдал юм.

Үүний зэрэгцээ, согогоос урьдчилан сэргийлэх гол үүрэг нь чанарын баталгаажуулалтын үйл явцад оролцдог үйлдвэрлэлийн ажилтнууд юм.

Poka-yoke буюу тэг алдааны арга нь ZQC-ийн гол талуудын нэг юм. Poka-yoke систем нь операторыг алдаа гаргахаас шууд сэргийлдэг мэдрэгч эсвэл бусад төхөөрөмжийг ашигладаг.

Эдгээр нь үйлдвэрлэлийн процессыг зохицуулж, согогоос урьдчилан сэргийлэх хоёр аргын аль нэгээр нь:

  • Удирдлагын систем- норм зөрчсөн тохиолдолд тоног төхөөрөмжийг зогсоох, эсвэл ажлын хэсгийг шаардлагатай бол боловсруулах хүртэл конвейерийн дагуу цааш хөдлөхгүйн тулд хавчаараар хаах. Энэ нь оператороос хамааралгүй учраас илүүд үздэг систем юм.
  • анхааруулах систем— машиныг зогсоох эсвэл асуудлыг засах дохиог оператор руу илгээдэг. Оператороос шалтгаалдаг тул хүний ​​хүчин зүйлийг бүрэн үгүйсгэхгүй.
Poka-yoke алдаа гаргасан хүмүүсийг хайж олохгүй, аргын зорилго нь олох ба сул талуудыг арилгахалдаа гаргах боломжтой болсон үйлдвэрлэлийн систем дээр.

poka-yoke төхөөрөмжийн түвшин

Үр ашгийг нэмэгдүүлэхийн тулд тэнэглэлээс хамгаалах аргуудыг гурван түвшинд хуваадаг.

  • 1-р түвшин - эд анги, бүтээгдэхүүний үл нийцэх байдлыг илрүүлдэг. Систем нь гэмтэлтэй хэсгийг илрүүлдэг боловч түүнийг хаядаггүй.
  • 2-р түвшин - таарахгүй байхыг зөвшөөрдөггүй.Систем нь үйлдвэрлэлийн процессын дараагийн шатанд гэмтэлтэй хэсгийг боловсруулахаас сэргийлдэг.
  • 3-р түвшин - бүтцийн хамгаалалттухайлбал, уг бүтээгдэхүүнийг зориулалтын бусаар суурилуулах, угсрах боломжгүй байдлаар хийгдсэн.

Алдаанаас хамгаалах зарчим

Алдаанаас хамгаалах зургаан зарчим буюу арга байдаг. Тэдгээрийг тэргүүлэх зэргийн дарааллаар жагсаав.

  1. арилгах: Энэ арга нь бүтээгдэхүүн эсвэл процессыг дахин төлөвлөх замаар алдаа гарах магадлалыг арилгадаг бөгөөд ингэснээр асуудалтай ажиллагаа эсвэл хэсэг нь шаардлагагүй болно.
    Жишээ : бүтээгдэхүүн эсвэл угсралтын согогоос зайлсхийхийн тулд бүтээгдэхүүн эсвэл холбох хэсгүүдийг хялбарчлах.
  2. орлуулалт: Найдвартай байдлыг сайжруулахын тулд та урьдчилан таамаглах боломжгүй үйл явцыг илүү найдвартайгаар солих хэрэгтэй.
    Жишээ : Гараар угсрах алдаанаас урьдчилан сэргийлэхийн тулд робот, автоматжуулалтыг ашиглах. Шингэн материалын тунг нарийн тогтоохын тулд автомат диспенсер эсвэл түрхэгч хэрэглэх.
  3. Анхааруулга: Дизайны инженерүүд ямар ч алдаа гаргахгүй байхаар бүтээгдэхүүн, процессыг зохион бүтээх ёстой.
    Жишээ: Зөвхөн зөв угсрах боломжийг олгодог эд ангиудын дизайны онцлог; кабелийг буруу холбохоос зайлсхийхийн тулд өвөрмөц холбогч; буруу суурилуулалтаас зайлсхийх тэгш хэмтэй дэлгэрэнгүй мэдээлэл.
  4. Тайвшрах: Тодорхой аргууд болон бүлэглэх алхмуудыг ашиглах нь угсрах үйл явцыг дуусгахад хялбар болгодог.
    Жишээ: Өнгөний кодлол, эд ангиудын тэмдэглэгээ зэргийг багтаасан харааны удирдлага. Бүх эд ангиудыг угсарч байгаа эсэхийг нүдээр хянадаг завсрын хайрцаг. Эд анги дээр зурах шинж чанарууд.
  5. Илрүүлэх: Алдаа нь дараагийн үйлдвэрлэлийн процесс руу шилжихээс өмнө илэрсэн тул оператор асуудлыг хурдан засах боломжтой.
    Жишээ: Үйлдвэрлэлийн явцад эд ангиудыг буруу угсарсан эсэхийг илрүүлдэг мэдрэгч.
  6. Хөнгөвчлөх: Алдааны нөлөөг багасгахыг хичээж байна.
    Жишээ: Богино холболтын улмаас хэлхээг хэт ачааллаас хамгаалах гал хамгаалагч.

Пока ёкегийн үндсэн аргууд

Алдаа хамгаалах гурван төрлийн арга байдаг: холбоо барих арга, унших арга, дараалсан хөдөлгөөний арга.

холбоо барих аргууд

Хэсэг эсвэл бүтээгдэхүүн нь мэдрэгч элементтэй бие махбодийн болон эрчим хүчний хувьд холбоотой эсэхийг тодорхойлох. Жишээ бие махбодийн холбоо барихХөдөлгөөнт механизм нь бүтээгдэхүүнд хүрэх үед доош дарж дохио өгдөг хязгаарлагч байж болно. Жишээ эрчим хүчний холбоо- шалгаж байгаа объектод ямар нэг зүйл буруу байгааг мэдэрдэг фотоэлектрик туяа.

Холбоо барих хамгийн сайн арга бол ажлын хэсгүүдийг конвейер дээр буруу байрлуулахаас сэргийлдэг чиглүүлэгч зүү эсвэл дамар зэрэг идэвхгүй төхөөрөмжүүд юм.

Унших аргууд

Ажлын урсгалыг тодорхой тооны алхмуудад хуваах эсвэл бүтээгдэхүүн нь тогтмол тооны хэсгүүдээс бүрдэх үед ашиглах ёстой. Энэ аргын дагуу төхөөрөмж нь эд ангиудын тоог уншиж, хүссэн утгад хүрсэн үед л бүтээгдэхүүнийг дараагийн процесс руу шилжүүлдэг.

Дараалсан хөдөлгөөний аргууд

Үйл ажиллагаа нь заасан хугацаанд хийгдсэн эсэх нь тодорхойлогддог. Тэдгээрийг мөн үйлдлүүд зөв дарааллаар хийгдэж байгаа эсэхийг шалгахад ашиглаж болно. Эдгээр аргуудыг ихэвчлэн ашигладаг мэдрэгчэсвэл фотоэлектрик унтраалга бүхий төхөөрөмжүүдтаймертай холбогдсон.

Мэдрэмтгий төхөөрөмжийн төрлүүд

Алдаанаас хамгаалахад гурван төрлийн мэдрэмтгий төхөөрөмж ашигладаг:

  1. физик контакт мэдрэгч
  2. эрчим хүчний контакт мэдрэгч
  3. физик нөхцөл байдлын өөрчлөлтийг илрүүлдэг мэдрэгч.

Физик контакт мэдрэгч

Энэ төрлийн төхөөрөмж нь эд анги эсвэл тоног төхөөрөмжийн биетийг хүрэх зарчмаар ажилладаг. Ихэвчлэн ийм төхөөрөмж нь холбоо барих үед цахим дохиог илгээдэг. Ийм төхөөрөмжүүдийн зарим жишээ энд байна:

  • Хязгаарлалтын унтраалга- унтраалга дээрх жижиг хөшүүрэгт хүрч буй объектуудын байгаа байдал, байрлалыг баталгаажуулах. Хамгийн түгээмэл бөгөөд хямд төхөөрөмжүүд.
  • Мэдрэгчтэй унтраалга- хязгаарын унтраалгатай төстэй, гэхдээ нимгэн "антенн" дээр байгаа объектод хөнгөн хүрэх замаар идэвхждэг.
  • ТриметронЭдгээр нь объектын хэмжилтийн хязгаараас хэтэрсэн үед дохио өгөх эсвэл төхөөрөмжийг зогсоох дохиог илгээдэг мэдрэмтгий зүү мэдрэгч юм.

Эрчим хүчний мэдрэгч мэдрэгч

Эдгээр төхөөрөмжүүдэд физик биш, харин эрчим хүчний холбоо нь алдааг илрүүлэхэд үйлчилдэг. Энд зарим жишээ байна:

  • Ойролцоо шилжүүлэгч- Эдгээр төхөөрөмжүүд нь гэрлийн туяаг ашиглан ил тод объектыг шалгаж, гагнуурыг үнэлж, объектын өнгө, хэмжээг зөв эсэхийг шалгах, туузан дамжуулагчаар дамжуулж, эд ангиудыг дамжуулагч руу хүргэх, тэжээхэд ашигладаг.
  • Цацрагийн мэдрэгч- ойрын унтраалгатай төстэй боловч алдааг илрүүлэхийн тулд электрон цацраг ашигладаг.


Мэдрэгч нь лонхны таг байгаа эсэхийг шалгадаг. Хэрэв таг байхгүй эсвэл сул байвал лонх автоматаар дамжуургаас гардаг.

Бусад төрлийн эрчим хүчний мэдрэгч төхөөрөмжүүд нь:

  • Шилэн мэдрэгч
  • Талбайн мэдрэгч
  • Байршил мэдрэгч
  • Хэмжээ мэдрэгч
  • Чичиргээ мэдрэгч
  • Шилжилт мэдрэгч
  • Металл сувгийг илрүүлэх мэдрэгч
  • Өнгөний код мэдрэгч
  • Хос тэжээлийн мэдрэгч
  • Гагнуурын объектын байрлал мэдрэгч

Физик нөхцлийн өөрчлөлтийг илрүүлдэг мэдрэгч

Энэ төрлийн мэдрэгч нь даралт, температур эсвэл цахилгаан гүйдэл зэрэг үйлдвэрлэлийн нөхцөлд гарсан өөрчлөлтийг илрүүлдэг. Жишээ өгч болно даралт мэдрэгч, термостат, хэмжих реле.

Алдаанаас урьдчилан сэргийлэх үр дүнтэй системийг хэрэгжүүлэх 7 түлхүүр

Тэг алдааны аргын үйл явцыг үр дүнтэй зохион байгуулахын тулд та дараах зөвлөмжийг боловсруулах хэрэгтэй.

  1. Poka-yoke хэрэгжүүлэх багаа бүрдүүлж, үйлдвэрлэлийн үйл явцад шууд оролцдог хүмүүсийн санал бодлыг үргэлж харгалзан үзээрэй. Энэ тохиолдолд гадны техникийн мэргэжилтнүүдийг оролцуулснаас илүү амжилтанд хүрэх магадлал өндөр байдаг.
  2. Процессын тогтвортой байдлыг сайжруулахын тулд үнэ цэнийн урсгалын зураглалыг ашиглана уу. Энэ нь тасралтгүй урсгалд нөлөөлөх хэсгүүдэд анхаарлаа төвлөрүүлэх боломжийг танд олгоно.
  3. Сонгосон бүс дэх үйл явцын зохион байгуулалтыг ашиглан үйл явцын үе шат бүрийг тодорхой тодорхойлох.
  4. Процессын доторх асуудлын үндсэн шалтгааныг тодорхойлохын тулд шалтгаан-үр дагаврын диаграм гэх мэт асуудлыг шийдвэрлэх энгийн арга зүйг ашиглана. Ингэснээр та алдааны хамгаалалтыг хэрэгжүүлэх шаардлагатай үйл явцын алхмуудыг тодорхойлох болно.
  5. Ашигтай хамгийн энгийн poka-yoke технологийг ашигла. Ихэнх тохиолдолд чиглүүлэгч зүү, хязгаарын унтраалга зэрэг энгийн төхөөрөмжүүд зүгээр л ажиллах болно. Гэсэн хэдий ч бусад тохиолдолд илүү төвөгтэй системүүд шаардлагатай болно.
  6. Хяналтын системүүд нь оператороос хараат бус байдаг тул анхааруулах системээс илүүтэйгээр хяналтын системийг эрэмбэлэх.
  7. Poka-yoke төхөөрөмж бүрийн стандарт маягттай байх дараах талбаруудтай:
  • асуудал
  • дохиоллын дохио
  • онцгой байдлын үед авах арга хэмжээ
  • зөв ажиллагааг баталгаажуулах арга, давтамж
  • эвдэрсэн тохиолдолд чанарын хяналтын арга.

Бидний эргэн тойронд байгаа Poka-yoke төхөөрөмжүүд

Хүмүүс зөвхөн үйлдвэрлэлд төдийгүй бүтээгдэхүүнийг ашиглах явцад алдаа гаргадаг. Эдгээр алдаанууд нь хамгийн багадаа эвдрэл, хамгийн ихдээ ноцтой аюул үүсэхэд хүргэдэг. Тийм ч учраас Үйлдвэрлэгчид бүтээгдэхүүнийхээ дизайнд алдаа гаргахгүй байх нөхцлийг бүрдүүлдэг.

Poka-yoke өдөр тутмын амьдралдаа


Жишээлбэл, уурын мэдрэгчийн ачаар ус буцалгах үед цахилгаан данх өөрөө унтрах болно. Та үүнийг унтраахаа мартахгүй. Энгийн пийшин дээрх данхны шүгэл нь мөн л пока-буулгах төхөөрөмжтэй адил зүйл юм.

Хаалгыг сайтар хаах хүртэл угаалгын машин угааж эхлэхгүй бөгөөд энэ нь үер болохгүй гэсэн үг юм.

Хүүхдийн эсрэг тусгай хамгаалалттай саванд савласан эмийг хүүхэд туршиж үзэхгүй.

Лифт хаагдах үед саад тулгарвал хаалгыг автоматаар онгойлгох болно.

Хэрэв та үүнийг мартвал орчин үеийн индүү өөрөө унтрах болно.

Пока буулга машинд


Орчин үеийн машинууд зүгээр л тэнэг төхөөрөмжөөр дүүрэн байдаг. Үнэн, тэд poka-yoke үзэл баримтлалыг санал болгож байгаа шиг хямд биш боловч амь насыг авардаг.

Үүнд идэвхтэй болон идэвхгүй аюулгүй байдлын системүүд орно, жишээлбэл:

  • яаралтай тоормосны систем
  • явган зорчигчийг илрүүлэх систем
  • зогсоолын систем
  • эргэн тойрон харах систем
  • яаралтай жолооны систем
  • шөнийн харааны систем
  • замын тэмдэг таних систем
  • жолоочийн ядаргаа хянах систем.

Програм хангамж дахь Poka-yoke

Пока буулганы сонгодог жишээ бол - өгөгдлийг устгахын тулд баталгаажуулахыг хүссэн интерфейсийн элементүүдИнгэснээр хэрэглэгч шаардлагатай мэдээллийг санамсаргүйгээр устгахгүй. Word файл дахь өөрчлөлтийг санамсаргүйгээр устгахгүйн тулд систем танд сануулах болно хадгалах. Google бүр цаашиллаа өөрчлөлтүүдийг хадгалдагтэмдэгт бүрийг оруулсны дараа.

Foolproofing жишээ нь маягтын талбарууд болон шаардлагатай болно Өгөгдсөн өгөгдөл оруулах форматтай талбарууд.

Холбоотой номууд

Чанарын тэг хяналт: Эх сурвалжийн хяналт ба Пока-Буулганы систем / Шигео Шинго

Poka-yoke системийг бүтээгч Шигео Шинго 1986 онд анх хэвлэгдсэн. Үүн дээр зохиогч бүтээгдэхүүний чанарт хүрэхийн тулд алдаанаас хамгаалах хэрэгслийг ашиглахын ач холбогдлыг нотолж байна. Тэрээр дэлгүүрт байгаа 112 төрлийн poka-yoke төхөөрөмжийн жишээг нэрлэжээ. Эдгээр төхөөрөмжүүдийг нэвтрүүлэхэд 100 доллараас бага зардал гардаг.

Poka-Yoke: Согогоос урьдчилан сэргийлэх замаар бүтээгдэхүүний чанарыг сайжруулах нь / Nikkan Kogyo Shimbun

Эхний хэсэгт poka-yoke-ийн тухай ойлголт, түүний онцлогийг энгийн дүрсэлсэн хэлбэрээр танилцуулсан. Хоёр дахь хэсэгт зохиогч Японы аж ахуйн нэгжүүдэд ашигладаг алдаанаас хамгаалах хэрэгслийн олон жишээг өгсөн.

Шийдвэр

Пока-йоке систем нь япончуудын бас нэгэн шинэ бүтээл юм. 30 гаруй жилийн хугацаанд poka-yoke төхөөрөмжүүд нь үйлдвэрлэлийн тоног төхөөрөмжтэй хамт хөгжиж ирсэн. Концепцийн нэг зарчмын дагуу тэд хямд байхаа больсон ч илүү үр дүнтэй болсон.

Одоо орчин үеийн болсон мэдрэгч, хувиргагч, шугамын дизайны онцлог, энэ нь олон мянган хүний ​​дундаас гэмтэлтэй эд анги, хоосон зайг илрүүлж, туузан дамжуулагчаас өөрсдөө зайлуулдаг.

Алдаа хамгаалах тухай ойлголт илүү өргөн хүрээтэй болсон:тусгай төхөөрөмж, дизайны онцлог, зүгээр л анхааруулга нь биднийг өдөр тутмын амьдралдаа алдаа гаргахаас хамгаалдаг.
Poka-yoke-ийн ачаар бидэнд асуудал бага байгаа нь гарцаагүй.
Үүнтэй төстэй нийтлэлүүд
Хэлэлцэх:
Харилцагчид Төсөл, хэвлэлтийн тухай Вэбсайт дахь сурталчилгаа сайтын газрын зураг

2022 parki48.ru. Бид хүрээ байшин барьж байна. Тохижилт. Барилга. Суурь.