Доброго.
Вот все по собеседованиям хожу типа. Все хочу стать настоящим программистом 1С. А то в наших провинциях, так все отчеты рисуем, та мелочёвка всякая. Но то лирика.
И вот сегодня один вопрос зацепил в тесте.
Вам поставлена задача по доработке нетиповой конфигурации. В данной конфигурации ведется учет остатков товара в регистре накопления  в разрезе номенклатура и серия. Серия является обязательной для заполнения в документах. Для проверки наличия остатка есть функция, в которую предаются два параметра в виде ссылки на Номенклатуру и ее серию, и параметр типа дата. Функция возвращает булево значение, есть на остатке или нет.
Рассмотрев внимательно данную функцию, Вы видите, что там выполняется запрос к регистру накопления. В запросе используется виртуальная таблица с отбором по номенклатуре и серии.
Анализируя работу программы, Вы понимаете, что это так называемый «запрос в цикле». Так как Вам необходимо, по заданию сделать новый документ, который должен иметь табличною часть, в которой возможно несколько строк  с разными значениями номенклатуры и серии, и для проверки Вам необходима будет вызвать процедуру проверки остатка столько раз, сколько у вас строк в  табличной части документа.
Какие ваши действия. Не против, я в голосовалку варианты ответов запихаю.
1. Сообщу руководителю проекта, что данный код не оптимален и предложу переделать.
2. Сообщу руководителю проекта, что данный код не оптимален, но буду использовать уже разработанный функционал.
3. Буду использовать разработанный функционал.
4. Сделаю свою, более оптимальную процедуру.

(4) Я сначала проанализировал бы бизнес-процессы. Если за 10 лет в этом ларьке ни разу не продавали более 100 товаров в одном чеке - то и оптимизировать там ничего не надо, время тратить...

(1) А блин забыл. Я выбрал вариант 2.

(0) прежде чем бросаться всё переписывать я бы оценил еще несколько вещей:
- насколько это вообще проблема? Если опираться на текст "табличною часть, в которой возможно несколько строк" то похоже речь идёт не о тысячах строк, а о единицах. Плюс надо оценить насколько часто используется этот документ вообще
- насколько сложен код который придется переделывать. Точнее сказать тут нужно оценить риски что после переделки что-то поломается. Такой риск есть всегда, какой бы гениальный человек за это не брался
- если наше время оплачивается по часам, то сразу же встает вопрос будет ли кто-то оплачивать это дополнительное время

короче нужно оценить возможные потери в виде риска напортачить и затрат времени, а потом сравнить с возможным выигрышем. И тогда уже решать стоит ли оно того. Скорей всего наиболее оптимальным исходом ситуации будет п.2 - о проблемы знать но ничего не трогать

Если есть РП, то он и должен решать. Если нет, тогда конечно сам буду переделывать.

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

(0) Если это работает и не вызывает пока технологических проблем - лучше использовать существующий библиотечный модуль.
Как миниум не будет размазываться ответственность за один и тот же блок по всей конфигурации.
Потом - будет проще все поправить. Время придет.
Сообщить о проблеме обязательно надо.
Но бежать с шашкой все переделывать - не разумно.
Поставить задачу в план и в отведенное время удовлетворить внутреннего перфекциониста.

Было подобное, не далее, как позавчера. Просто сообщил РП, на что получил ответ: "Да, ребята доделают, а ты доделывай свою задачу - завтра надо демонстрировать заказчику".

Лезть в чужой код при групповой разработке - такое себе. Неизвестно, что потом отвалится у коллег после твоих правок. При этом не исключено, что после их правок что-то у тебя отвалится.

В ТЗ таки и написано: "Так как Вам необходимо, по заданию сделать новый документ, который должен иметь табличною часть, в которой возможно несколько строк  с разными значениями номенклатуры и серии, и для проверки Вам необходима будет вызвать процедуру проверки остатка столько раз, сколько у вас строк в  табличной части документа.", но, вообще, мало данных:
1 - Вдруг начальник дурак, сделаю по 1, а остальные будут ругаться, или процесс разработки встанет согласованиями
2 - Ты прикрыт и крайним не будешь, и разработка не встанет, и, если надо, то сами спросят. Ты в дураки идешь, а не в начальники
3 - Разработка идет по тз, но ведешь себя как индус
4 - По факту результат примерно тот же, что и в пункте 1, но это прямое неследование тз без согласования, отсекаем.

(47) может, дело не в знаниях, а в тебе лично?
если ты не производишь должного вида на работодателя, то на знания уже не смотрят.