На эту тему мы частенько спорим с айтишниками. Обсуждая, кто где и как накосячил, и как с этим бороться.
Вот в чем разница. Саму по себе программу контроллера протестировать можно и несложно. Тем более что программы очень простые и короткие (скажем, 7000 строк - это по меркам IT вообще мизер)
Но основная часть проблем возникает не из-за косяков в программе (хотя это тоже бывает, конечно). А из-за ошибок в понимании технологии, физических процессов, происходящих в оборудовании, и так далее К ним же стандартное (для IT) QA не прикрутишь вообще никак.
Как результат, основная задача программиста промышленной автоматики - вовсе не программировать (это маленькая и простая часть работы). А разобраться, с помощью технолога, литературы и прочая - в том, как оборудование устроено, что в нем происходит, как оно может сломаться... А "классического" (IT) программиста это вообще не волнует. Он может даже и не знать, а где, собственно, физически выполняется его программа.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
momijizukamori
no subject
Date: 25 Jul 2016 04:47 (UTC)Вот в чем разница. Саму по себе программу контроллера протестировать можно и несложно. Тем более что программы очень простые и короткие (скажем, 7000 строк - это по меркам IT вообще мизер)
Но основная часть проблем возникает не из-за косяков в программе (хотя это тоже бывает, конечно).
А из-за ошибок в понимании технологии, физических процессов, происходящих в оборудовании, и так далее
К ним же стандартное (для IT) QA не прикрутишь вообще никак.
Как результат, основная задача программиста промышленной автоматики - вовсе не программировать (это маленькая и простая часть работы).
А разобраться, с помощью технолога, литературы и прочая - в том, как оборудование устроено, что в нем происходит, как оно может сломаться...
А "классического" (IT) программиста это вообще не волнует. Он может даже и не знать, а где, собственно, физически выполняется его программа.