Так как сегодня суббота, то думаю можно немного поспамить. На просторах reddit наткнулся на интересный пост, который назывался: "ПЛОХИЕ ПРАКТИКИ СИСИТЕМНОГО ИНТЕГРАТОРА"
И вот что он пишет:
-Нет производства стандартных библиотек, каждый раз приходится что-то переписывать с нуля.
-Очень плохой шаблон ПО
-Очень плохой дизайн HMI и отсутствие шаблона, поэтому каждый раз с нуля и каждый раз чего-то не хватает.
-Очень плохая документация (какой-то дерьмовый ворд файл, лол).
-Плохое знание физики и механики
-Каждый проект не может быть выполнен одним человеком, всегда приходится менять человека из-за других работ и нехватки времени.
-Плохой контроль версий
-Нет знаний в области ИТ
С чем-то я согласен, с чем-то нет. В прошлом году я уже писал о проблемах в АСУТП, на мой взгляд. Теперь могу поделиться плохими практиками от себя, с чем я сталкивался, а что иногда и сам делаю(простите), а также предлагаю вам в комментариях поделиться
1)Документация не всегда соответствует реальности. И если про всякие руководства я беспокоюсь в последний момент, так как их все равно переписывать после ПНР, то вот электрические принципиальные схемы, которые отличаются от реальности создают много проблем.
2)Отсутствие пункта про рабочее место на территории заказчика в договорах. (Ага, это про стул, стол, свет и минимальные удобства)
3)Наименование объектов в коде соответствует наименованию в проекте. Конечно HL1 - это здорово, но RedLamp - это чуть более понятно.
4)Бесполезные комментарии. Опасность комментариев заключается в том, что они не всегда изменяются с изменением логики. Так что комментировать каждую строчку с условием и циклом - перебор, а вот в паре строчек указать что делает эта функция полностью - норм.
5)Отсутствие переговоров и совещаний. Раньше сам не любил эти процессы, считая, что они только забирают время, мол в почте все проще и быстрее. Переговоры и совещания действительно забирают много времени, если их правильно не организовать, указав время, продолжительности и цели к которым надо прийти к концу этого совещания.
6)Отсутствие общего ТЗ на СУ. Оно всегда требуется. ВСЕГДА. Именно в нем указывать что надо сделать, а если заказчик говорит, что не надо, то указывайте в ТЗ, что это делать не надо.
7)Дизайн рисуют программиста. Давайте признаемся, что мы не умеем рисовать дизайн. И ни какие 101 нам не помогут.
8)Отсутствие бюджетов и сроков для разработки библиотеки СУ для всего парка устройств.
9)Цифровые двойники или макеты. Ох, сколько же нервов это могло сэкономить. Отладка большей части логики управления в спокойных условиях.
10)Плохая структурная организация проекта в среде разработки. Это когда мы все накидали в рандомные папки с какой-то непонятной структурой. Сначала у меня в одной папке были данные в другой FB, но без экземпляров в третьей Экемпляры FB и их вызовы. Потом я как-то еще пересобирал структуры проектов, пока не дошел до структуры, которая уже понятна для меня с каким-то постоянными названиями.