На моей предыдущей работе был очень детализированный процесс внесения изменений в код, никто не мог просто исправить свой или чужой баг и внести изменения в код. Нужно было следовать определённому процессу, а именно создать в специальной базе данных CR - change request, в котором описать проблему, методы воспроизведения бага, версию ПО, на котором баг воспроизводится и т.п. Затем, после того, как этот CR просмотрит специально обученный человек, который принимает решение, стоит ли овчинка выделки, надо эту ошибку исправлять или нет, а если надо, то с какой срочностью, CR назначался на определённого человека, который уже должен исправить эту ошибку. Этот человек может быть, а может и не быть тот, кто создал описание этого бага.
Далее, если эту CR назначили на тебя, ты исправляешь баг, затем, когда ты уверен, что всё сделал, перед тем как вносить эти изменения в общее хранилище кода (в систему контроля версий ) назначаетсяформальная инспекция, на которую ты обязан позвать нескольких человек, как правило 2-3-х, обычно своих ближайших коллег, чтобы они просмотрели твои изменения с помощью Diff-tool'а (конкретно там использовался Araxis Merge, хотя вообще таких программ много, в том числе неплохой бесплатныйWinMerge, которым я пользуюсь в настоящий момент). Это вообще-то весьма полезная практика, обычно другие люди видят в твоём коде то, на что у тебя уже замылен взгляд. По результатам инспекции в описание CR вносятся все найденные ошибки, недочёты, проблемы и т.д, найденные в её ходе, причём если их 0, то есть ничего не найдено, то считается, что инспекция проведена некачественно, так что для всех лучше, если хоть что-нибудь найдут и опишут. Дальше разработчик проводит работу над ошибками, правит свои изменения, и процесс повторяется, в случае серьёзных изменений назначает новую инспекцию.
Только после того, как все участники инспекции вынесут одобрение твоему коду, ты имеешь право нажать кнопку Submit и внести изменения в код. Причём к каждому внесенному изменению прилагается формализованное текстовое описание с информацией о том, кто правил, кто в инспекции участвовал, шаги для воспроизведения бага и т.п.
С одной стороны это иногда раздражало, поскольку казалось излишним и весьма удлиняло работу. С другой стороны следование процессу позволяло упорядочить процесс внесения изменений, всегда можно найти кто виноват в баге и кого в случае чего пинать. В маленьких компаниях таких строгостей обычно нет, но для средних и больших проектов какой-то похожий процесс существует во многих компаниях. За несколько лет я к этому так привык, что сейчас, после смены работы, попав в компанию с менее формализированным процессом (хотя тут процесс тоже есть, просто он гораздо менее суров), мне иногда его не хватает, особенно не хватает инспекций кода.
Комментариев нет:
Отправить комментарий