()
Думаете на другом языке программирования, разработанная типовая конфигурация имела бы меньше каши?
Дело не в другом языке. Можно и на 1С - если его усовершенствовать.
А свобода - да - она может срывать башню - поэтому тут важно не просто давать свободу - тут важно ещё и обучать правильно ей пользоваться - как минимум - обязательно читать книжки на подобии "Чистый код" Роберта Мартина. Смотреть обучающие видео. Формировать регламенты. И на своём примере (я говорю о типовых конфигурациях) показывать как применение этих рекомендаций упрощает программирование и анализ кода. Вообще нужно повышать культуру программирования. И да, сами технологии без культуры - бесполезны, какими бы крутыми они ни были.
Но сейчас типовой код 1С просто ужасен. Сдаётся мне - это вообще сделано намеренно - чтобы у программистов, которые потом будут это дорабатывать и обновлять, было больше работы - чтобы франчайзи смогли заработать. Обратная сторона - это отпугнуло молодые кадры - от того и кадровый голод!
Ограниченный код задает стандарты
Любой синтаксис задаёт те или иные стандарты. Но ограниченный - просто в итоге может начать загонять программиста в бутылку - код не будет легче - он будет становится всё запутаннее и запутаннее. Особенно когда мозг знает о крутых фишках в других языках - хочет их использовать и но в силу ограничений не может - и начинает изобретать велосипед с ромбическими колёсами!
Описание типов и тд есть в едт
Что Вы имели в виду?
Я говорил о возможности, скажем, задать тип аргумента функции (и возвращаемого значения):
функция МояФункция (Арг1 : Число(10,2), Арг2 : Строка(100,.Фиксированная)) : 'СправочникСсылка'
возврат Справочники[Арг2].НайтиПоКоду(Арг1);
КонецФункции
ну или задавать типы полей при описании класса
Класс МойКласс
Перем Поле1 : Число(10);
Перем Поле2 : Строка;
Перем Поле3 : {Число, Строка};
Перем Полe4 : 'ДокeментСсылка.ПоступлениеТоваровУслуг';
Перем Поле5 : НекийМодуль.КакойтоКласс;
КонецКласса
Хотя переменным тоже можно задавать тип (хоть это, возможно, менее актуально)
Перем А : 'СправочникСсылка.Номенклатура' = МояФункция (1000001,"Номенклатура") КАК 'СправочникСсылка.Номенклатура';
Ну или с выведением типов
Перем А = МояФункция (1000001,"Номенклатура") КАК 'СправочникСсылка.Номенклатура';
ну или так - с выведением типа статически - т.к. тут все известно на стадии компиляции; и его фиксации для переменно А - "СправочникСсылка.Номенклатура"
Перем А = МояФункция (1000001,"Номенклатура") &СтатическаяТипизация
При этом сам языки остаётся с динамической типизацией. Эти ограничения типа - не более чем части описания контракта API - просто декларирование доп. проверок, в т.ч. статических во время компиляции. Ну и документацию (в т.ч. для всплывающей подсказки при редактировании программы) на их основе автогенерировать можно.
И да - я знаю, что это можно описать в комментарии, и да, я понял - что Вы имели в виде - то что EDT умеет это выводить в всплывающей подсказке. Это, конечно плюс, но всё-таки это всё через одно место и очень ограничено! Я за более масштабное описание - с проверками - полноценное контрактное программирование!
И да - конфигуратор это тоже умеет делать - см. прикреплённую картинку
работа на 2 экрана
Что Вам мешает работать в конфигураторе на два экрана - я, вот, без проблем работаю!
git
Есть в EDT - и надо полагать - это будущее разработки для 1С - когда туда всё перенесут - со временем от конфигуратора 1С, скорее всего, полностью откажется.
Да и к конфигуратору МОЖНО GIT прикрутить!
Директивы компиляции в общих модулях как бы есть
Да, поэтому я ставлю почти все свойства у общего модуля пишу вот так в рамках одного модуля
#ЕСЛИ Клиент ТОГДА
Функция МояФункция()
КонецФункции
#КОНЕЦЕСЛИ
#ЕСЛИ Сервер ИЛИ ТолстыйКлиент ИЛИ ВнешнееСоединение ТОГДА
Функция МояФункция2()
КонецФункции
#КОНЕЦЕСЛИ
Показать
И так с каждой функцией по отдельности - вместо того, чтобы просто написать перед ней "&НаКлиенте" и "&НаСервере&НаТолстомКлиенте&НаВнешнемСоединении" (лучше без приставок "На").
Правда, ещё - так отладчик 1С глючит - есть проблемы с точками останова - приходится - вносить директивы внутрь функций - тогда проблем меньше.
Но, я не могут так добавить "ВызовСервера" и "ПовторноеИспользование" (и "Привилегированный" - хотя в этом как раз особой нужды нет).
Приходится всё равно для этого создавать отдельные модули - просто блованки - и писать вот так
Отдельный модуль, например с ВызовСервера с именем "МойМодульВызовСервера"
функция МояФункция()
возврат МойМодуль.МояФункция();
КонецФункции
Основной модуль с именем "МойМодуль"
функция МояФункция()
#ЕСЛИ не Сервер ТОГДА
возврат МойМодульВызовСервера.МояФункция();
#КОНЕЦЕСЛИ
//Какой-то алгоритм
КонецФункции
Показать
Я бы пошел по пути глобальной модульности, а не глупости с функциональными опциями
ну - модульность это да - вещь крутая была бы - но это отдельная тема.
А вот, функциональные опции - вещь хорошая - просто реализация хромает.
Нужно было делать так, чтобы:
1. Их значения могли быть получены ещё на стадии сборки конфигурации (компиляции)
2. Их можно было назначать на почти все обеъекты метаданных и элементы кода
3. Препроцессор получал бы их значения и сразу отключал бы лишние элементы метаданных, элементы интерфейсов и блоки алгоритмы - полностью исключая их из собранной конфигурации информационной базы.
4. Такой подход так же бы позволив вариативно подклбючать разные реализации алгоритмов и типов данных из разных библиотек или классов
5. Ну, вариант нежёсткого исключения (а только формального отключения использования для определённых сеансов) тоже можно оставить - для динамически подключаемых расширений это может быть хорошо.
В конфигуратор можно было бы внести объект "Нечто", а из него лепить необходимую сущность.
Вот тут ничего не понял- что за страшное "НЕЧТО"?
Я бы еще с многопоточностью как на уровне клиента, так и на уровне сервера поработал бы.
Многопоточность - это тоже - отдельная тема - но её внедрение явно не сделает разработку легче
Вообще, идей можно наклепать много.
У меня их вагон - часть уже описана - когда-нибудь выложу в виде статей - может будет кому-интересно почитать - а может и вызовут обширную дискуссию - которая со временем сможет повлиять и на развитие 1С Предприятие - скажем для поколения 1С: Предприятие 9
