Никита Арипов | 1С, DevExp

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

Сегодня Всероссийский день НКО Для меня НКО - это не только социальные проекты, но и сложные процессы, отчетность, гранты, требования регуляторов и постоянные изменения законодательства. За красивыми миссиями всегда стоит большая системная работа. И если где-то все сходится, автоматически формируется отчет и спокойно проходит проверка - значит, архитектура выстроена правильно 🙂 Рад быть частью этой инфраструктуры. Поздравляю всех, кто работает в некоммерческом секторе - и тех, кто помогает ему быть устойчивым. Если у вас есть знакомые НКО - не забудьте их поздравить!

Отец знакомого работает в Anthropic. Сегодня срочно вызвали на совещание. Вернулся поздно, ничего не объяснил. Сказал только срочно подтянуть фундаменталку: дизайн систем, архитектуру, распределенные вычисления и управление командами. И закупить оперативки на два года вперед. Сейчас собираем свой локальный кластер ИИ в гараже. Не знаю, что происходит… Кажется, началось.

«Планы доносятся на семинаре» Именно такую фразу часто можно услышать в ответ на вопрос про то, когда будет сделана та или иная функциональность. Поэтому не упустите шанс пообщаться с разработчиками на семинаре. В эти выходные (27 февраля - 1 марта) пройдет традиционный весенний партнерский семинар. На этом мероприятии эксперты фирмы «1С» делятся новыми проектами и обсуждают планы развития программ. А также Борис Георгиевич рассказывает о состоянии дел партнерской сети и компании «1С». В этом плане это уникальное мероприятие! На семинаре помимо выступлений еще проходит вернисаж. На нем будут разработчики платформы и типовых конфигураций. С ними можно пообщаться, обсудить вопросы учета и предложения по развитию. Не стесняйтесь подходить - мы там для этого и стоим! Я тоже буду выступать на этой конференции - буду рассказывать про НКО и что мы в ней сделали. Сейчас активно готовлюсь к выступлениям. Буду рад увидеться на мероприятии, кто будет - приходите пообщаться! У нас много новостей!

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

Оставайся голодным! Знаменитое «художник должен быть голодным» говорит нам не о буквальном голоде, а о сохранении умения быть неудовлетворенным. В бизнесе тоже есть «stay hungry», которое мотивирует желать чего-то еще. В нашей работе с программами тоже нужно оставаться голодным, чтобы при взгляде на ситуацию, проект, задачу или интерфейс спрашивать себя, что здесь не так. Что можно улучшить?! Что можно сделать по-другому?! Такие вопросы позволяют развивать критическое мышление, творчество и смекалку. Это превращается буквально в игру: смотрим на форму и думаем, что можно улучшить. Минимальное даже: поменять местами поля, сократить заголовок, добавить иконку к кнопке. Любое улучшение сгодится!

Порядок чтения кода Представьте, что вы читаете модуль и пытаетесь понять что он делает. Просмотрели его до конца и только там увидели, то что вам нужно. Тот конкретный метод, который помог вам понять все остальное содержание модуля. Чтобы этого избежать располагайте код в том порядке, в котором читателю было бы удобнее получать информацию. Помните, что на каждого писателя приходится много читателей. С кодом тоже самое. Код читают гораздо чаще, чем пишут. Если планируете изменять существующий модуль, то не поддавайтесь искушению почистить все сразу. Скорее всего, читая код, вы заметите и другие детали, которые усложняют понимание и изменение кода. Оставьте их на потом. При этом идеального порядка методов не существует: • иногда стоит сначала понять примитивы, а потом разбираться в их объединении • иногда лучше начать с понимания API, а затем переходить к подробностям реализации • иногда лучше добавить описание всего модуля в начало Представьте себя на месте читателя и руководствуйтесь здравым смыслом и опытом. Какой порядок предпочли бы вы? Пусть последовательность, которую вы выбрали, порадует следующего читателя. Плохо:

Процедура РассчитатьИтог()
КонецПроцедуры

Процедура ЗаполнитьДоговор()
КонецПроцедуры

Процедура ПриИзмененииОтбораОрганизации()
КонецПроцедуры

Процедура СоздатьДокумент()
КонецПроцедуры

Лучше:

Процедура СоздатьДокумент()
КонецПроцедуры

Процедура ЗаполнитьДоговор()
КонецПроцедуры

Процедура РассчитатьИтог()
КонецПроцедуры

Процедура ПриИзмененииОтбораОрганизации()
КонецПроцедуры

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

Рассказываю, что на видео. Там недостроенная игрушечная железная дорога, то есть есть прям обрывы. И по ней запускают поезд. Он сходит с рельс, но продолжает ехать по столу, затем врезается в другой участок дороги, сдвигается по курсу и начинает ехать внутри огражденного участка дороги. Так едет до тех пор пока не въезжает в другой обрыв и снова попадает на рельсы. То есть формально все работает. Железная дорога есть. Поезд ездит по кругу. Вне трассы ничего не происходит. Но внутри творится хаос. Поэтому и аналогия с вайбкодингом, что там что-то работает и ладно. Главное, не смотреть что там внутри происходит.

Когда ты полностью завайбкодил приложение и оно работает 😂

// @skip-warning - специальный комментарий, отключающий синтаксическую проверку в строке или методе В типовой БНКО встречается 1639 раз, в основном в библиотеках. Часто он обеспечивает переопределение процедур и подавляет пустой метод (см. скриншот) Важный момент, что этот комментарий не пишут на всех срабатываниях проверки, лишь бы не исправлять. Мы подавляем проверки только в тех случаях, когда это действительно необходимо Например, если переопределяемая процедура пустая, то синтаксическая проверка выдаст ошибку, а skip-warning подавляет эту проверку, чтобы не отображалось красным в EDT или в BSL Language Server Самое главное, что такой комментарий сигнализирует, что ошибка проверена и намеренная. Без него может показаться, что предупреждение просто пропущено Поэтому в библиотеках это распространено больше. Они встраиваются в разные конфигурации и объяснять разработчикам каждый раз было бы сложно. В типовых такие моменты могут упускать, так как код не передается дальше Еще есть комментарии // АПК:123-выкл и // АПК:123-вкл. Они отключают правило 1С:Автоматизированная проверка конфигурации (АПК) для блока или конкретной строки (без выкл и вкл). Цифры - это номер правила АПК. В типовой БНКО встречается 3576 раз, опять же в основном в библиотеках (см. скриншот) Такого же эффекта можно достичь и файлами исключений в Sonar или АПК. Но тогда нужно вместе с библиотеками каждому потребителю поставлять и их, а это сложнее В других языках это тоже применяется, например, в Python или в С++ и C

Про фрейминг Представьте, что есть два инструмента, у которых вот такое описание: 1. Наш ИИ в 85% дает правильные рекомендации по коду. Используйте именно его! 2. Наш ИИ ошибается всего в 14% случаев - это самый низкий процент ошибок на рынке. Используйте наш инструмент! Что для Вас лучше сработает? С точки зрения математики и вероятности второй инструмент выгоднее, ведь он ошибается реже, чем первый на 1 процент. Но выбрать нам его не позволяет психология. Потому что нам гораздо больше нравятся успешные рекомендации. Ведь ошибки звучат плохо и тревожно и мы подсознательно от них отстраняемся. А вот успех и правильность нам нравятся и мы стремимся к ним. Это когнитивное искажение называется эффект фрейминга. Наше восприятие информации зависит от того, как она подана. И знайте, что в 80% случаях лайк под постом закрепляет идею!

«Сначала реши проблему. Потом пиши код» Джон Джонсон

Мертвый код Мертвый код - это код, который не используется. Удалите его. Сейчас статические анализаторы умеют определять такой код и подсвечивать его. Не нужно хранить в конфигурации такой код, в надежде, что он когда-нибудь пригодится. Скорее всего когда он пригодится вы не вспомните и начнете писать его заново. Если вспомните, то сможете достать его из системы контроля версий. Удалять мертвый код нужно тоже аккуратно и небольшими кусочками. Размер небольшого кусочка определяется самостоятельно, а не по количеству строк. Код:

// Новый код, который хорошо работает
Если Не Истина Тогда
    // Старый код, который мы оставили в конфигурации
КонецЕсли;
// Продолжение кода, который хорошо работает

Должен выглядеть вот так:

// Новый код, который хорошо работает
// Продолжение кода, который хорошо работает