Личный бренд разработчика: проверяем то, что не показывают «плюсики» и количество скачиваний за $m

Под публикацией на Infostart видно, сколько у неё плюсов, скачиваний и комментариев. По этим числам удобно найти работу, которую обсуждают коллеги. Когда же вы покупаете обработку под свою задачу, важнее другое: на какой конфигурации её запускали, с чем сравнивали результат и что осталось непроверенным. Этого в рейтинге нет.

Я взяла две обработки, купленные раньше, и проверила их на одной копии демонстрационной базы. Каждую сравнила с контрольным расчётом. В справочнике «Номенклатура» было 253 записи; первая обработка показала в строке итогов 30. Вторая, Console 4K, правильно насчитала 253 различных кода, но не смогла получить ответ от локального HTTP-сервера. Ниже протоколы обеих проверок и вывод, который из них следует для описания собственных работ.

Что показывает рейтинг

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

В карточках обеих исследованных публикаций написано, что гарантии работоспособности, возврата и технической поддержки нет. Проверить пример под свою задачу покупатель должен сам. Выбор готовой обработки иногда напоминает интеллектуальное казино: за файл уже заплачено, а сколько уйдёт на адаптацию, выяснится позже.

Снизить эту неопределённость может описание работы, которое коллега способен проверить. Репутацию, за которой стоит доступная история конкретных работ (задача, личный вклад, артефакт и результат проверки), я называю проверяемым личным брендом.

Стенд и объекты проверки

Файлы обработок я не правила. Чтобы прочитать программные модули, выгрузила каждую обработку штатно в XML, а запускала исходные файлы в клиенте 1С. Контрольные запросы выполняла через внешнее соединение и небольшими скриптами. В подготовке опытов и текста мне помогали ИИ-инструменты; внешней рецензии не было.

Первая обработка - «Итоги в динамическом списке. Итого по колонке. Вычисляемые поля» (публикация № 2652155). Её автор указывает проверку на ERP 2.5.25.112. Я запускала её на УТ 11.5, поэтому мой результат относится к УТ; как обработка работает на ERP, этот опыт не показывает.

Вторая - Console 4K (публикация № 2781719). На странице публикации упоминаются версии 2.16.46 и 2.16.45, а имя полученного файла оканчивается на «45». Чтобы было понятно, какой именно экземпляр проверялся, я записала размер и контрольную сумму SHA-256 обоих файлов.

Первый опыт: итог по колонке в динамическом списке

Обработка выводит итог под колонкой динамического списка, в строке итогов внизу таблицы. В форме есть вычисляемое поле:

1

ВычислитьВыражение("КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Код)", , "ОбщийИтог")

Выражение считает, сколько в списке различных значений реквизита «Код». Итог под колонкой «Код» связан с CurrentData.Поле1, то есть со значением этого поля в текущей строке. У списка включено динамическое считывание: клиент получает строки с сервера порциями. Я проверяла простую вещь: совпадает ли число в строке итогов с количеством различных кодов во всём списке.

Правильный ответ я получила отдельным запросом через внешнее соединение:

1
2
3
4
5

ВЫБРАТЬ
    КОЛИЧЕСТВО(*) КАК Всего,
    КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Код) КАК Кодов
ИЗ
    Справочник.Номенклатура

Всего - число записей, Кодов - число различных кодов. В моей базе оба показателя равны 253: коды у всех записей разные. Значит, правильный итог - 253. Если бы обработка не учитывала группы, получилось бы 192; такого показания в опыте не было.

В обработке я переключила список в плоский вид (Ещё → Режим просмотра → Список), чтобы элементы и группы шли одним списком. Строка поиска пустая, пользовательский отбор не задан, группировки нет. В строке итогов под колонкой «Код» появилось 30.

Рисунок 1. Итог под колонкой «Код» справа внизу: 30. Контрольный запрос по той же базе возвращает 253.

Потом я ходила по списку и пользовалась поиском. Данные справочника за это время не менялись: контрольный запрос после серии вернул те же 253.

Рисунок 2. Тот же список без отбора после поиска и возврата в начало: в строке итогов 17, правильный итог по-прежнему 253.

Рисунок 3. Когда найдена одна позиция, итог верный. Демонстрация на такой выборке выглядела бы убедительно.

Иерархический вид, в котором форма открывается по умолчанию, я со справочником целиком не сравнивала: в нём на экране только содержимое текущей группы.

Что установлено. На этом стенде строка итогов не показывает количество различных кодов во всём списке: вместо 253 в ней 30, 45 и 17, и число меняется при перемещении по списку. Такие показания похожи на подсчёт только по строкам, которые клиент уже получил с сервера. Внутренний алгоритм платформы я не исследовала, поэтому это предположение; размер порции из него не следует.

В описании публикации есть ещё выражение для суммы долга. Его, как и работу обработки на других конфигурациях и релизах, я не проверяла.

Второй опыт: Console 4K

Console 4K - консоль запросов и набор служебных инструментов в одной обработке. Сначала я проверила основное: выполнила в консоли запрос с КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Код) по справочнику «Номенклатура». Консоль вернула 253, столько же, сколько контрольный запрос. Затем выполнила запрос ВЫБРАТЬ "a""b" КАК Текст и получила ожидаемое a"b: экранирование кавычек в строке запроса работает. Об остальных возможностях консоли эти две проверки ничего не говорят.

Рисунок 4. Console 4K посчитала 253 различных кода в справочнике «Номенклатура», как и контрольный запрос.

Потом я проверила вкладку Web-requester, которая отправляет HTTP-запросы. На том же компьютере запустила простой HTTP-сервер без шифрования по адресу http://127.0.0.1:18719/probe. Он отвечал фиксированным JSON {"ok":true,"fixture":"console4k-local"} и записывал в журнал первые байты каждого входящего соединения. Данные базы на этот сервер не уходили; после опыта я его остановила. Чтобы повторить опыт, понадобится такой же локальный сервер.

Рисунок 5. Тот же адрес отвечает Python и встроенному HTTPСоединение, а Console 4K сообщает об ошибке вызова HTTP-метода.

Журнал сервера объяснил разницу. Python и HTTPСоединение прислали обычный HTTP-запрос GET. Оба запроса из консоли начинались с TLS ClientHello - первого сообщения, с которого клиент начинает защищённое соединение. Сервер ждал обычный HTTP и ответил на это сообщение обычным текстом с кодом 400. Клиент, который начал защищённое соединение, такой ответ прочитать не может, поэтому консоль сообщила об ошибке соединения.

Код формы подтвердил то же самое. Признак HTTPS в нём вычисляется, но в конструктор HTTPСоединение всегда передаётся ЗащищенноеСоединениеOpenSSL. Поэтому на адрес http:// консоль всё равно пытается установить защищённое соединение. Наблюдение и чтение кода дали одно и то же объяснение. Ошибка подтверждена для адресов http:// в этом экземпляре файла; запросы по HTTPS я не проверяла.

За время опыта клиент 1С дважды аварийно завершился. Первый раз - после серии действий и возврата на вкладку консоли, второй - при открытии формы после перезапуска, ещё до нового HTTP-запроса. В обоих аварийных дампах указаны исключение 0xc0000005 и модуль WebKit.dll с одинаковым смещением. Причину аварий я не установила и с ошибкой HTTP их не связываю: для этого нужен разбор стека и отдельное воспроизведение.

Встроенный ИИ-помощник и работу с Git в консоли я не запускала, ключи API не вводила. Тонкий клиент, веб-клиент, другие операционные системы и большие выборки тоже остались непроверенными. Сказать по этому опыту, что «консоль не работает», было бы неверно: запросы она выполнила правильно.

Что эти опыты говорят о репутации

Две обработки - это не выборка, по которой можно судить о площадке. Связь рейтинга с качеством я не измеряла и авторов между собой не сравнивала. Опыты показывают более узкую вещь: чтобы сделать конкретный технический вывод, нужен конкретный опыт с эталоном.

В первой обработке нашлось воспроизводимое расхождение с правильным итогом. Во второй прошли проверки запроса и строки с кавычками, а в HTTP-клиенте нашлась ошибка. Оценка «хороший файл» или «плохой файл» потеряла бы почти всё, что здесь удалось узнать.

Протокол с условиями и эталоном можно повторить. Если автор выпустит новую сборку, её проверят на том же сценарии и увидят, исправлена ли ошибка. Совпадение с эталоном подтвердит исправление именно этого случая, остальные сценарии придётся проверять отдельно.

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

Паспорт работы: заполненный пример

Начать можно с одной работы, описанной так, чтобы коллега мог проверить главный вывод. Ниже паспорт моего опыта с HTTP-запросом. Мой вклад здесь ограничен исследованием чужой обработки.

По отдельности каждое свидетельство слабое. Контрольная сумма подтверждает, какой файл проверялся, но не говорит, кто его написал. Снимок экрана показывает результат, но не эталон. Вместе с условиями и контрольным расчётом они позволяют коллеге повторить проверку и прийти к тому же выводу.

История попыток вместо итоговой оценки

Ниже фрагмент FAQ сервиса, где профиль специалиста связан с историей его задач, попыток, дат и рецензий. Я привожу его как иллюстрацию такой модели; прохождение задач и получение рецензий в этом сервисе я не проверяла.

Рисунок 6. Фрагмент FAQ. Токен здесь - публичный идентификатор, к которому привязана история действий специалиста.

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

У такой истории есть условия. Её нужно связать с конкретным человеком. Нужно знать, какая помощь допускалась, кто рецензировал работу и какие материалы были у рецензента. Если в работе участвовал ИИ, важно, что специалист проверил сам и за какой результат отвечает.

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

Как описать свою работу

1. Выберите одну работу, которую готовы объяснить коллеге и сведения о которой можно раскрыть.
2. Зафиксируйте версию артефакта (номер сборки или контрольную сумму) и условия испытания: платформу, конфигурацию, режим запуска, данные.
3. Назовите личный вклад: что сделали сами, что взяли готовым, где помогали коллеги или ИИ.
4. Покажите эталон и фактический результат, в том числе сценарий, который не прошёл.
5. Перечислите, что осталось непроверенным.
6. При повторной проверке сохраните прежний результат и укажите, что изменилось в условиях. Иначе улучшение после обновления платформы легко приписать правке обработки, а результат на маленькой выборке перенести на весь список.

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

Источники

• «Итоги в динамическом списке. Итого по колонке. Вычисляемые поля», публикация № 2652155 на Infostart - первая исследованная обработка.
• Console 4K, публикация № 2781719 на Infostart - вторая исследованная обработка.

Файл к статье

К статье приложен архив verifiable-reputation-companion.zip (1,4 МБ) - «Стенд проверки двух разработок, купленных за $m». В нём:

• пошаговые протоколы обоих опытов с условиями, эталоном и таблицами наблюдений;
• probe.ps1 - контрольные запросы по справочнику «Номенклатура» через внешнее соединение (всё, по элементам, по группам, по поиску «Ботинки»);
• http_fixture.py - локальный HTTP-сервер, который пишет в журнал, пришёл ли обычный HTTP-запрос или TLS ClientHello; check_http_python.py и probe-http.ps1 - контрольные запросы к нему из Python и из HTTPСоединение 1С;
• результаты контрольных запросов, журнал сервера и сводки двух аварий клиента от 18.10.2026;
• 15 снимков экрана, в том числе те, что не вошли в статью: каждое показание строки итогов, пустой отбор и группировка, обе аварии;
• шаблон паспорта работы и заполненный пример.

Купленных обработок и базы в архиве нет: обработки берутся из публикаций по ссылкам выше. 19.10.2026 я запустила скрипты из архива ещё раз на том же компьютере: контрольные запросы вернули те же 253, 192, 61 и 1, оба контрольных HTTP-запроса получили 200, а TLS-клиент на том же порту получил ошибку соединения, и сервер записал TLS ClientHello.

Итог

В копии УТ 11.5 справочник «Номенклатура» содержал 253 записи с разными кодами. Строка итогов первой обработки показывала 30, 45 и 17 вместо 253 и давала верный итог только на выборке из одной позиции. Console 4K на тех же данных посчитала правильно, но её HTTP-клиент на адрес http:// пытался открыть защищённое соединение и получал ошибку. Причина двух аварий клиента осталась неустановленной.

Эти результаты относятся к двум конкретным файлам и одному стенду. О качестве всех разработок площадки и о квалификации их авторов они ничего не говорят.

Проверяемый личный бренд начинается с одной работы, у которой описаны условия, личный вклад и результат. Паспорт, составленный самим автором, ещё не подтверждает квалификацию: читатель должен иметь возможность сверить его с артефактом и повторить главную проверку. В таком описании есть место и удачному сценарию, и ограничению, и исправлению.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S