Тем не менее, rgreat для разнообразия прав и предлагает принципиально более вменяемое решение.

Помимо прочих недостатков, оно намертво ломается в тривиальном кейсе:

1. Программист Вася пилит какую-нибудь фичу. Он сделал бранч, внёс изменения и в ходе отладки напоролся на такую ошибку где-то в чужом коде. Обошёл её и пошёл дальше.

2. Через неделю-две-три программист Петя, у которого дошли руки до разгребания валяющихся в трекере мелких ошибок, отгадывает это самое {$I %FILE%} + ', ' + {$I %LINE%} не соответствующее вообще ничему - поскольку состояние исходников, в котором оно сработало, было только у Васи на компе.

Kazantsev Alexey,

прикрывать плохое техническое решение беспочвенными ссылками на неправильный процесс - это и есть бардак.

Kazantsev Alexey,

отчего же. Правильные технические решения очень часто не оставляют бардаку места, примеров сколько угодно. Скажем, я помню, какой бардак когда-то творился с сообщениями об ошибках - "Ну почему вы не запомнили текст? А где это было? Ну вот опять..." - а всего-то потребовалось правильно организовать автоматические репорты. Я помню, какой бардак творился когда-то с ведением исходников и поддержкой разных версий - а всего-то потребовалось спроектировать вменяемые VCS.

Что же до предмета спора, он иллюстрирует другой верный тезис - подходы, допустимые для случая, когда единственный разработчик пилит на коленке нетленку, далеко не всегда пригодны для команды разработчиков в организованном процессе.

Ты бы попробовал научиться читать до того, как начинать возражать.

Ещё раз, на пальцах:

• На старте текущей в VCS является версия V1, в ней в сотой строке некоего файла лежит такая вот диагностика ошибки
  
• Васе нужно допилить реализацию кнопки А. Он отбранчовывается и начинает вносить изменения, в результате чего диагностика перемещается в строчку 105
  
• Вася запускает exe (уж не знаю, какой именно "отпечаток версии" ты ожидаешь увидеть в отладочном exe, придумай на свой вкус), и там случайно промахивается и вместо кнопки А нажимает кнопку Б. Получает ошибку "хрень в строке 105"
  
• Поскольку Вася пилит кнопку А, он забывает о своём промахе и идёт дальше, а репорт "хрень в строке 105" ложится ждать своего часа в трекер
  
• В конце концов Вася допиливает реализацию и кладёт в контроль версий исходники, где диагностика лежит уже в строке 110, это будет версия V2.
  

А вот теперь расскажи, каким образом Петя, когда у него дойдут руки до репорта "хрень в строке 105", будет выбирать между версиями V1, V2, V3 и V4, чтобы попытаться воспроизвести и исправить.

А что ты предлагаешь? В рамках поставленного процесса забивать на них болт? Вообще-то, по-нормальному, 99% ошибок отлавливаются и устраняются до того, как проявятся на продакшне - на разных стадиях разработки и тестирования. Хотя да, конечно, можно делать вид, что в приложении нет никаких ошибок до тех пор, пока "хрень в строке X" таки не вывалится на проде.

На проде, скорее всего, версия V0 - последний протестированный релиз, возможно с хотфиксами. V1 - это текущая разрабатываемая версия (то, что наплодили разработчики со времён V0 и что ждёт своего выкладывания на прод). Для простоты можно предположить, что ошибка, порождающая "хрень", внесена именно в V1, и в V0 её ещё нет.


Ну здорово. Взял с сервера V0 и отрапортовал, что её нет. Закрыл таску. Потом наступает релиз - и она наконец-то начинает вываливаться на проде. "Мы все - ма-лад-цы" (тм)


Ну то есть ты предлагаешь забить на найденную ошибку и надеяться, что потом, когда начнётся тестирование релиза - тестировщики найдут её ещё раз. Это не выглядит образцом надёжности.

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


На этот случай есть чекбокс "слать ли репорт".

Не проблема, конечно. Вопрос в том, как делать это наиболее эффективно.

В случае нашего процесса это действие регулируется одним проставить/снять галочку, и в результате в трекер уезжает качественный отчёт - со стректрейсом, значениями ключевых переменных итп. Ты предлагаешь тратить гораздо больше времени на то, чтобы руками оформить значительно менее качественный репорт. И ради чего? Только ради того, чтобы обойти лажу плохого технического решения с %LINE%.

Ещё вчера для тебя было правильным "репорты только с продакта". Поэтому я с некоторым скепсисом отношусь к новым рецептам правильности.