Разная работа программы в эмуляторе и на контроллере

[Михаил Иванович]

Согласен, но... Вы сдаете важный горящий объект, попросите внести мелкую правку. Вместо помощи за 5 минут, программист зарядит это дело в отдел технической документации.. после праздников они согласуют.. Боюсь, что мой взгляд в такой ситуации выражался бы только матом

Вы утрируете ситуацию для того, чтобы показать ее более ярко. С яркостью - согласен. Но, я думаю. что все не так страшно. В приведенном Вами случае программист перед тем, как менять саму программу, должен написать за 5 минут техническое задание на коррекцию программы в самой простой свободной форме, еще за 5 минут - проект вносимого изменения, тоже в свободной форме, причем первое и второе можно совместить, еще за 5 минут внести эти изменения, потом потратить пол-часа на проверку того, не навредил-ли, и если все в порядке, зафиксировать внесенные изменения, получить подпись заказчика на акте испытаний внесенных изменений. А уж "после праздников", если они уже наступили, передать свои листочки в соответствующий отдел, они с ними разберутся, дадут программисту втык, за то, что не по форме, наябедничают начальству, начальство, как водится наградит непричастных и накажет невиновных, листочки в первозданном виде подошьют куда надо ибо выяснится, что и такая форма не противоречит ГОСТу, внесут запись в лист изменений, заведут на это изменение карточку и разошлют ее смежникам - держателям проектной документации. И только такой путь (за исключением ябеды начальству) позволит не утонуть в волнах вносимых изменений. Ибо опыт показывает, что документация "потом" - не пишется. То о чем я говорю называется элементарной производственной дисциплиной. Конечно, это требует определенных волевых усилий, для огромного большинства программистов просто немыслимых. Отсюда и рождаются всякие концепции "экстремального программирования" и т.п. Приведенная Вами в примере "помощь за 5 минут" в дальнейшем обернется сутками поиска где, когда и зачем кто-то что-то внес. А если человек уволился, то это может стать вообще безнадёжным делом. Уверен, что Вы с этим сталкивались, если не при разработке конкретной программы, то в какой-то иной ситуации, потому что это явление общее. Так может быть, лучше потратить час на простое документирование?

Если серьезно, то документацию и ПО пишут не боги. Стоит взять за правило тестировать самому любую новую функцию или блок, прежде чем использовать в деле. Это и в CoDeSys и в любых других системах является хорошей идеей.

Совершенно согласен. Собственно, именно это и является источником моих вопросов, на которые Вы и другие специалисты отвечаете, за что еще раз спасибо.

[Игорь Петров]

Всегда разрабатываются детальные спецификации, но например я не способен все придумать сразу, особенно если делается нечто не имеющее аналогов. Многие вещи рождаются в процессе, обкатываются, притираются, потом описываются. Хорошо бы художнику зайти в Лувр, получить описание требуемого шедевра и спокойно его нарисовать

Приведенная Вами в примере "помощь за 5 минут" в дальнейшем обернется сутками поиска где, когда и зачем кто-то что-то внес. А если человек уволился.......это явление общее. Так может быть, лучше потратить час на простое документирование?

Будет как у юристов – поправка 215 к поправке закону, инструкция по чтению инструкции...

Не надо сутки поиска. Проблема решается системами управления версиями. Для CoDeSys V2 используется ENI. В V3 Professional Edition интегрирован SVN. На конференции раскроем эту тему.

[Михаил Иванович]

я не способен все придумать сразу, особенно если делается нечто не имеющее аналогов. Многие вещи рождаются в процессе, обкатываются, притираются, потом описываются.

Никто не способен. Есть процесс разработки, есть пробы, ошибки, решения. И бывает так, что изначальный вариант меняется до неузнаваемости - это объективно неизбежный процесс. Но если изначально нет Тех. задания, нет проекта с первоначальным описанием решений на основании того, что "все равно изменится, потом все опишу", не делается текущих описаний в этом процессе на том же основании, то "потом" - никогда не наступает. Почему? Первое - идеология. Человек, который придерживается идеологии "потом опишу" не способен на это. Он потому её и придерживается, что она позволяет ускользнуть от невозможного для него дела, найти себе текущее оправдание. Второе - забывается все быстро. Даже если добросовестный сотрудник действительно может и хочет описать потом, то у него может это не получиться или придётся затратить огромное, несопоставимое с самой работой время. Пока вы что-то делаете, пока "в теме", все кажется понятным. Проходит месяц, настаёт "потом" - и все надо поднимать заново. Сидеть и разбираться - а зачем такое было написано, выбрано такое решение. Неужели Вы с этим не сталкивались? У меня у самого такое бывало, поэтому взял за правило документировать, хоть пару строк - зачем, почему, как. Всего три вопроса и надо осветить. А если в проекте участвует много людей и один из них что-то важное забыл? Или уволился. Не было у Вас таких случаев? У меня, к счастью, не было, а с некоторых пор вообще предпочитаю работать в одиночку, но я такое наблюдал. Нельзя написать "потом", "потом" можно только подытожить, создать создать на основе текущих локальных документов новый общий документ. Вам хочется использовать систему управления версиями? Пожалуйста. Кто-то использует листочек бумажки и карандаш, кто-то делает заметки в Word'е, кто-то по каждому поводу запускает сервер с Аксаптой. Не важно, что используется, важно, чтобы этот процесс был системным, чтобы он был обязательной частью разработки. На каждом этапе. Это и называется "производственная дисциплина". И я речь веду именно о ней - не путать с отсидкой. Её автоматизировать невозможно. И без неё любая система, в том числе ENI, в том числе любая ERP-система превращается в автоматизированный бардак. А это совсем плохо.
Должен ещё сказать, что у меня есть впечатление, что мы как-то по-разному понимаем предмет обсуждения. Не могу я себе представить, что Вы не понимаете необходимости документирования проекта на всем протяжении процесса его реализации.
О конференции я знаю, но, увы, присутствовать не смогу.
Спасибо.