Что делать, когда приложение падает под Windows?

[Лекс Айрин]

CRobin, значит, надо менятьподход программирования. попробуй экстремальный или защитный.

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

[CRobin]

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

[Лекс Айрин]

если программист в проекте сам себе режиссер, думаю врядли он сможет соблюсти все каноны.

наоборот. Как раз тогда, когда один легче соблюсти свои каноны.

[CRobin]

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

[Лекс Айрин]

CRobin, не так все тяжко, как выглядит.
Методика программирования (пусть и неявная) это лишь набор методов (ака скриптов ) позволяющих упростить работу с кодом.

Например, при агрессивном программировании цикл набор текста/компиляция/отладка/сборка/ выпуск новой версии настолько мал, что фактически код сразу же проверяется. При этом, прототип программы наращивается и тут же проверяется, так как легко можно проверить все текущие варианты ветвлений и вызовов.

Конечно, если начальству нужен быдлокодер, то ни о какой оптимизации работы речь не идет. Но тогда основной упор придется делать на рефакторинг.

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

проблема не в том, что написать идеальный код нельзя --- а в том, что его нельзя написать быстро. По мере развития проекта, при таком подходе, участники просто либо не успевают сделать вовремя, либо тупо устают (у них появляются иные интересы и заботы). Решается это, например, созданием второй команды чисто для рефакторинга.

[CRobin]

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

[Лекс Айрин]

CRobin, так и я о том же самом.