От Лейтенант
К Василий Фофанов
Дата 29.06.2011 23:21:46
Рубрики Танки;

Re: Давайте еще...

>Всех программистов, у которых программы начинают "вести себя" надо увольнять нах. А лучше и не нанимать.

С одной стороны да, но с другой стороны тогда прийдется уволить (не нанимать) всех програмистов.

>Дело надо уметь делать

"Ты же коммунист, Петка!" и пулемет застрочил вновь ...

> а не прикрывать собственную безграмотность и профнепригодность мистикой и шаманством. Алес.

Мистики и шаманства в этом никакой нет, просто когда программа содержит милллион операторов ветвления и написана несколькими деястками людей, то никто не в стояннии быть в курсе целиком и уж тем более в реальном времни прокручивать ее в голове. В частности в программе такого размера всегда есть ошибки (обычно много). Есть такое понятие в проектировании - предел сложности.






>> Банальный пример поведения Бурана при посадке, которое, несмотря на полную объяснимость постфактум и несложную, по нынешним понятиям, программу - очень сильно озадачило встречающих.
>
>Значит говно встречающие. Что не особенно удивляет вобщем.
От Hokum
К Лейтенант (29.06.2011 23:21:46)
Дата 30.06.2011 06:22:52

Re: Давайте еще...

>Всех программистов, у которых программы начинают "вести себя" надо увольнять нах. А лучше и не нанимать.
>С одной стороны да, но с другой стороны тогда прийдется уволить (не нанимать) всех програмистов.

Увольнять надо не программистов, а руководитей групп и менеджеров проекта, которые не в состоянии построить и отладить процесс разработки, не зависящий от причуд конкретного программиста. В серьезных конторах Quality Assurance заворачивает прекрасно работающий код на доработку, если имена переменных или формат комментариев не соответствуют корпоративному стандарту. А в очень серьезных - регулярно меняют разработчиков того или иного модуля - просто передают по кругу, типа "первый барак меняется со вторым". Да, это дольше и дороже, зато дает возможность заменить любого из программистов в любой момент, не срывая при этом сроки.

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

А в этом случае программа делится на блоки и модули с хорошо документированными интерфейсами между ними. И тестируется по кускам, а потом в сборе (Unit testing / Integration testing). Если этого нет - архитектора системы гнать той же метлой, что и менеджеров проекта.
От bedal
К Hokum (30.06.2011 06:22:52)
Дата 30.06.2011 08:44:14

известно всё это, но

если программа обрабатывает множество факторов, то вполне обычна ситуация, когда человек, автор, обратную задачу решить не может.
Утрируя, если банальная программа расчёта программы выдала вам на 432 рубля меньше, чем в прошлом месяце - _автор_ программы без дополнительного исследования _данных_ не скажет - почему.
Если же говорить о программах с физическими моделями - то такое будет сплошь и рядом. Это НЕ означает неправильной работы, и все расписанные ужасы про то, как QA всё отловит - не в тему.

Напомнаю, что подветка образовалась из простого моего утверждения, что для случайного поведения (в пространстве правильных решений) никакие генераторы случайных чисел и не нужны. Анализ постфактум исключаем, обсуждается реальное время - так что никакого урона детерминизму ЭВМ не наносится :-)
От bedal
К bedal (30.06.2011 08:44:14)
Дата 30.06.2011 08:44:51

впрочем, непотема же всё это давно... завяжем? (-)