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

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

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

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

Прекрасно. А кто пишет автотесты? Только тестеры?


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

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

G>

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

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

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

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

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

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


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

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

Разница в том, что в первом случае багфикс ведется в рамках разработки текущего продукта, когда в голове еще свежи все детали, и когда можно все взять и поменять. А вот во втором случае уже гораздо веселее. Не всегда можно пользователю сказать — снеси старую версию с багой и поставь новую без баги, все заново настрой, разверни и т.п


G>>>А пофигу что за область. Релизы все одинаково полезны, потому что проходят все автоматичесике тесты.
G>>>После этого тестеры находят по одному багу в неделю при ручном тестировании.

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

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

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


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

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