Каждый из вас может оставить свой вклад в истории. И оно того стоит...

В 2005 году я окончил университет по специальности «Бухучет» и должен был стать бухгалтером. Но во время практики и первой работы случай свел меня с руководителем проекта по внедрению SAP R/3 в одном из крупнейших газодобывающих холдингов России. На этом моя карьера бухгалтера резко закончилась.

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

Будучи тогда еще молодым и не особо востребованным специалистом, я оказался в фирме, которая занималась разработкой для собственных нужд одной из газовых компаний. Время тогда было интересное – программистов еще не заваливали смузи-предложениями, и за вопросы в духе: «Есть ли у вас менторство в компании?» можно было получить хорошее ускорение в сторону выхода с собеседования. Никто ни с кем особо церемониться не собирался.

Да и программистов 1С (тогда еще 7.7) вообще мало кто считал программистами. Хотя… Возможно, я преувеличиваю. Пошутили, и ладно.

Немного истории

Изучить 1С тогда было достаточно непросто – программистами становились только те, кто действительно любил свою профессию и пытался разобраться во всем самостоятельно.

Попасть в эту сферу из-за хайпа или после курсов было невозможно, так как самих курсов практически не было. Одним из наиболее популярных источников информации тогда был форум Mista. Он и сейчас остается своеобразным сообществом по интересам. Но для меня Mista очень быстро закончилась.

Я очень быстро открыл для себя FormEx – если кто помнит 7.7, это инструмент, который позволял работать с формами, отслеживать движение мышкой, изменять размеры, передвигать элементы. В стандартной 7.7 с этим было немного грустно, и FormEx тогда давал нам больше, чем «восьмерка» сейчас. Поэтому для меня, как человека, который я хотел делать на 1С что-то красивое, но программировать толком еще не умел – это было в свое время отличное открытие.

Таким же открытием для меня оказался 1C++, который для программистов 7.7 тогда был практически как швейцарский нож. Однако первое, с чем я столкнулся во время работы с 1С++ – это отсутствие толковой документации. Сашу Орефкова было практически невозможно поймать, он – «птица гордая», пойди его найди. А все остальные тусуются на форумах, и задавать им нубские вопросы мне было неудобно. Поэтому я просто закатал рукава и начал разбираться сам – восстанавливать документацию, потихоньку перелопачивать.

В конечном итоге я сделал и выложил на форуме справочник по 1С++ и FormEx в виде специальных als-файлов, которые открывались в составе синтакс-помощника 7.7. Поначалу я думал, что это никому особо не понадобится – старожилы и так все знают. Но сообщество 1С++ мой вклад приняло, и это стало для меня большой неожиданностью. Люди, которых я считал практически небожителями, говорили: «Вау, молодец, классно». Я такого отклика действительно не ожидал. Поскольку я для них стал «своим», это дало мне право задавать вопросы и получать обратную связь.

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

• в стандартной 7.7 был свой синтаксис запросов, совсем непохожий на привычный язык SQL;

• 1cpp.dll позволяла сделать прямой запрос к SQL-базам данных в нотации SQL-языка с некоторым синтаксическим сахаром;

• а возможность делать прямые запросы к DBF из кода 1С появилась позже, когда Саша Орефков выложил 1SQLite, и там тоже был свой синтаксический сахар.

Т.е. в 1cpp.dll – соленый сахар, в 1SQLite – перченый сахар. Выбирайте каждый свой. А мы писали тиражное решение, которое хотели сделать универсальным, и мне, как руководителю разработки, было тяжело объяснить ребятам, что надо постоянно что-то комбинировать. Я посмотрел на недавно вышедшую «восьмерку», порадовался, как они классно сделали там язык запросов, и подумал – почему бы не сделать так же в 7.7?

Так появился класс ПрямойЗапрос – фактически аналог механизма запросов в «восьмерке». Он обеспечивал единый синтаксис, единое выполнение и единую параметризацию для абсолютно разных платформ. И главное – все это было открыто. Любой человек мог посмотреть, как там все сделано, и в случае необходимости адаптировать его под любую базу данных, учитывая особенности различных версий SQL. Там была документация – если не ошибаюсь, 150 страниц.

Дальше вышел класс ПоставщикДанных – аналог «восьмерочного» динамического списка, позволяющий буквально в четыре строки кода реализовать для справочника динамическое чтение и фильтрацию данных. Он тоже был полностью открытым, к нему была документация. Для меня написание этого класса стало квинтэссенцией и «лебединой песней» в 7.7, потому что с «семерки» я ушел практически сразу же после того, как его выложил. Так жизнь распорядилась, бизнес порешал. Тем не менее я эту разработку тащил до 2015-го года, хотя еще в 2011-м уже никаких дел с «семеркой» не имел вообще.

Получается, что учиться «восьмерке» я начал в 2010 году, полностью на нее перешел где-то в 2011, а в 2013-м у нас уже вышли свои собственные первые решения на 1Сv8.

Вот как выглядела наша «семерка», которую мы разработали в 2010 году – мне кажется, что она и в современных реалиях выглядит в целом адекватно. Все табличные поля и кнопки отборов работали так же, как сейчас работает динамический список. И для того, чтобы все это сделать, надо было написать по 4 строчки кода на каждую из них. Работало шикарно, и до 2015 года я все это поддерживал.

Эволюция мотивации. «Зачем оно тебе» от момента когда я только начинал джуниором, до сегодняшнего дня. Хотя, возможно, речь не столько о мотивации: просто «шило в одном месте»…

После перехода на «восьмерку», я какое-то время занимался своими основными обязанностями в бизнесе – руководил компанией, управлял разработчиками и учился.

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

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

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

Мне важно, чтобы код был разложен по областям, упорядочен и вычищен, и если приходится создавать множество условий «ИначеЕсли», я сразу оборачиваю их в отдельную функцию – просто потому, что цена рефакторинга всегда выше, чем цена за то, чтобы написать код сразу хорошо.

Раз в полгода я перечитываю 1С-овские стандарты. У нас есть собственные стандарты в компании, и мы периодически устраиваем некоторые споры. У нас есть некоторые отклонения, но они тоже имеют вполне себе железобетонные основания.

И я категорически не понимаю разработку по принципу Вовки из известного мультика «И так сойдет» – не приемлю такого, и не знаю, зачем это надо.

Цена open-source

Дальше был период «восьмерки». Поначалу мелкие разработки, потом – что-то более серьезное.

Сначала я выкладывал все это на Инфостарте. Чуть позже у меня появился GitHub.

На слайде показаны скриншоты тех разработок, которые вы можете найти на сайте Инфостарта и скачать. Они все существуют, и все работают.

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

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

Здесь можно вспомнить Юрия Дудя с его фирменным: «А что ты заработал на том, что выложил?»

Результаты довольно скромные – особенно на фоне более коммерчески успешных решений. Если взять всю эту сумму и разделить на 17 лет, получится примерно 500 рублей в месяц.

Плюс мне за все время пришел один-единственный донат – 250 рублей. Это произошло, когда в эпоху «семерки» я организовал что-то вроде краудфандинга – мы собирали деньги, чтобы оплатить доработку 1cpp.dll. Я тогда оплатил всю сумму из своих, а мне какое-то время еще продолжали поступать переводы, и в итоге пришло немного больше, чем я заплатил – те самые 250 рублей сверху. Было забавно.

«У самурая нет цели, есть только путь». Как начать, нужен ли план и что там ждет впереди…

Если вы хотите запустить свой собственный pet-проект, имейте в виду: выкладывать его в опенсорс или продавать – решать только вам.

В любом случае, нужно с чего-то начать:

• Определяем пул решений, которые у вас есть. Здесь важно не просто выбрать то, что вам нравится, а вспомнить себя в тот момент, когда вы работали над этими проектами. Выберите те, которые были для вас наиболее актуальны – кто-то сейчас проходит этот же самый путь, и для него это тоже может быть интересно.

• Начинаем классическую работу над ошибками – ищем «квадратные колеса» в нашем велосипеде. Анализируем, что мы накостылили и продумываем, как это переписать.

• Изучаем конкурентов. Конкурентов надо изучить с пристрастием, подойти к этому максимально честно. Возможно, на фоне чужих решений ваша разработка вообще не выдерживает конкуренции, но это не повод обесценивать себя – это нормально. Вам нужно понять, как люди это сделали – почему они туда пришли, и почему вы до туда не дошли. Возможно, вы просто чего-то не учли. Этот опыт пригодится вам в будущем.

• А если ничего не осталось? Если после составления списка вам кажется, что все уже все выложили – это неправда. Всегда можно найти какое-то старое решение от другого автора, которое давно не обновляется, и адаптировать его, если вы понимаете, что обновленная версия может оказаться востребованной. Например, CFU&CFE-reader, который я переписал, был пятилетней давности.
  Вложенные в такую разработку усилия окупятся знаниями. В большинстве случае, когда я делал свои разработки, я не всегда досконально знал используемую технологию. Я обычный человек – я что-то знаю, но в мире знаний в разы больше. Поэтому я изучал, разбирался, вникал. И теперь эти знания остались со мной, стали частью моего опыта и повысили мою ценность как разработчика. А я, тем не менее, пошел дальше.

• Когда мы разберемся с нашими разработками и решим, что можно выложить, нужно определиться со стоимостью. И здесь «я тебе один умный вещь скажу, только ты не обижайся»: некоммерческая разработка не легче коммерческой, а, возможно, даже сложнее. И объяснение этому достаточно простое:

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

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

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

• Продумать интерфейс. Даже если у вас простейшая разработка – потратьте время и сделайте ее красиво, чтобы люди захотели ей воспользоваться.

• Написать документацию. Хоть строчку, но выдавите себя. А программистам писать документацию – это всегда тяжело и больно. «Что тут писать-то? Тут же все работает, все понятно!»

• Отладить свой код.

• Определиться с площадкой. Основные варианты – GitHub и Инфостарт. Есть еще третья, Habr, но надо иметь железные нервы, чтобы попытаться туда зайти. Там 1С-ников прям любят.

• Оформить публикацию. Это тоже достаточно сложная работа, потому что нужно разобраться в требованиях к оформлению на площадке и изучить ее best practices.

А вот если вы все это проигнорируете, учитывайте, что срок жизни публикации на «Инфостарте» – неделя.

• Если ты не попал в топ, ты тонешь.

• Если ты попал в топ, у тебя есть еще неделя.

• Если успел попасть в обсуждения, у тебя есть еще две недели, а потом ты все равно утонешь.

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

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

Чему я научился у сообщества, и мои ошибки при общении с ним

Есть хорошее правило: «Хочешь идти быстро – иди один. Хочешь идти далеко – идите вместе».

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

Но когда речь идет о личном проекте, мой демон вырывается наружу. Я могу часами возиться с одной кнопкой, передвигать ее туда-сюда, а потом полностью все удалить и начать с нуля. Могу пообещать Инфостарту, что выпущу релиз через неделю, а потом: «Я тут такую фичу придумал, буду две недели ее пилить» – если я знаю, как улучшить реализацию, я не отказываю себе ни в чем.

Поэтому я вряд ли смогу научить вас работать с комьюнити. Есть большие open-source сообщества типа OneScript или Vanessa Automation – я смотрю на них и понимаю, что у меня так не получится. Для меня разделить свою разработку с кем-то – это все равно что вырвать кусок самого себя. Хотя, опять-таки, когда разработка переходит от чего-то личного к бизнесу, тут отчуждение происходит автоматом.

Поэтому считаю, что это уже скорее профессиональное искажение: когда я разрабатываю в open-source, я «важный птиц».

Роль открытых решений в развитии сообщества 1С

В завершение хочу сказать, что open source для всех разработчиков – это плечо, на которое мы можем опереться. Это наши учителя, источники вдохновения и инструменты, которыми мы можем воспользоваться.

Невозможно стать хорошим разработчиком, если ты не изучаешь чужой код. Можно изучать код типовых решений, но чужой код, выложенный в open source – это взгляд людей, которые вообще необязательно занимались 1С. Поэтому изучение open-source-решений приносит новые подходы и идеи, о которых просто мало кто задумывался.

Наиболее популярные open-source проекты 1С, выложенные на GitHub, перечислены в новости Инфостарта.

Кроме этого, есть специальный агрегатор 1С-ных open-source проектов OpenYellow, где собраны все репозитории GitHub по 1С, у которых есть хотя бы одна звездочка.

У пятикратного чемпиона по кроссфиту Мэтта Фрейзер есть такая фраза:

«Hard work pays off» – тяжелый труд окупается.

Разработка open source – это всегда тяжелый труд. Чтобы себя мотивировать, нужно иметь железный стержень.

Но поверьте, этот труд приносит большое моральное удовлетворение – ты понимаешь, что не только приносишь что-то полезное бизнесу, но и отдаешь что-то сообществу.

В конце концов, меня так учили: если ты где-то что-то взял, будь добр, верни это. Если не можешь вернуть, отплати добром за добро. Это – то хорошее, с чем нам всем потом жить.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.