Здравствуйте, baily, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:

B>>>>>Ну если вопрос только в терминологии
G>>>>Вопрос именно в выполняемых задачах.

B>>>Тогда, безусловно, в обязанности программиста входит и тестирование написанного им кода.
G>>Смешно. Зачем же тогда крупные конторы держат штат тестеров?
G>>Попробуй в своем коде найти все ошибки. Это вообще говоря потребует времени большего, чем на кодирование.
G>>Кто за тебя программы писать будет?

B>Да уж. Нет слов. Вы это серъезно пишите или стебетесь?
Серьезно.

B>То есть по вашему надо после того как что-то скомпилировалось сразу выкладывать "стабильный релиз"? Неудивительно что их у вас получается по 3 в день.
Нет, проходится еще дофига автоматических тестов.


B>>>Именно поэтому и нужен саппорт, чтобы оградить разработчика от большого потока обычных проблем.
G>>Ну вот, а ты предлагаешь повесить саппорт на разработчиков.
B>Ссылку в студию, где я это предлагал. Я говорил о том, что полностью оградиться от саппорта не удастся.
http://www.rsdn.ru/forum/job/3565330.aspx

Автор: baily
Дата: 12.10.09

А как же получение опыта от общения с реальными пользователями твоего продукта? И получения опыта работы, когда помимо спокойного течения разработки, приходится внезапно отвлекаться на вопросы поддержки? Такого опыта не получишь если будешь задерживаться в компании не более чем на год-два

Выделенное как раз предполагает вешание функций саппорта на разработчиков.
Если саппорт от разработки отделен, то не будет такого что придтеся "внезапно отвлекаться".

B>>>Тем не менее, в случае возникновения нештатных ситаций ( а кто пишет безбажный код? ), помочь сможет только разработчик. А кто же еще?
G>>Но его роль будет сводиться к исправлениб бага.
G>>Выявление бага будет на совести тестера.
G>>Вот тебе и разделение труда.

B>Ну найдет тебе тестер баг. Но перед тем как его поправить, кто будет устанавливать причину бага? Или у вас тестеры копаются в дампах, а потом говорят — исправь в файле таком-то строчку такую-то?
Нет, тестер восстанавливает последователньность действий, приводящих к багу.


B>>>И вот тут можно получить просто неоценимый опыт того, как писать программы так, чтобы быстро суметь понять в чем проблема и как ее решать.
G>>Это к саппорту вообще мало отношения имеет.

B>А к чему же это имеет отношение? Одно дело багфикс в процессе разработки, до релиза. Совсем другое багфикс для реального продукта, когда проблема у реального пользователя.
При нормально поставленном процессе совершенно нет разницы. Добавят баг в трекрер с приоритетом "критический" и он будет исправлен как можно быстрее, а саппорт отправит новую версию как она будет готова.


B>>>>>Как тут правильно писали, цикл разработки обычно длится больше года, и если нигде больше года не работать, то некоторые нюансы останутся за бортом.
G>>>>Ну у кого-то больше года, а у кого-то по 3 стабильных релиза в день
B>>>Это что же за область такая? Все ли релизы одинаковы полезны
G>>А пофигу что за область. Релизы все одинаково полезны, потому что проходят все автоматичесике тесты.
G>>После этого тестеры находят по одному багу в неделю при ручном тестировании.

B> Ну если все автотесты проходят — это однозначно релиз!

Упс, это я напутал. Конечно же стабильные билды, а релизы примерно раз в неделю-две.


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

B>По другому получить такую связь невозможно.
И не нужно её получать.