гдето нашел этот не мой пост в 202о году , надеюсь в тему тут будет и для истории пригодиться : Я наверное единственный разработчик в России (в том числе как и со стороны пользователя), который по 12 часов в день одновременно сидит сразу во всех версиях конфигураций, ковыряюсь в них каждый Божий день. Знаю все в них от и до.
И вот впервые я создал файл, который начал вписывать самые существенные недостатки всех конфигураций. В один одни, в других другие и третьи.
Вопрос куда это все отправлять. А хотелось бы чтобы это попало не куда то там в суппорт для отписок или ожидания ещё пяти лет, а к людям принимающим решения.
Они могут показаться мелкими, но куда глобальнее чем кажется на первый взгляд.
Многие могут сказать - это же классно когда есть косяки!! Нет не классно!
За ковыряние никто денег уже не платит, а такие вещи глобально расходуют время, бывают его и мешают делать реально классные решения, так как для создания одной разработки для множества конфигураций нужно 200 процентов времени убить только на совместимость.
Сам уровень программирования на встроенном языке уже дефектен. Я об этом уже много раз писал. Это объясняется объективными причинами: 1. Популярными являются программы с низким порогом входа, когда может писать новичек. 2. Встроенный язык не прогрессирует десятилетиями. Это долго в мире ИТ. 3. Фирма 1С крайне закрытая и не дружелюбная когда ей сообщаешь о багах.
Нужно пройти семь кругов ада, что бы ошибку приняли _по старинке_, путем долгого общения с сотрудниками. Но и после этого нужно провести целое расследование, что бы узнать - исправляли ошибку или нет.
В результате вся внутренняя инфраструктура находится в состоянии "глубокого технического долга". Много кода нарушающие принципы, SOLID, DRY (от мелкого Запрос.выполнить.выгрузить, до повторения огромных запросов "при проведении", в отчетах, СКД), YAGNI - общие модули и БСП изобилует "брошенными" функциями. Семантика наименований объектов ущербна и неинформативна, абсолютно всегда "технарна". Например, (из https://its.1c.ru/db/v8std/content/469/hdoc), ОбщегоНазначенияКлиентСервер, РаботаСФайламиКлиентПовтИсп, РаботаСФайламиКлиентПереопределяемый.
Конкретно. Какая единственная отвественность (single resposibility) у модуля "ОбщегоНазначенияКлиентСервер" согласно _названия_? Да никакой - сумбур один. "КлиентСервер" - технарский суффикс, добавленный из-за ущербности среды разработки. Ну на самом деле признаки "На сервер", "На клиенте" в конфигурации указаны, почему их (цветом, иконкой) нельзя было показывать в дереве конфигурации? Зачем это десятилетиями писать в названии, увеличивая размер в мегабайтах конфигурации? Почему нельзя добавить еще один иерархический уровень в ветвях конфигураций? Что бы список "Общие модули" помещался в пределах высоты экрана, а не на 20 экранов? И т.д. и т.п. Не буду продолжать ибо это голос одиночки в пустыне.
Один из вариантов решения - обьединение партнеров 1с и параллельная разработка полностью альтернативного решения на стандартном , хорошо известном стеке технологий , например qt c++ или Delphi , python как сервер бизнес логики и Postgres для бд . Это позволит создать конкурентную среду и простимулирует 1с исправить все проблемы или , тоже постепенно , кануть в лету ... пример такого подхода - Una.md . Давайте дадим шанс 1с стать лучше 🙂
букинг зажрался — дерет завышенные цены за свои услуги с арендодателей, что вынуждает их ставить жесткий минимальный номерной фонд в надежде продать другую часть напрямую. Фактически Booking больше реклама. Получается в итоге что Booking задавил конкурентов и стал вести себя как монополист…
сервисы посредники типа AirBnb и Booking обречены на исчезновение, так как они не обеспечивают полного цикла автоматизации процессов ни арендодателя ни съемщика… а AirBnb проигрывает в части невозможности получения мгновенного отклика при бронировании
насчет «новый Spreadsheet контрол» это интерестно. Вот мы думаем про SpreadsheetGear ( www.spreadsheetgear.com ). Это когда то называлось FormulaOne (Tidestone) в варианте ActiveX на стандартной палитре Delphi/Builder C++ 5 версии. Вы делали матрицу сравнения между Spreadsheet и SpreadsheetGear?
еще книги по теме тут https://www.pdfdrive.com/murachs-oracle-sql-and-plsql-for-developers-d175343155.html
этот что в статье ?
гдето нашел этот не мой пост в 202о году , надеюсь в тему тут будет и для истории пригодиться : Я наверное единственный разработчик в России (в том числе как и со стороны пользователя), который по 12 часов в день одновременно сидит сразу во всех версиях конфигураций, ковыряюсь в них каждый Божий день. Знаю все в них от и до.
И вот впервые я создал файл, который начал вписывать самые существенные недостатки всех конфигураций. В один одни, в других другие и третьи.
Вопрос куда это все отправлять. А хотелось бы чтобы это попало не куда то там в суппорт для отписок или ожидания ещё пяти лет, а к людям принимающим решения.
Они могут показаться мелкими, но куда глобальнее чем кажется на первый взгляд.
Многие могут сказать - это же классно когда есть косяки!! Нет не классно!
За ковыряние никто денег уже не платит, а такие вещи глобально расходуют время, бывают его и мешают делать реально классные решения, так как для создания одной разработки для множества конфигураций нужно 200 процентов времени убить только на совместимость.
Сам уровень программирования на встроенном языке уже дефектен. Я об этом уже много раз писал. Это объясняется объективными причинами: 1. Популярными являются программы с низким порогом входа, когда может писать новичек. 2. Встроенный язык не прогрессирует десятилетиями. Это долго в мире ИТ. 3. Фирма 1С крайне закрытая и не дружелюбная когда ей сообщаешь о багах.
Нужно пройти семь кругов ада, что бы ошибку приняли _по старинке_, путем долгого общения с сотрудниками. Но и после этого нужно провести целое расследование, что бы узнать - исправляли ошибку или нет.
В результате вся внутренняя инфраструктура находится в состоянии "глубокого технического долга". Много кода нарушающие принципы, SOLID, DRY (от мелкого Запрос.выполнить.выгрузить, до повторения огромных запросов "при проведении", в отчетах, СКД), YAGNI - общие модули и БСП изобилует "брошенными" функциями. Семантика наименований объектов ущербна и неинформативна, абсолютно всегда "технарна". Например, (из https://its.1c.ru/db/v8std/content/469/hdoc), ОбщегоНазначенияКлиентСервер, РаботаСФайламиКлиентПовтИсп, РаботаСФайламиКлиентПереопределяемый.
Конкретно. Какая единственная отвественность (single resposibility) у модуля "ОбщегоНазначенияКлиентСервер" согласно _названия_? Да никакой - сумбур один. "КлиентСервер" - технарский суффикс, добавленный из-за ущербности среды разработки. Ну на самом деле признаки "На сервер", "На клиенте" в конфигурации указаны, почему их (цветом, иконкой) нельзя было показывать в дереве конфигурации? Зачем это десятилетиями писать в названии, увеличивая размер в мегабайтах конфигурации? Почему нельзя добавить еще один иерархический уровень в ветвях конфигураций? Что бы список "Общие модули" помещался в пределах высоты экрана, а не на 20 экранов? И т.д. и т.п. Не буду продолжать ибо это голос одиночки в пустыне.
Один из вариантов решения - обьединение партнеров 1с и параллельная разработка полностью альтернативного решения на стандартном , хорошо известном стеке технологий , например qt c++ или Delphi , python как сервер бизнес логики и Postgres для бд . Это позволит создать конкурентную среду и простимулирует 1с исправить все проблемы или , тоже постепенно , кануть в лету ... пример такого подхода - Una.md . Давайте дадим шанс 1с стать лучше 🙂
может пришло время написать статью продолжение про ЗРП?
Открытая модель сотрудничества от Unisim-Soft / UNA.md