Комментарии 160
Начинал рабочую карьеру с 1С, во франче работал, сначала установщиком, потом более продвинутым "конфигуратором" (называли меня программистом, но объективно говоря, тогда от установщика меня отличало только более глубокое понимание что и куда нажимать если установка пошла не по плану).
Потом погружался во все это более и более глубоко, и в 9-м году решил окончательно уйти с 1С. Причина - понял что стало просто очень неинтересно, большинство задач повторяются и выглядят довольно примитивно - отчетики там делать всякие хитрые, или править печатные формы в соответствии с новой дикой инициативой законотворцев, это все быстро приедается. Можно вырасти в какого-либо менеджера, но мне это не особо интересно. В итоге ушел сначала в С++, потом в Java и ни о чем не жалею. Впрочем и 1С не хейтю, в свое время заниматься этим было интересно и это был единственный доступный заработок программированием или около того (там где я тогда жил).
Хабр повзрослел, всё больше адекватных комментариев в статьях про 1С, а не стандартное нытье в стиле "1Сники это не программисты"
Я вообще как-то не люблю это меряние пиписьками - чей ЯП круче, я так считаю, программист должен быть быть просто программистом, ему не зазорно использовать тот ЯП, который лучше подходит под текущие задачи, другое дело что новые ЯП изучать надо, но это не проблема обычно для опытных разработчиков.
Так вопрос нафига пользоваться неудобным инструментом если есть удобные?
удобство 1с не в том, что он офигительно удобен для разработчика, а в том, что он офигительно удобен для бизнеса.
т.е. пока вы будете делать на своем удобном инструменте какую-то учетную систему, нуб-1сник правой задней ногой уже сделает нужное и сдаст бизнесу. Да, изрядную часть задач сделать на 1с весьма затруднительно, но принцип Парето никто не отменял… ну и в конце концов, ту часть задач, которую нельзя решить чисто 1с-ными способами, "освященными Нуралиевым", можно решить внешними компонентами, написанными на других языках.
У каждого инструмента есть своя область задач.
Так повторюсь. А разработчику то это нафига, в интересах работодателя гробить свой комфорт и удобство.
так повторюсь — разработчик работает на заказчика.
Работодателя разработчик выбирает сам. И нет смысла выбирать того у которого придется работать неудобными инструментами.
для этого надо быть разработчиком который может выбирать работодателей по этому параметру
Ну пока дефицит разработчиков вполне в наличии. Не отрицаю что 1с норм для начала карьеры, любая работа в айти лучше чем никакая, но задерживаться там слишком долго — странно.
Ну пока дефицит разработчиков вполне в наличии
сеньоров и топ-миддлов, да
а вот у остальных не так радужно
p,s, 1с как старт карьеры в ИТ это такое себе… потому что потом рестарт надо делать опять с джуна если переключится захочется
Да даже просто обычных мидлов нормальных найти проблема.
А рестарт — мелочи, если выбор вообще нигде не работать или хотя бы какого то опыта набираться, пусть не совсем релевантного, но прокачивающего вполне многие вещи. А уж если совмещать с пет проектами и самостоятельным обучением — вообще хорошо. Свичнуться придется на джуна, но рост до мидла будет довольно быстрым. Навыки отладки, поиска проблем, работы в команде, понимания задач, чистого кода и прочего не исчезнут, пусть и трансформировать некоторые из них придется.
Сейчас я рынок IT стороны джунов не знаю, раньше (начало 2000-х в провинции) просто выбора особого не было, рынок труда был очень маленький и если хочешь стартануть в программировании, то у 1С было мало альтернатив. Сейчас, м.б. с этим и лучше, не знаю..
В середине 3-его курса попалось объявление на программиста-стажёра 1С
То есть вам удалось и работать, и учиться одновременно? Очно или заочно? Расскажите об этом побольше. Мне трудно было совмещать даже заочное обучение с работой. Может быть кому-то тоже будет интересно, а то и поможет.
Кажется это крайне типовой кейс, сам ушел на 3м курсе. Сейчас мои студенты уходят там же. Где-то к 3му курсу появляется общее базовое понимание cs с которым можно врываться на стажировки. А по учебе обычно дальше лишь диплом и не так много важных фундаментальных знаний.
Учился и работал на двух работах. Учился очно. Тут всё индивидуально и очень много зависит от отношения руководства. В моём случае я учился в универе и пришёл на работу также учиться. Руководитель знал и понимал, что я студент и первую половину дня я скорее всего буду не доступен - это важно. В начале я работал за опыт и мне ничего не платили. Когда подучился и стал приносить пользу организации, стали постепенно повышать зп.
На первых курсах такое сложно будет совмещать, т. к. больше ощеобразовательных предметов и там преподаватели следили за посещаемостью - от неё зависело поставят ли тебе "автомат" или зададут ли доп. вопрос на экзамене/зачёте.
На более старших курсах большинство предметов уже узкоспециализированные и там как правило, нам давали на курс несколько лабораторных и предполагалось, что мы будем ходить на лекции, узнавать что-то новое и делать эти лабораторные. Но мне было проще посмотреть туториал на ютубе или прочесть статью на Хабре и сделать всё за час (вместе с изучением темы), сдать работу и не ходить на лекции, которые длятся 1,5-3 часа.
Ещё один вариант времяпрепровождения какой у меня был. На 3 и 4 курсе всё таки оставались занятия, где следили за посещаемостью и я просто приносил с собой ноутбук, открывал Word'овский документ и периодически вносил в него какие-то обрывки фраз препода. А по факту я заходил на сервер по rdp и работал или учился по 1С. Если у преподавателя какие-то вопросы, то Alt+Tab и я показываю документ, в который записываю его слова. Приходилось конечно распылять внимание, но у меня два варианта во время такого занятия было: или работать, или листать ленту в ВК)
В вашем случае на заочке есть проблемы. Во-первых, преподаватели с вами не знакомы и к вам они максимально беспристрастны. Пришли вы учиться, например, на программиста, а вам нужно сдавать диф. зачёт по истории России - ну такое себе, как для программиста вам это вообще не нужно, а время отжирает. Во-вторых, нужно быть очень дисциплинированным, что бы на заочке учиться. Именно учиться, а не клянчить троечку в зачётку во время сессии. В-третьих, если вы работаете, то работодатель может и не отнестись с пониманием и будет требовать как минимум тех же результатов в работе что и прежде.
Помню я совмещал работу и учебу в колледже было трудно, и идея оказалась не очень, то-ли я работу не ту выбрал которая только увеличивалась , то-ли я сам виноват не умел с организацией времени, в общем получалось так что я с 9 до 15 на учебе, потом домой, полчаса на отдых, а далее я работал до 10 часов. Итог? Увольнение и отчисление. Со временем и опытом жизни понял два момента, не надо было наверное идти туда, а надо было получить загран, и ездить летом на сбор ягод в Финляндию. Да это не престижно, не по профессии, но я бы заработал в разы выше чем на этой работе, а пока учусь все усилия отдать в обучение и в изучение английского языка, что дало бы два момента, первый работа сборщиком ягод позволила бы накопить на учебу в той же Финляндии, а английский позволил бы поступить учиться на высшее образование бесплатно. Тогда ещё можно было учиться на английском бесплатно. Но это мой опыт. У каждого он свой, но по мне полноценная работа и учеба очень сложно. Сейчас немного разгребаю последствия и учусь учится в другой стране. Как я туда попал это уже совсем другая история Каневский.jpg
Всё-таки здорово у вас получалось учиться и работать. Не все так могут!
Почему-то на очном (первоначально) у меня учёба была в режиме фулл-тайм и ни о какой работе речи идти не могло. Причём я бы не сказал, что у меня была проблема с самоорганизацией, так как я потом переехал в Екатеринбург и в новом вузе этой проблемы не было - от меня просто отстали и перестали загружать всякой ерундой.
А в чем вообще вопрос?
Решается просто - забиваешь на походы в универ и ходишь на работу. Иногда отпрашиваешься с работы сходить сдать сраные лабы и прочее универское говно. Работодатели, которые нанимают студентов нормально к этому относятся, по очевидным причинам.
Разруливать такие приколы это же основной скилл которому учит универ. Если не смогли этому научиться, считай вообще зря в универ поступали.
Основной вывод что я сделал за 3 года с 1С — что нафиг оно надо, еще полтора года проработал и свичнулся.
Ещё у 1С сайт есть со списком багов. Например в ERP их больше тысячи. Последнее исправление которое я ждал, шло больше полугода. Самое долгое исправление ошибки было больше двух лет. За все баги 1С бухгалтерия винит разработчика.
Разброс цен по доработке очень большой. Например, компания может взять больше двух миллионов, а сторонний программист 200 тыс.
Менеджеры в 1С работают лучше, чем программисты, впаривают ненужные программы по заоблачным ценам.
По 5 пункту - дикий бред, есть в любом кровавом энтерпрайзе под капотом. Особенно если это управленческий учет, там кровати переставляют ни чуть не реже чем в регламентированном, если руководство за руку не ловить, но они вам платят и тогда с ними контрить - себе дороже бывает и идешь на сделку с совестью. Хотя, бывает болото с каморами, где правок нет годами, тогда вы деградируете как специалист, и не важно на чем писано java, 1с, c# / f#..
Чтобы не деградировать, как специалист стоит заниматься собственными небольшими пет-проектами для прокачки знаний о инструментах и технологиях.
И теперь подскажите, как можно так развиваться 1С-разработчику в рамках своего стека, что изучать то? И сравните как может развиваться мидл в стеке в котором он работает - java, go, c#, js?
1С это все таки про инструмент который решает задачи бизнеса и про платформу на которой 1С пилит свои решения и продает.
Там мало чего про программирование/разработку в классическом понимании. О чем можно поговорить с 1С-разработчиком - SOLID?, Чистая архитектура?, как правильно писать тесты?, асинхронность/многозадачность?, CI/CD?, код-ревью (есть-нет не знаю) да как минимум с десяток вещей которые должен знать хотя бы крепкий мидл и выше.
На других стеках - это можно изучать самому, а не ждать когда на работе появится задачка.
О чем можно поговорить с 1С-разработчиком - SOLID?, Чистая архитектура?, как правильно писать тесты?, асинхронность/многозадачность?, CI/CD?, код-ревью (есть-нет не знаю) да как минимум с десяток вещей которые должен знать хотя бы крепкий мидл и выше.
А собственно в чем проблема? и SOLID, и тесты, и многозадачность, и CI/CD, и код-ревью - все это в разработке 1С есть. Далеко не все пользуются - да, есть такое, но вот чтобы указанного не было - это сознательное решение руководителя команды разработки/проекта.
И никто не мешает это все использовать самому, чтобы потом уйти в более квалифицированную команду. А если "и так сойдет", ну значит на том же уровне и останетесь. Это от языка программирования не зависит.
Ну ну, как вы на 1с реализуете последние две буквы солида? Особенно D? Никак. Да и с тестами печаль в т.ч. по этой причине.
Ну как бы SOLID это принципы написания кода на любом ЯП. 1С не исключение. Принципы "I" и "D" отлично реализуются на практике. Конечно, в языке нет для этого специального инструментария, и это приводит к дополнительным издержкам в виде описанных соглашений в команде.
Какая печаль у вас с тестами? У нас покрытие 90к LOC проекта 50%, и а более мелкие покрыты на 80+%.
И как вы мокаете источники данных? И вообще юнит тесты пишете?
А как D конкретно реализуете без возможности контракты задавать в коде?
Ну и про многозадачность забавно. До сих пор на фоновых заданиях делается через костыли? От бывших коллег не слышал что в этом плане что то кардинально поменялось.
И как вы мокаете источники данных? И вообще юнит тесты пишете?
Через mock-server мокаем внешние http-сервисы, есть моки для внешнего оборудования, серверов очередей и т.п.
Юнит-тесты классической структуры given/when/then. Формируем контекст вызова, вызываем функцию, проверяем результат.
А как D конкретно реализуете без возможности контракты задавать в коде?
Для начала вместо:
Функция А()
Б = Новый Д();
Б.Действие();
....учимся писать:
Функция А(Б)
ПроверитьЧто(Б).Это(Тип("Д"));
Б.Записать();
....Это уже переформатирует мозги разработчиков, и позволяет покрывать код тестами.
До сих пор на фоновых заданиях делается через костыли?
Какие странные у вас представления о костылях - ФЗ это как раз имплементация Thread.run(Action).
А как мокаете вызов базы, выполнение запросов, объектную модель?
А где у вас D если вы явно тип задаете конкретный и получается вполне обычная зависимость, а не инверсия? Задавать нужно контракт, а не конкретный тип.
А по поводу разницы тредов и фоновых заданий — у тредов сильно больше возможностей. Начиная от возможности память шарить, и заканчивая возможностью дождаться результата выполнения распараллеленной задачи на локе.
А как мокаете вызов базы, выполнение запросов, объектную модель?
База часть рантайма, смысла ее мокать нет.
А где у вас D если вы явно тип задаете конкретный и получается вполне обычная зависимость, а не инверсия?
Пример с передачей параметра вместо создания объекта внутри, это же самые азы "D". Т.е. этот принцип вполне применим уже с самых простых примеров. Обычно же там проверка, в которой проверяется наличие и типы полей нужных по контракту. Т.е. есть описанный контракт, есть его конструктор и функция проверки значения на соответствие контракту.
А по поводу разницы тредов и фоновых заданий — у тредов сильно больше возможностей. Начиная от возможности память шарить, и заканчивая возможностью дождаться результата выполнения распараллеленной задачи на локе.
Так и мы в ФЗ и лочим, и можем ждать, и можем запускать пулы обработчиков (десяками).
База часть рантайма, смысла ее мокать нет.
Ну вообще есть. Ибо логика зависит от того что вернет база. Можно конечно передавать данные извне, но часто логика требует нескольких запросов и поведение может ветвиться от результатов каждого из них.
Пример с передачей параметра вместо создания объекта внутри, это же самые азы "D". Т.е. этот принцип вполне применим уже с самых простых примеров. Обычно же там проверка, в которой проверяется наличие и типы полей нужных по контракту. Т.е. есть описанный контракт, есть его конструктор и функция проверки значения на соответствие контракту.
Выглядит как адок. И ладно когда чисто dto какой то. А что делать когда извне должен провайдер данных приходить какой нибудь, или фабрика? Как это без ООП реализовать то получится? Никак.
Так и мы в ФЗ и лочим, и можем ждать, и можем запускать пулы обработчиков (десяками).
Ну т.е. уже можно в методе с директивой &НаСервере написать что то вроде
Задания = Новый Массив();
Для Каждого ЭлементДаных из МассивДанных Цикл
Задания.Добавить(Новый ФоновоеЗадание(...));
КонецЦикла;
Для Каждого Задание из Задания Цикл
Задание.Ждать();
КонецЦикла;Или таки нельзя такое написать и придется тонны костылей городить?
Ну вообще есть. Ибо логика зависит от того что вернет база.
Ну вот к примеру простейший тест, на то что вернет база. Тесты функции СсылкаСуществует: https://github.com/yukon39/cfe_tests/blob/main/src/tests/CommonModules/ОбщегоНазначения/Ext/Module.bsl
В принципе тесты которым нужны данные в базе (а их подавляющее большинство) мы так и проверяем - формируем контекст, вызываем функцию, проверяем значение.
А что делать когда извне должен провайдер данных приходить какой нибудь, или фабрика? Как это без ООП реализовать то получится?
Передаете параметром нужный провайдер или фабрику. Внутри метода обращаетесь к нему. В чем сложности-то.
ИМХО, вы почему то считаете, что принципы SOLID применимы только к ООП языкам, а это совсем не так. То что на ООП языках эти принципы удобно иллюстрировать не означает, что только там они и работают.
Ну т.е. уже можно в методе с директивой &НаСервере написать что то вроде
Разве когда-то было нельзя? Указанный код вроде работает во всех платформах начиная с 8.0.
Задания = Новый Массив;
Для Каждого ЭлементДаных из МассивДанных Цикл
Параметры = Новый Массив;
Параметры.Добавить(ЭлементДанных);
ФоновоеЗадание = ФоновыеЗадания.Выполнить(ИмяМетода, Параметры);
Задания.Добавить(ФоновоеЗадание);
КонецЦикла;
Для Каждого Задание из Задания Цикл
Задание.ОжидатьЗавершения();
КонецЦикла;
Ну вот к примеру есть у вас метод который из базы должен запросить список ремонтов по объекту, затем дозапросить еще набор данных, над этими списками провести операции, в зависимости от результата запроса, записать данные, и вернуть часть данных вовне. Понятно что шаги вынесены в отдельные методы, но часть из них может вызываться или нет в зависимости от того что в данных на первом или втором шаге прилетело. Как вы подмените результат выполнения запросов, убедитесь что методы внутри вызывались нужное количество раз и с нужными параметрами, а некоторые не вызывались, подсунете данные нужные и т.п. без тех же моков?
З.Ы. И можно пример фабрики на 1с, ни разу такого чуда не видел.
Как сейчас реализована асинхронность?
Последнее, что помню (я немного пытался изучать 1С, но хватило на пару месяца) - это передача в вызываемый метод колбэка и контекста для него. Так и осталось?
Добавили Async/Wait инструкции.
Не прошло и 20 лет XD. Кстати в обоих контекстах (НаКлиенте/НаСервере) работает, или только в каком то одном?
Как и коллбеки только на клиенте.
Печалька сильная конечно.
асинх методы созданы для борьбы с модальными окнами. Какой смысл на сервере? Там можно использовать синхронные методы.
чтобы не блокировать поток при IO-bound операциях
А что плохого случится, если вы на сервере заблокируете поток? Сервер встанет?)
Ваш комментарий подтверждает мои слова про компетентность 1С разработчиков
По существу, сервер не встанет из-за того, что один поток заблокируется. Но сервер обрабатывает десятки-сотни-тысячи запросов в минуту и если на каждом будут блокироваться потоки, то наступит "потоковое голодание". За подробностями прошу в гугл поиск
Но вы же знаете, что 1с - это виртуальная машина, и выполнение байт-кода приводит к вызову соответствующих платформенных функций, внутри которых уже и треды и многопоточность и ожидания с блокировками. Ведь не крутит же пустой цикл 1С при ожидании внешнего ресурса. Есть там и тредпулы с очередями и никакого перерасхода потоков не происходит. Задача просто ждет в очереди до завершения IO операции (так же как и при вызове сервера SQL, например).
Поэтому ничем тут асинхронность в языке 1С на сервере не поможет.
Если сильно развит свой управленческий учет или конкретный отраслевой продукт ( сфера услуг / конфигурация для медцентра / строительства / фин. учета и тд.), а не голая типовая коробка с парой доработок, для отчетов государству, то в таком программном продукте есть место всему - чистой архитектура, тестам, асинхронности, многозадачности, CI/CD, код-ревью. Еще всякие прикольные интеграции могут оказаться (требующие хотя бы среднего знания веба), и все на 1С. Тут главное, чтобы повезло с местом работы, объемом работ (гвозди не дадут забивать микроскопом, если вся доработка - это добавить флажок). Ни кто не мешает крутить jenkins к разработке на 1С и он будет очень даже к месту, и архитектура не всегда тривиальна и есть место для дискуссий. Да, архитектура привязана к предметной области 1С и заранее так сказать обозначенным "классам" для учета, но там много мест где можно построить красивые и эффективные по времени выполнения решения, как раз за счет асинхронности, параллелизма и способа хранения данных. В 1С дофига чего про алгоритмы на стандартных структурах данных и программирование с учетом местного "ООП". В 1С это тоже можно изучать самому без задачи или на подработках.
Вы много на других языках писали? Как вы clean выстроите то когда у вас гвоздями все прибито в платформе к видению ее разрабов об архитектуре?
Тот же UI — MVC в довольно стремном варианте, где контроллер с вью совмещен. Максимум который возможен — логику в какой нибудь общий модуль вынести. Но только методы, которым придется модель представления передавать соответствием/структурой, а заодно все зависимости внешние которые этому методу нужны. В общем дикими костылями.
Мы на своих проектах выносим логику UI от логики объекта.
В типовых от вендора, да, там такого регулярно. Это довольно сильно напрягает разрабов, т.к. код вендора очень архаично выглядит по сравнению с нашим, а использовать надо и тот и тот.
Модули в 1С не имеют контекста, и весь контекст в вызов надо передавать явно. Это влечет за собой отдельные соглашения о том как создавать и модифицировать контекст. Зато упрощает выше озвученное тестирование, т.к. весь контекст можно создать за пределами вызываемого метода/общего модуля.
Ну т.е. приходится дико костылить, о чем я и говорил. Я под конец своего 4+летнего общения с 1с (свою коробку делали) достаточно от таких извращений наплевался. Зачем себя мучать если можно писать на нормальных языках?
Не вижу именно тут прям в этом жутких костылей. Контекст вызова общего модуля всегда известен, полностью передается извне - шикарное свойство для юнит-тестов. То что надо озаботится написанием обвязки - это потом многократно себя окупает. Четкого следования принципам SOLID вполне достаточно.
Рискую пованговать, но в вашем проекте эти вопрос не были решены, и это приводило к огромным вложенным структурам передаваемым в контексте. Этого добра прям много в типовом коде от вендора, и, увы, разработчики зачастую копируя этот стиль превращают свой проект в монстра.
Да в любом проекте задолбаешься по 10 параметров прокидывать. Форму прокинь, модель формы прокинь, отдельный контекст для "репозиториев" прокинь, общие модули прокинь (про I принцип и клин не забываем же?) чтобы была возможность подменить вызовы методов. И сверх этого непосредственно параметры метода еще. А потом это все еще и рефакторить придется с учетом того что типизация динамическая и нужно все держать в голове, а не на IDE расчитывать.
У вас слишком сложно все получается, и все в кучу - и собственно архитектура проекта, и тесты. На наших проектах как-то мы обходимся без описанных вами ужасов.
Что за контексты репозиториев и прокидывание общих модулей? Куда и зачем вы их прокидываете?
Ну суть клина заключается в разделении на слои, где внешние слои должны зависеть от внутренних, а не наоборот. Т.е. имеем вью, слой логики представления, слой бизнес логики, и слой данных (в простейших случаях).
На слое бизнес логики к примеру имеем метод который объявляет требования к структурам данных и внешним для себя интерфейсам, т.е. имеем аргументы исполнения бизнес логики + аргументы в виде колбеков для запроса данных у базы, записи в базу, и т.п. В некоторых случаях еще колбеки на логику представления (и в таком случае чтобы этим колбекам было с чем работать надо передавать в бизнес логику и форму и ее модель и сами колбеки). Например какая нибудь бизнес логика обработки заказов в зависимости от того на какой форме была задействована принимает извне общие модули с одними колбеками, а на другой форме с другими. Если нюансы обработки должны отличаться (ну т.е. паттерн "шаблонный метод", например).
Чтобы это все дошло до слоя бизнес логики (из формы например), мы из формы передаем форму, аргументы события и все нужные колбеки в слой логики представления, логика представления все это передает уже бизнес логике. Получаются цепочки вызовов методов с кучей аргументов. Хотя если делать используя DI контейнеры и ООП — все это задается декларативно на этапе конфигурации контейнера, и в нормальном случае из вью в логику представления идут только данные события, из логики представления в бизнес логику только данные нужные бизнес логике. Поскольку в инстанс интерактора через DI уже заинжектили все нужное заранее.
В контексте 1С не вижу смысла пилить вью отдельно, специально обученным человеком, пока другой что-то делает в параллели для бизнес-логики или работы с базой. Для прикладных задача, которые решают на 1С, такой подход зло - мое мнение. Это энтерпрайз и искать концы по виновным и чья хата с краю - такое себе, "я делал форму", "ой я писал запрос и события". Если конечно очень хочется, вешаешь подключаемые обработчики, убегаешь в общие модули обозначив только один вызов на форме при ее создании, для будущих "биндингов", но скорее всего за такое - тупой ложкой вскроет череп, следующий разработчик которому такое на поддержку упадет, фактически делаешь биндинги как в mvvm в wpf. Достаточно на какое-то время выйти в отпуск и на работу лучше не возвращаться. 1С сейчас в сложных вью сами подключают обработчики кодом или убегают с контекстом формы (вью) в общие модули, сопровождает это видимо "рептилойд", но это не от хорошей жизни. Надежнее отдавать объект на откуп 1 сотрудник, от формы до бизнес-логики, и пользоваться какими-то общими функциями наработанной под текущей проект "библиотекой" или стандартной библиотекой.
Выделять логику представления отдельно от самого представления стоит даже на проекте что целиком одним человеком пишется. Сильно поддерживаемость повышает хотя бы тем что не смешивается код меняющий видимость колонок и прочую визуальную шнягу и код логики представления, а код бизнес логики и работы с данными вообще на третий слой уходит. А про общие модули писал уже, дикий костыль ибо контекст и зависимости придется в каждый метод передавать. Тем более что в конфигураторе очень неудобно будет прыгать между модулем и формой, нормальных разбиений по пакетам нет.
Разделение на области модуля формы - это разве не оно?
В любой типовой есть области событий ("визуальная шняга") и область #СлужебныеФункции, в которой и место всей логике представления.
А логика данных - это вообще модуль объекта.
Это сильно не оно. Уж очень неудобно что все имеет доступ ко всему. Даже если работать на соглашениях — и в подсказках от IDE много мусора лишнего который надо проверять к какой области относится, и логика представления может не к одной форме относиться а к нескольким. Или вовсе только к части представления, но использоваться в куче форм.
Приведите, пжалста, пример логики представления при нескольких формах.
Чуствую, или тут должно решаться вкладками в одной форме или это вообще не для 1С подход (один объект - одна форма). Либо же это некая монструозная обработка, сочетающая списки со связанными объектами и прочими свистелками. 1С под это просто не заточена - плакать и колоться.
О чем можно поговорить с 1С-разработчиком - SOLID?, Чистая архитектура?, как правильно писать тесты?,
До вашего коментария я презрительно относился к 1С, но теперь понял что это не глупые ребята, раз даже они не ведутся на эту ернуду
Такой вопрос - а в среде разработки 1С, где Вы пишете код, уже появилось отображение номеров строк?
а зачем оно?
Ошибка в строке 761: бла бла бла
и как искать эту строчку в файле на 1к+ строк? вручную считать?
Ctrl-G 761
Ну или прямо тыком по ошибке, кнопку "конфигуратор", и попадаешь на нужную строку в нужном модуле.
Гит тоже не нужен. Открыл два блокнота, и сравнил что изменилось )
Понапридумывают тут всяких удобств, понимаешь. Лентяи!
Ну гит в EDT у них уже работает. Правда поди найди еще тот проект где EDT используется, а не конфигуратор. По крайней мере в мое время, 5 лет назад, было так. Да и общаюсь с коллегами, до сих пор не то чтобы прям распространен.
Это реально печально, если для языка, в его среде разработки, вам нужно смотреть на номера строк постоянно, и нет переходов. Тогда, вопрос - какой инструмент более отсталый. Мб это кончено определенная фобия, потребность ежесекундно знать в какой стоке модуля на 20к строк ты находишься или нет возможности сделать закладку.. или треск скрола, добавляет удобств к работе, вместо прямого перехода.
Выхлоп git для 1С сейчас только в том, что можно в больших командах перетягивать одеяла в работе над одной сущностью и не ждать друг друга - очень удобно, как и для хранения внешних обработок. Если говорить про сравнение, то старый механизм сравнения весьма ускорен по сравнению с собой прежним и отлично работает. Если обертку над git для 1С научат отлично показывать графическую разницу в формах, то будет совсем замечательно.
Мб это кончено определенная фобия, потребность ежесекундно знать в какой стоке модуля на 20к строк
У вас там файлы по 20к строк?
Не файлы. Модули. А в них может быть много кода.
А модуль, это что? Несколько файлов? Мы же о номерах строк говорим, значит имеет смысл говорить о размере именно одного файла.
Модуль — это вот такая приблуда.
В нем уже содержится код (функции, процедуры, перменные).
Если вы когда-нибудь работали с VBA, то 1С устроен по его подобию.
Ну, ок, хранится всё это не в файлах, а в БД, какая разница? Когда программист видит исходный код, он может никуда не переключаясь проскроллить 20к строк колесом мыши? Зачем вы занимаетесь буквоедством, вы ведь наверняка поняли мой вопрос с самого начала?
А какой вопрос был? Единственное, что я нашел, пролистав ветку вверх: "У вас там файлы по 20к строк?". Нет, код разбивается на модули.
Может проскроллить, но зачем?
20к не видел, максимум 15. Что тоже овердохрена, хотя Области несколько смягчают проблему.
Что тоже овердохрена
О том и речь. Если программист вынужден работать с такими полотенцами и не может их разбить на вменяемые сущности в несколько сотен строк, то, как по мне, система — дерьмо полное, а тот, кто такое придумал — некомпетентен и ему нечего делать в профессии.
Там 10кк строк всего. Сейчас они разложены по 3824 общим модулям (да блин, без папок, от этого бывает больно), и еще тысяч 5 наверное специализированных.
Предлагаете увеличить число файлов еще раз в 10?
Но вот сути боли от 20к строк в одном файле или разбить это по несколько сотен в 80 файлах я не ощущаю совсем.
Я же не скролюсь по всему файлу, я иду вслед за вызовами. И мне примерно пофиг, это вызов из соседнего файла или на 5к строк ниже в этом же. А сильно связанный код будет и в одном файле рядышком.
Ну, давайте все 10кк строк в один "файл" соберем тогда, вы же не скроллитесь, а по вызовам ходите. Норм будет?
Вот быстро нагуглил аналогичный по размеру проект:
Kernel Version: 2.6.27
Release Date: 09 Oct 2008
Lines in source-code files: 8.690.888 thereof
Code: 5.403.859 (62 %)
Empty lines: 1.909.206 (22 %)
Comments: 1.377.823 (16 %)
Lines of all files: 9.629.957
Files: 24.353
Source-code Files: 20.759
Average length of a source-code file: 419 LinesВо всей остальной индустрии считается, что файл, по фозможности, не должен быть больше 200-500 строк, чтобы с ним было удобно.
Анекдот в тему:
Звонит муж. — Алло, дорогая, только что по радио передали, что один псих едет по встречке. Будь осторожнее! — Один? Да их тут тысячи!
Это на самом деле серьезная проблема с которой мучался в бытность 1сником. Нормальных пакетов нет (можно подсистемами извращаться, но в плане удобства УГ все равно), и реально куча файлов на дофига строк. Приходилось городить префиксы тем же общим модулям, например. Ужасно.
Области позволяют видеть не "единым полотенцем", а именно по областям.
У этого есть и свои плюсы, и свои минусы.
"По вам" — возможно полное дерьмо, но ведь вы не верховный авторитет, правда?
иногда удобнее ходить внутри одной портянки вверх-вниз, нежели иметь тучу закладок страниц. Да, можно часть кода выносить в отдельные модули — но всегда существует некая середина между дроблением и объединением.
Короче, это не самый главный недостаток системы.
"По вам" — возможно полное дерьмо, но ведь вы не верховный авторитет, правда?
Про авторитеты вот тут написал: https://habr.com/ru/articles/737210/?reply_to=25581736#comment_25581732
в phpstorm, idea, pycharm (все одно по сути) я использую zen или distraction free режимы когда мне номера строк не нужны и пишу вообще без интерфейса и с кодом в середине дисплея, иногда с фоновой картинкой для настроения, ctrl+g тоже использую, но когда правлю баги я перехожу в обычный режим, т.к. часто смотрю на номера строк. Это удобно.
Не понимаю, как можно раскритиковать возможность/потребность отображения номеров строк в редакторе кода??♂️.
Ну вот в конфигураторе у вас и zen мода никакого не будет. Потому что там ни плагинов, ни настройки интерфейса нормального.
"никогда не говори никогда".
Ну вот в "голом" конфигураторе клюшек много чего не было, а вот в том же конфигураторе с опенконфом-телепатом-сциколорером была даже нежно любимая вами нумерация строк… И проработав "расширенным комплектом" лет 7, никогда не пользовался этой нумерацией.
Снегопат, конечно, тормознулся в развитии из-за лицензионных ограничений вендора, но я не исключаю возможности того, что он все-таки появится в нормальном виде (и да, нумерация, емнип, там тоже была. Но ее наличие никогда не упоминалось как какой-то плюс — видимо, настолько несущественная вещь).
Это все и близко не сравнится со всем многообразием плагинов для взрослых IDE. И даже в EDT проблемы будут из-за того что эклипс довольно мертвая платформа.
ну вот, вы уже перешли от "не будет" к "не сравнится с разнообразием". Начали торговаться - это хороший признак :-)
Гит нужен, конечно. Ибо ХоронилищеКонфигурации™ — это, хм, "так себе". Но гит работает только в EDT, а он сам по себе "чемодан без ручки".
Эти сложности из-за отказа от перфокарт. Их же просто наложил и увидел в каком бите отличие!
Конфигуратор.. правая кнопка мышка и пункт "переход к строке ..."
Подтверждаю, что номер строки в ide для 1С не нужен, это как подрулевые лепестки на некоторых машинах, люди их просто не жмут с момента покупки, но они есть и это греет душу, что как у всех четких пацанов. IDE поддерживает переход сразу в нужную строку по клику на ошибку или по Ctrl+G. Не нужно создавать мельтешение в глазах доп. информацией от IDE, которая не находит практического применения в контексте разработки 1С. В данном случае, это не "отставание" или консерватизм, а оно реально нафиг здесь не нужно. Номер строки и причина ошибки более внятные чем в c++ или erlang =))) как и номер строки для перехода.
то, что вы не пользуетесь определённым функционалом, не значит что он не нужен никому. Значит вы не попадали в ситуацию, когда этот функционал нужен. Что строки, что ваш пример с лепестками, этим пользуются, как это не выглядело для вас "ненужным"
Но объясните, зачем? чай, не на бэйсике пишем.
Я вот не могу себе представить такую ситуацию.
Даже там, где есть, в вижал студии, например, мне номера строк не очень нужны при написании кода. В пичарме тоже их не помню.
Перейти по требуемому номеру строки всегда можно, текущий номер строки отображается в строке состояния, остальные переходы (при отладкеи обработке ошибок) номер строки требуют очень редко.
номер строки требуют очень редко.
да не особо и редко, я частенько по номерам строки хожу (в пайчарме) если надо искать ошибку которая через какуюнить sentry прилетела
Но ведь и там тоже работает Ctrl+G? зачем они на экране?
чтобы по клавиатуре не тыкать лишний раз?
а вы текст в окне взглядом двигаете?
колесиком мышки?
ну так пальцами по клавиатуре удобнее, разве нет?
мне нет
Это же чистая субъективщина, кто как привык, я знаю что очень многие сочетаниями клавиш пользуются почти на всё, но я с годами так и не привык
могу согласиться. Но ведь тогда и "номер строки на экране" — "чистая субьективщина", не так ли?
Я привык даже интерфейсы проектировать так, чтоб без мышки работать. Ну да, не совсем 1с-ная идеология, но вот есть привычка такая. "пальцами" быстрее, во ттолько за счет этого операторы в своё время (когда настроил и научил) стали на 15% быстрее работать (стабильно "не хватало часа-полутора", их вынуждали задерживаться, что оборачивалось, естественно, текучкой — а новые работвают медленнее, что… Так вот, после оптимизации под пальцы — тот же объем заканчивали примерно за 15-20 минут до конца смены)
могу согласиться. Но ведь тогда и "номер строки на экране" — "чистая субьективщина", не так ли?
именно так, я собственно и не возмущался в этой теме по этому… 1С меня научила кодить в любом текстовом редакторе… потому что в семерке не было подсказок ни автоформатирования ни номерами строк я не морочился
тем не менее, ф-ция если есть она для некоторых удобна, для меня например
Ну и я кодил в "любых текстовых редакторах", включая вписывание кода в клеточки "Бланка программы", командный EDI на терминале, и прочим, включая написание собственной IDE, навеянной турбопаскалем.
В семерке был опенконф+телепат, что гораздо лучше голого конфигуратора восьмерки. Впрочем, вернувшись в самом конце 90-х к программированию, и поработав годик в голом конфигураторе 7.7, я открыл VisualC и ужаснулся. Но, к сожалению, VC ушла очень далеко вперед, а конфигураторы 1с остались на том же уровне начала нулевых.
Я не утверждаю, что фукнция отображения номеров строк на экране совсем уж бесполезна, но считать ее отсутсвие серьезным недостатком смешно. особенно на фоне остального. (лично я с 1с использую конфигуратор+турбоконф, без турбоконфа/снегопата там совсем уныло.)
но считать ее отсутсвие серьезным недостатком смешно.
да я собственно недостатком это не считал, я отметил лишь то что отсутствие какойто ненужной лично вам ф-ции не означает что ф-ция не нужна никому, неудобна и вообще "дураки какието ей пользуются"
я вообще только после этого треда обсуждений заметил что в 1С нет номеров строк (я всегда пользовался там именно переходом к строке) но теперь, имея уже гораздо больший опыт в большом ИТ, я бы там отображение номеров строк бы включил
Когда у вас в файле 200 строк, а не безумие из 20000, нужную строку часто проще и быстрее найти глазами. Ctrl+G, это, как раз, костыль для километровых простыней, с которыми работать сложно и неудобно.
Но объясните, зачем? чай, не на бэйсике пишем.Я вот не могу себе представить такую ситуацию.
Ну опять же, то что вы не пользуетесь или не можете представить себе такую ситуацию, не значит, что это не нужно никому, никогда и нигде) Зачем? Такой вопрос можно задать на любую функцию где угодно:
Зачем тёмная тема в IDE? Нормально же мне на белой.
Зачем сочетания клавиш, все же через правую кнопку мыши можно сделать, ну и через менюшки!
Зачем мне мышка, я с клавиатуры и курсором управляю, и всем остальным.
Я разве говорил, что "никогда и нигде"? я просил объяснить. Пока видел только одно объяснение — "чтоб удобно скроллить мышкой".
а за упоминание хоткеев, как видите, огреб минусов…
через менюшки, кстати, порой тоже быстрее, чем мышой мышить. Альт-кнопка-стрелка-стрелка-ентер, если нет прямого хоткея. не надо руку туда-сюда мотать...
Я в 1С не так давно — около 8 лет, но при мне отображение номеров строк всегда присутствовало:
Изображение с нумерацией строк
Это же всё бантики, да и потом, кто-то пишет на 1С в EDT (aka Eclipse), кто-то — в VS Code. Как мы вообще пришли к оценке языка по IDE? Здесь же дело в возможностях: условно, пока один человек будет рисовать интерфейс на HTML и CSS, второй будет писать на JS взаимодействие с бэком, а третий на PHP начнёт описывать структуру БД и работу с ней, всё то же самое один человек сделает в 1С за несколько минут и при необходимости сможет оперативно исправить недочёты. Преимущество 1С в скорости разработки и бизнес ценит именно это, как и 1С-разработчики.
По ИДЕ оценивается не язык, а сама экосистема. И ущербные инструменты разработки, как и токсичное сообщество, а также закрытые и не полные материалы сильно снижаю комфортность разработки. Сравните комфортность разработки приложения под .NET Core и приложения под 1С платформу.
Сначала я написал огромный абзац текста в попытке переубедить вас, а потом понял, что любой 1Сник подтвердит, что 1С — говно. Но она действительно намного удобнее, чем кажется со стороны, решает задачи, для которых предназначена и делает это быстро. По поводу токсичности не знаю: может быть, но я как-то зашёл с вопросом по Python на тостер и с тех пор мне все вокруг кажутся зайками.
но я как-то зашёл с вопросом по Python на тостер и с тех пор мне все вокруг кажутся зайками.
надо правильные вопросы задавать, только ПОСЛЕ того как вы исчерпали все возможности самостоятельно найти ответ. а не сразу идти на тостер/мисту/ещёкудато там спрашивать вопрос в стиле "а как рассчитывать НДС, я решил не использовать регистры, а результаты писать в справочники?" (удивляясь потом что над вами стебутся)
Это вообще особенность всего русскоязычного сообщества в интернете, злобно стебаться над человеком которому лень самому разбираться
надо правильные вопросы задавать, только ПОСЛЕ того как вы исчерпали все возможности самостоятельно найти ответ
В начале своего пути по наклонной дорожке 1С я назадавал кучу тупейших вопросов на форумах и узнал много нового о платформе из ответов, в которых не было никакой оценки моих интеллектуальных способностей и рекомендаций воспользоваться поисковиком, а позже ответил другим на ещё большую кучу таких же глупых опросов безо всякого загибания пальцев.
Это вообще особенность всего русскоязычного сообщества в интернете
Там выше стоял акцент именно на сообществе 1С и меня это задело т.к. я ни разу — честно, ни разу лично с этим не столкнулся в данном сообществе. Всё ведь просто: прочитал вопрос; шаришь? — объяснил. Не шаришь? — дождался ответа. Просто так лезть в какую-то полемику с перспективой перехода на личности, тратить на это время... это же иррационально. И ко мне так никогда не лезли. Может, мне просто везёт в этом плане в нашем уютном жёлто-красном мирке.
В начале своего пути по наклонной дорожке 1С я назадавал кучу тупейших вопросов на форумах и узнал много нового о платформе из ответов
вполне вероятно что вы задавали правильные вопросы.
Я это говорю потому что у меня очень большой опыт общения на куче всяких форумов и я очень люблю порассуждать-посоветовать на темы в которых разбираюсь и я отлично понимаю что говорят когда имеют в виду токсичность, это не зависит даже от отрасли… точно также ведут себя в автофорумах и на форумах ЖД фанатов например
Там выше стоял акцент именно на сообществе 1С и меня это задело т.к. я ни разу — честно, ни разу лично с этим не столкнулся в данном сообществе.
Просто так лезть в какую-то полемику с перспективой перехода на личности, тратить на это время… это же иррационально
Ну это вы вероятно просто не замечаете из-за того что не погружаетесь в общение ;)
Может покажется странным, но вместе с тем, что я перечислил, я считаю 1С достаточно хорошим в некоторых смыслах продуктом. Есть хорошие конфигурации, которые на порядки лучше, чем непонятные поделия от других фирм (в торговле есть УТ, например, в бухгалтерии та же конфигурация 1С:Бухгалтерия). Я знаю людей, которые много использовались и 1С:УТ и SAP в торговле. И вот 1С вспоминали, можно сказать, с любовью, после опыта с SAP. Так что, имхо, 1С не должно умереть, но вот трансформироваться во что-то более привлекательное им бы не помешало.
Для бизнеса 1с хорошо. Дофига дешевых разработчиков в любой дыре, стоимость ПО тоже не запредельная. Но зачем разработчику то себя хоронить под ворохом неудобных и закрытых инструментов, закрытого ишью трекера, закрытого партнерского форума, процедурного языка (причем даже в процедурный язык можно было бы дофига сахара добавить делающего его комфортным, вроде лямбд, но нифига этого нет) в котором вендор даже сборщик мусора нормальный не прикрутил и до сих пор на подсчете ссылок все работает (при этом таргетируя инструмент как среду разработки бизнес приложений)?
я думаю под нумерацией строк подразумевается нумерация всего кода, а не отображение позиции курсора
Клац для примера
Есть ли в этом смысл, или хотя бы преимущество? Выглядит как потраченный впустую приличный кусок монитора.
что же за монитор у вас такой, что 4-5 символов это приличный кусок)
а смысл искать строку номер 3569 по индикатору курсора? Когда коллега скажет "в файле таком то в такой то строке у тебя неоптимизированный метод, пожалуйста, пофиксь", не проще ли таким методом найти строку, чем рандомно щёлкать по файлу и смотреть рядом/не рядом? А еще может человек не в IDE пишет, а в редакторе, и компилит сторонним компилятором(это на тему CTRL+G или клац по ошибке).
"не в IDE пишет, а в редакторе, и компилит сторонним компилятором" — и от этого номера строк меняются? нет? ну тогда зачем "рандомно щелкать по файлу", или жать стрелки, или крутить колесо, если можно нажать CTRL+G и попасть сразу на нужную строку???
Потому что вывод компилятора не связан в данном случае с редактором, и CTRL+G ничего не даст? (Notepad++/sublime к примеру)
Выкиньте редактор с номерами строк не умеющий в CTRL+G. Он хуже, чем тот, кто умеет, но не отображает строки.
Тот кто умеет в CTRL+G и опционально может отображать номера строк конечно еще лучше.
погодите… Т.е. вывод компилятора "ошибка в строке nn" не означает, что ошибка именно в строке nn? тогда какую информацию несут номер строки в выводе компилятора, и номера строк в файле, если они не соответсвуют друг другу?
Какой то спор ниочём. В 1С есть инструменты по которым можно определить номер строки и/или перейти на конкретный номер строки. Это очевидно ибо ошибки выдаются с номером строки в коде.
В других языках IDE есть своя реализация этого, например если ты работаешь с PHP и правишь код в Notepad++ то имеешь возможность включить номера строк и перейти на нужную строку.
Вопрос аналогичен "а как вы на русском пишете код" и выглядит, как попытка подколоть 1Сника.
Я писал на 1С в 90-х. В 1998-м написал последнюю строчку и закрыл для себя эту деятельность.
25 лет прошло. Но до сих пор прекрасные воспоминания о вполне логичной системе. Не без косяков, конечно, но простая и понятная.
Будет голодно - пойду опять строчить.
98 год? это 6 версия от которой тянутся шутеечки что оно очень странно работает, потом были клюшки, логика которых уже более человеческая но после нормальных ЯП… у меня после C# и внезапно VB… оооочень сильно пригорало от 7.7 и то как там все логично и правильно (в кавычках)… где в одном месте надо какието приседания (создать объект, выбрать объект… тут значение… а вот тут ТекущееЗначение (сам догадайся где как правильно)… а через два шага… а забей можно прям напрямую все вызывать… это у нас архитектор упоролся в ООП и решил оттуда чето дернуть но не докурил доконца по этому вот так)… или запросы которые сегодня отдают одно завтра другое, файловая база возвращает select * from aaa where id>10 одни данные, а на sql базе уже другие… хотя казалось бы, 1С это же ОРМ фактически… но нет, разработчик обязан помнить это все
в 8 уже да, стало все гораздо более человечно
но именно после 6 и 7 одинес не любят за такую наркоманию и в коде и в логике
файловая база возвращает select * from aaa where id>10 одни данные, а на sql базе уже другие…
Это сильно вряд ли - сам набор данных (количество строк и каждая строка в отдельности) будут идентичны, а вот идентичный порядок строк указанного запроса, даже в рамках двух последовательных вызовов, вам не гарантирует ни одна современная СУБД.
Вы уже забыли проблемы семерки с БД? (я привел пример сферический в вакууме, проблемы там помоему были в сложных конструкциях)
Там мало того что большая часть релизов платформы 7 фиксила именно глюки SQL, так они до конца их и не исправили из-за чего пользоваться языком запросов там считалось не очень хорошей идеей если база SQL, а если всётаки SQL использовался то в ТиС, который был почти весь написан на таких запросах приходилось всякие костыли втыкать чтобы оно нормально работало и всёравно надо было помнить что оно не всегда ровно работает
Если вы в ТиС и вообще в 7.7 использовали такие запросы, то это точно не проблемы движка платформы 7.7. Это решение сторонних разработчиков так позволяло делать, причем через инжект в стандартные dll платформы. Вполне логично, что сторонний продукт мог работать нестабильно, и странно при этом предъявлять претензии к релизам платформы, которые якобы "чинили эти глюки".
я имею в виду именно штатные запросы к базе, не сторонние
в ТИС они в каждом утюге
"сторонний продукт" как раз работал быстро, качественно и устойчиво.
а вот "штатные запросы" в 7.7 — это редкостное уродство. Впрочем, причина понятна — они делались под файловую структуру БД. Что, конечно, не извиняет, но объясняет. ну и дtлалось это 25 лет назад, когда некоторые тутошние критики cnhernehs 1с еще читать не умели.
Вы на 7.7, наверное, писали?
Задачи мне поступали напрямую от клиентов и для всех задач у меня был
равный приоритет. Все они срочные, важные и все должны быть сделаны в
ближайшее время. Так вот это не так. У каждой задачи есть приоритет и
нужно уметь его правильно определить, чтобы знать что делать в текущий
момент времени.
Для этого скрамы всякие существуют...
Мои выводы после почти 10 лет разработки:
1С - жадные консерваторы. Оборачивают классические технологии в свои оболочки, придумывают неудачные альтернативы и самобытную терминологию, замыкают на свою экосистему и берут за это деньги. За исправление всех проявившихся багов косвенно руками франчайзи берут дополнительные деньги. Документация - по подписке за деньги. Просто очень нужны деньги.
Коммьюнити делает для 1С больше, чем сама 1С. Увлеченные искренние умные парни тащат в нее юнит-тесты, коннектят брокеры и шины, пишут линтеры и автоматизированную проверку кода. 1С молча смотрит на это... и делает вторую среду разработки, соперничающую с основной. Причем потребности в механизмах реально существуют, но остаются незакрытыми вендором.
Туманное будущее и внутренняя неопределенность. 1С сейчас пытается усидеть на двух стульях - повернуться лицом к людям, услышать просьбы коммьюнити и немножко выйти в опенсорс и одновременно забрать славу SAP и спрятать ключевой код от просмотра и изменения в связи с уходом последнего. Как можно быть нацеленным одновременно на малый, средний и большой бизнес с противостоящими оконечносиями шкалы "гибкость доработки/приведение к стандарту", я не понимаю, но очень интересно посмотреть, что получится.
Эклектичность и устаревание платформы. По сути, платформа - это предметно-специфичный фреймворк на бэйсике без возможности изменения своего исходного кода с урезанными и изуродованными концепциями ООП, клиент-серверной архитектуры и модульности. Если проводить аналогии со стройкой - это дагестанский самострой с кучей пристроек и еще пристроек с трухлявыми входными дверями и золотой лепниной внутри. При внедрении новых возможностей не проводится ретроспектива и не привносится сквозная цельность и единообразность.
При всем при этом, в профессии очень много разумных осознанных пытливых специалистов с уникальным опытом и творческим бэкграундом, заставляющих платформу танцевать на углях под свой душевный ритм. Либо ты принимаешь границы вендора и живешь в них без света и радости, либо один раз ломаешь свой страх изменений и новизны и становишься в среднем смелее, увереннее и компетентнее усредненного специалиста из другого языка, потому что видел в жизни и кромешный ад отбитых стандартов, и ангельский свет просветленного ничем не скованного сознания.
При всем при этом, протипирование происходит почти мгновенно и под разные условия - мобильную разработку, веб, тонкий клиент, чистый бэкенд, чистый фронтенд. С масштабированием, стандартизацией и передачей опыта все сильно хуже, но циклы обратной связи, решение в моменте и итеративная разработка - на высоте.
При всем при этом, внешний инструментарий не от вендора, а от евангелистов хоть и не очень многогранный и разнообразный, но действительно качественный и сделанный с любовью и заботой к своим коллегам.
И согласен, что работа на 1С будет, и ее будет много. Просто сложно расставить ориентиры и понять, что такое хорошо, а что такое плохо и выстраивать план развития.
Согласен. Только, имхо, то, чем 1с поворачивается к людям — это не лицо… Но остальные части тела еще ужаснее.
1С - жадные консерваторы. Оборачивают классические технологии в свои оболочки, придумывают неудачные альтернативы и самобытную терминологию, замыкают на свою экосистему и берут за это деньги. За исправление всех проявившихся багов косвенно руками франчайзи берут дополнительные деньги. Документация - по подписке за деньги. Просто очень нужны деньги.
Лол, да 1С это русский еппол
~13 лет опыта, согласен по всем пунктам
" Так вот, очень часто попадаются некомпетентные люди, которые не хотят выполнять свою работу и любят перекидывать ответственность, заявляя что-то вроде: “Проблема в вашей программе, у нас всё в порядке”. "
О любимая песня всех 1Сников - написать быдлокод и спихнуть все на железо и сисадминов. Или развернуть БД, не настроить мейтененс, а потом кричать, что это железо тупит. Проходили много раз.
Самый эпичный случай: прибегают 1Сники с запросом нужен новый сервер, старый дико тупит на выгрузке какого-то отчета. А железо на серваке и так одно из топовых по тем временам. Заставляем показать код выгрузки отчета........ И вуаля!!!! Открытие и закрытие файла ексель внутри цикла выгрузки. Т.е. открыли файл, записали ячейку, закрыли файл, открыли, записали, закрыли
Работаю веб-разработчик (фул-стак), иногда занимаюсь связыванием 1С продуктов с моими веб-сервисами. Из-за этого иногда приходится что-то писать под разные конфигурации 1С. Так вот, опишу проблемы, почему я бы никогда не стал быть разработчиком 1С на полную ставку:
1) Устаревшие технологии и подходы, игнорирование архитектурных подходов и т.д. Подавляющее большинство приложений 1С - это монолит с кучей процедур делающих тоже, что и другая процедура, только с розовыми рюшечками.
2) Низкий уровень обучающих материалов. Платная база знаний, неполные материалы, многие учебники начинаются с конкретных примеров как сделать такую-то фигню, без описания концепции и подхода в целом.
3) Очень токсичное сообщество. Это прямо просто жесть - зайдите на мисту и на вопрос "Как сделать фичу N?" вам ответят: "Наймите разработчика." Если сказать, что ты разработчик, то тебя попытаются унизить, хорошо если дадут ответ, но скорее всего только унизят.
4) Проблемы с контролем версий. Отдельный вид, файлы кода в своих форматах, всё зачастую запрятано в бинарные файлы и т.д. Невозможно использовать подходы, применимые в почти любых других областях IT.
К плюсам стоит отнести нередко хорошие конфигурации, которые похоже разрабатывались с диким трудом и потом. Однако, в той же торговли решения сторонних разработчиков обычно и близко не стоит по возможностям с 1С:УТ, например.
В общем, 1С экосистема в целом - это набор хороших и не очень продуктов, построенных на устаревшей технически базе и управляемый слегка невменяемыми менеджерами из 10-х.
UPD: Вспомнил еще один момент. Среда разработки (конфигуратор) - ущербное поделие времен делфи-паскаль. Например, нельзя перенести курсор сдвигом вправо (он будет уходить в бесконечность). И там еще много таких стремных вещей, которые после студии/идеи кажутся пережитками прошлого из 0х-10х.
А вот, кстати, к коду на русском языке привыкаешь очень быстро.
Базу данных по языку и платформу вроде открыли. По конфигурациям — просите доступ у владельцев конфигураций, которые стучаться к вашим сервисам, если они настолько специфичны, что модуль написанный для БСП им не подходит.
Не ходи на мисту, ходи на Инфостарт. А еще лучше — на partners.v8.1c.ru (правда там квест тысяч на 7 чтобы доступ получить)
Хранилище для конфигураций и расширений, git для вненшних обработок — если ты старпер. git для всего — если модный
UPD — любителям модных IDE — в эклипс (точнее EDT)
. Это прямо просто жесть — зайдите на мисту и на вопрос "Как сделать фичу N?" вам ответят: "Наймите разработчика."
и правильно сделают, потому что 1С это коммерческий ентерпрайз который стоит денег, на мисте вам ответят на сложный и интересный вопрос, но когда 100500раз приходит человек и начинает "Я решил перейти на опенсорс, перенес сервер на линукс и у меня почемуто сыпятся ошибки "невозможно создать COM коннектор", памагити!!!.. и когда за ответом что COM на линуксе не работает, начинаются вопросы чем заменить, а как? а примеры? а еще? заткнитесь кто не хочте помогать вы мешаете, ну отвечайте мне что мне делать!!! немедленно!!! (бан)
просто потому что простые вопросы через которые сквозит то что человек вообще не разбирается в вопросе ведут за собой просьбы сделать работу за него… из за чего следует ответ "наймите разработчика"… и если вам такое ответили то это значит что ваша квалификация недостаточна, а уровень консультаций превышает то что обычно можно получить бесплатно
я на мисте с 2007 года, задал чёто типа — три вопроса, на который мне сумели ответить только на один, а в остальных двух скрипение мозгов закончилось ничем… но никто не сказал "наймите разработчика" или какимто образом стебался… либо тупо никто не знал либо вопрос был слишком сложным (и вопрос сместился в советы — менять бизнеспроцессы)
Я не задаю вопросы на форумах ни по каким темам, только гуглю документацию и эти самые вопросы от других. За много лет я дважды хотел задать вопрос на SO, но после того, как подробно расписал проблему, находилось решение, и вопрос публиковать нужда отпадала.
А вот именно при гуглеже по 1С чаще всего возникало или "ты лох, найми разработчика", или "это бесплатная версия документации, оплатите доступ".
Из примеров, которые у вас написаны, вопрос "чем заменить COM коннектор в конфигурациях, которые типо есть под линукс, но типо нет" - это абсолютно валидный вопрос и адекватный вопрос. Если разработчики сделали кроссплатформенное решение с не кроссплафторменными частями, то такой вопрос обязательно возникнет и должен быть хорошо описан.
" заткнитесь кто не хочте помогать " - обычно пишут после того, как написали "автор лох, выпей йаду, найми разраба". И именно "автор лох" - это токсичное поведение. Если не хочется помогать, всегда можно либо пройти мимо, либо кинуть ссылку на нужный раздел документации.
Если разработчики сделали кроссплатформенное решение с не кроссплафторменными частями, то такой вопрос обязательно возникнет и должен быть хорошо описан.
именно, там есть замена этой технологии, однако она требует кардинальной переделки всех обработок на нее, замена там не бесшовная… и зачастую 1С разработчики крайне далеки от веб-разработки чтобы даже просто прочитав документацию с легкостью реализовать написанное… к томуже подавляющая часть примеров и всяких обработок накопленная годами написана на COM, а отнюдь не на вебсервисах… т.е. годами проверенную обработку скачанную 10 лет назад с какогонить инфостарта надо переписывать чутьли не с нуля самому
по этому когда человек спрашивает про КОМ… это также как к вам подойдет человек и скажет я учился и всю жизнь ездил на авто с АКПП… а тут МКПП… поясните парой слов как мне на ней ездить? показывать и учить не надо, просто словами скажите, это же просто должно быть! Вы отправите его в автошколу? (нанять разработчика?? как в 1С)
Например, нельзя перенести курсор сдвигом вправо (он будет уходить в бесконечность).
помогал стажеру настраивать конфигуратор, вспомнил, что не ответил своевременно на вашу претензию (вот такой я тормоз, и вот такое ассоциативное мышление).
можно. Это настраивается.
Мой вывод спустя 7 лет работы 1Сником:
Быстрое достижение результата. Не надо создавать 100500 классов в различных слоях чтобы добавить новый документ. Захотел добавить новый отчет, легко, смышкой накликал и готово.
Легко войти в профессию, но трудно выйти. Берут всех, если есть руки и не ссышься, то отлично, у тебя есть все шансы стать 1сником. К сожалению чтобы перейти на другой язык программирования приходится прикладывать не мало усилий, и лучше никогда не упоминать на собеседованиях что ты работал 1Сником, потому что этот опыт никто серьёзно не воспринимает.
Много вакансий, но крайне низкое качество этих вакансий. Вакансий только по Москве не счесть, работы найдется каждому, но в 90% случаев это автоматизация ларьков, про удаленку не слышали, про ДМС, а что это? Если начальство тебя не видит значит ты не работаешь.
Низкие зарплаты. В моменты когда уже сильно вырастаешься как специалист, чтобы найти вакансию на 250к уже придется постараться. Чтобы найти вакансию за 300к, в большинстве случаев уже просить знакомых. Найти вакансию свыше 300к это из области фантастики.
Оверхед требования на высокооплачиваемых вакансиях. Хочешь зарабатывать много, нужно быть отличным аналитиком и разбираться в типовых решениях, отличным программистом, нужно быть архитектором и руководителем и починителем примусов и все это в одном человеке.
5 выводов, сделанных за 3 года работы разработчиком 1С