Организация работы программистов

[mazzy]

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

Цитата:

Изначально опубликовано Андре
1. Как Вы осуществляете тестирование вновь написанной или модифицированной функциональности ?

На тестовой базе.

Цитата:

Изначально опубликовано Андре
Да в какой-то степени программист разрабатывающий эту часть системы, ее уже протестировал, но он никогда не будет до конца уверен (по крайне мере у меня еще нет такой уверенности),

100% уверенности никогда и ни в чем не бывает. В этом я уверен на 100%
Для практической деятельности обычно бывает достаточно следовать принципу 80-20.

Цитата:

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

Как это? А перекрестные ссылки?
Что значит "не ожидали от модуля"?
Это всего лишь значит, что ты не посмотрел и не проверил.

Цитата:

Изначально опубликовано Андре
Осуществляется ли полная проверка функциональности системы после каждого добавления функциональности ?

Это идеальное решение.
К сожалению, идельные решения требуют бесконечных ресурсов.
Поэтому опять же следуем правилу 80-20.

Цитата:

Изначально опубликовано Андре
Каким образом Вы осуществляете тестирование

Первичное тестирование осуществляет тот, кто писал. Т.е. "написал - проверь, что нет явных ляпов". Если ляпов нет, то этим же выполняется более тщательное тестирование на пяти-десяти примерах (если на тестирование есть время). Задача все та же - на 80% быть уверенным в корректности кода.

Дальнейшее тестирование выполняет уже сам оператор. Его предупреждают, что код новый - посмотри на его поведение, проверь несколько цифр/документов. Если все нормально, то код считается правильным.

Естественно, что такой подход не гарантирует полную проавильность и корректность кода. Однако для практических целей он вполне подходит и на практике приносит хорошие результаты.

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

Цитата:

Изначально опубликовано Андре
И второй вопрос: должен ли быть в организации человек, через которого проходит ВЕСЬ написанный код, который изучает и проверяет его и "дает добро" на внесение этого кода в работающую систему ?

Для типовых решений скорее всего да.
Для внедрений "для себя" это излишне, IHMO. Так как увеличивает количество требуемых ресурсов, а эфект не так заметен.

Цитата:

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

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

Цитата:

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

Кроме того в Аксапте записывается кто какие объекты правил.
Что значит не "признает"?
У объекта прописан логин?
В архивных копиях есть? Какие пролемы?
Только искать виноватого - это очень затратный путь. Гораздо эффективнее создать команду, которая работает на одну цель.

Цитата:

Изначально опубликовано Андре
В связи с этим, мне кажется разумным, чтобы был человек, который отслеживает все изменения функциональности (вплоть до контроля и проверки каждой строки кода), одобряет их и соответственно уже он несет ответственность за работоспособность системы.

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