Re[14]: да ну!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.10.09 11:57
Оценка:
Здравствуйте, baily, Вы писали:

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


G>>>>>>Или всем нужен программист, который еще и саппортом работает, и внедренцем, и тестером, и прожект-планы рисует?


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

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

B>>>Ну если вопрос только в терминологии

G>>Вопрос именно в выполняемых задачах.

B>Тогда, безусловно, в обязанности программиста входит и тестирование написанного им кода.

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


B>>>А собирают ли у вас на работе файлы трассировки и дампы падения. А кто занимается их анализом? Обязан ли он это делать?

G>>Сначала тестер, а если выявится баг, то разработчики править будут. Сбором саппорт занимается.
G>>Далеко не все дампы будут попадать разработчикам.

B>Именно поэтому и нужен саппорт, чтобы оградить разработчика от большого потока обычных проблем.

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

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

Но его роль будет сводиться к исправлениб бага.
Выявление бага будет на совести тестера.
Вот тебе и разделение труда.

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

Это к саппорту вообще мало отношения имеет.

B>Можно сказать, прочувствовать на своей шкуре последствия наступания на грабли.

Красивые лозунги. Может сразу как в видеоролике "We share your pain" от МС?

B>>>Как тут правильно писали, цикл разработки обычно длится больше года, и если нигде больше года не работать, то некоторые нюансы останутся за бортом.

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

B>>>>>Опять же — общение с клиентами. Вы для кого пишите продукт? Неужели вам неинтересно мнение пользователей о нем?

G>>>>Одно дело интерес, а другое — обязанности разработчика.
B>>>Ну так речь шла о получаемом опыте, а не об обязанностях
G>>Ну и как этот опыт поможет программисту при нормальном разделении труда?

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

Обратную связ можно и подругому получить. Иметь для этого мастеров-универсалов (и требоваться такое при приеме на работу) не самая лучшая идея.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.