Здравствуйте, gandjustas, Вы писали:
B>>>>Ну если вопрос только в терминологии
G>>>Вопрос именно в выполняемых задачах.
B>>Тогда, безусловно, в обязанности программиста входит и тестирование написанного им кода.
G>Смешно. Зачем же тогда крупные конторы держат штат тестеров?
G>Попробуй в своем коде найти все ошибки. Это вообще говоря потребует времени большего, чем на кодирование.
G>Кто за тебя программы писать будет?
Да уж. Нет слов. Вы это серъезно пишите или стебетесь?
То есть по вашему надо после того как что-то скомпилировалось сразу выкладывать "стабильный релиз"? Неудивительно что их у вас получается по 3 в день.
B>>Именно поэтому и нужен саппорт, чтобы оградить разработчика от большого потока обычных проблем.
G>Ну вот, а ты предлагаешь повесить саппорт на разработчиков.
Ссылку в студию, где я это предлагал. Я говорил о том, что полностью оградиться от саппорта не удастся.
B>>Тем не менее, в случае возникновения нештатных ситаций ( а кто пишет безбажный код? ), помочь сможет только разработчик. А кто же еще?
G>Но его роль будет сводиться к исправлениб бага.
G>Выявление бага будет на совести тестера.
G>Вот тебе и разделение труда.
Ну найдет тебе тестер баг. Но перед тем как его поправить, кто будет устанавливать причину бага? Или у вас тестеры копаются в дампах, а потом говорят — исправь в файле таком-то строчку такую-то?
B>>И вот тут можно получить просто неоценимый опыт того, как писать программы так, чтобы быстро суметь понять в чем проблема и как ее решать.
G>Это к саппорту вообще мало отношения имеет.
А к чему же это имеет отношение? Одно дело багфикс в процессе разработки, до релиза. Совсем другое багфикс для реального продукта, когда проблема у реального пользователя.
B>>Можно сказать, прочувствовать на своей шкуре последствия наступания на грабли.
G>Красивые лозунги. Может сразу как в видеоролике "We share your pain" от МС?
Ну можно и так. Только скорее всего долго так делать не получится. Прийдется искать новую работу. Либо потому, что руководство на фирме грамотное и вовремя турнет такого "программиста". Либо, если руководство неграмотное, то грохнется сама фирма.
B>>>>Как тут правильно писали, цикл разработки обычно длится больше года, и если нигде больше года не работать, то некоторые нюансы останутся за бортом.
G>>>Ну у кого-то больше года, а у кого-то по 3 стабильных релиза в день
B>>Это что же за область такая? Все ли релизы одинаковы полезны
G>А пофигу что за область. Релизы все одинаково полезны, потому что проходят все автоматичесике тесты.
G>После этого тестеры находят по одному багу в неделю при ручном тестировании.

Ну если все автотесты проходят — это однозначно релиз!
G>>>Ну и как этот опыт поможет программисту при нормальном разделении труда?
B>>Как и любой механизм обратной связи. Можно годами делать ошибки и не замечать этого, так как в тот момент, когда проявятся последствия этих ошибок, вы уже будете "приобретать опыт" на новом месте работы.
G>Обратную связ можно и подругому получить. Иметь для этого мастеров-универсалов (и требоваться такое при приеме на работу) не самая лучшая идея.
Обратная связь — понятие широкое. Здесь идет речь об отзыве пользователей на именно ТВОЮ работу, причем некоторые отзывы ОБЯЗУЮТ тебя исправить твои ошибки ЗДЕСЬ и СЕЙЧАС. По другому получить такую связь невозможно