Это с чего вдруг? Функционал, известность, саппорт и доступность специалистов на рынке это кузов / салон авто, бренд, СТО, заправки и наличие механиков. А двигатель это как раз платформа.
То есть с теслой тоже самое было. Где вы ее заправлять будете, где чинить, вы же за город выедете и встанете, она сырая и все такое. Но как обычно инноваторы, early adopter'ы и пошло поехало. Но конечно они это на самой благодатной почве делали — в Калифорнии. В Омске им бы конечно посложнее было :)
Проблемы-то у них возникли не из-за груза накопленного опыта, а из-за грубых управленческих ошибок.
Это проблема всех корпораций. По факту все инновации идут за их пределами, так как корпорации слишком инертные. Да и им проще потом купить выскочек, чем самим делать (хотя понятно, что с гуглом, фейсбуком, теслой это например не прокатило, а скажем с инстаграммом или ютюбом прокатило).
И смотреть они будут не на то, какая там внутри красивая объектная архитектура, и как эффективно работает внутренний ORM, а на то, насколько система соответствует текущим потребностями бизнеса «из коробки», насколько она понятна пользователям, какие риски внедрения и т.д.
Так и в тесле люди не на двигатель (под капот) смотрят, но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться (хотя повторюсь мало кто из пользователей знает что под капотом).
Чтобы продать автомобиль его нужно сделать. Если вы можете делать супер автомобили, но только 10 шт. в год, никакого лидерства вам не увидеть, даже если это супер автомобиль. Как пример печальный опыт DeLorean. Если бы денег в теслу не вложили, не было бы достаточного количество «зарядок», не было бы завода про производству нужного количества батарей.
Немножко запутался. Понятно, что должна быть хотя бы теоретическая возможность производства продукта за ту стоимость, которая будет меньше чем преимущества, которые этот продукт дает. Если это есть, деньги найдутся рано или поздно. Зарядки и заводы это уже вторично.
Я не очень досконально изучал, как тесла удалось сделать автомобиль с пробегом в 400км на одной зарядке и с OPEX'ами в 120к (CAPEX'ы при таком громадном рынке и текущей стоимости денег не так важны) или около того. Но когда это стало осязаемым, дальше успех Тесла на мой взгляд был вопросом времени (но нет, я в них не вложился в свое время, так что это рассуждения в стиле «как моя жена после»).
Ну и работающий бизнес в определенной степени пока «внутренний» (в смысле indoor), сейчас главный вопрос как его (и можно ли) масштабировать «внешне» (outdoor) и это тоже своего рода Proof-of-Concept. Хотя конечно иметь при этом стабильный cash flow (даже с запасом), возможность для обкатки идей и т.п. безусловно приятный бонус, и позволяет не сильно переживать по поводу взлетит или не взлетит.
Воот. И бывают такие ошибки, которые не так уж просто обнаружить, которые проявляются только при определенных обстоятельствах, и которые вполне проходят в прод-среду. Для них и придумали тесты, которые должны запускаться при любых изменениях исходного кода.
Да но эти ошибки как раз и возникают из-за состояний, то есть всяких race condition или сложных алгоритмов / сценариев. На чистых функциях и ограниченном числе операторов таких ошибок ГОРАЗДО меньше.
Я уже несколько раз ответил — нет.
Нет
Ну ок, боюсь это утверждение строго математически я вам вряд ли докажу, поэтому давайте на этом и остановимся.
С автотестами носятся не только в 1С, а и в Java, C#, PHP, С++, где вполне себе есть полиморфизм.
Так они тоже всего немного декларативнее 1С (хотя даже это уже очень важно). Поэтому естественно тоже носятся.
Вам же в ответе на этот комментарий все объяснили.
Ну там строго говоря, там такой же черно-белый комментарий, как и мы с вами спорим. Но давайте тогда последний вопрос: вы согласны, что если для задачи затраты на поддержание тестов > вероятности возникновения ошибки умноженной на ущерб от ее возникновения, то тесты лучше не поддерживать и наоборот?
Тесла делает автомобили которые имеют все функции доступные другим автомобилям, плюс свою фишки. Человек при покупке теслы ничего не теряет, а только приобретает. Ваше решение пока такими свойствами не балует.
Что значит ничего не теряет? Там тоже курица — яйцо было, когда например количество заправок измерялось десятками, против миллиона ДВС'ых, тоже самое касается сервисов / продаж и всего остального. Не говоря уже о том, что вы салон Тесла видели? Минимализм в чистом виде. Да и с надежностью по слухам там ерунда была (двери не закрывались). Но у них была главная вещь, фундаментально другая машина, с фундаментально другими характеристиками (например скорость разгона, шум, управляемость экологичность). Этого как правило достаточно, все остальное вопрос времени.
Предвосхищая ответ, что не все сразу делается, скажу что тесла смогла делать и продавать такие автомобили не благодаря тому что они такие хорошие и в неё поверили. В неё до сих пор просто вкладывают огромные деньги.
Вы причину со следствием путаете. Они смогли продавать такие автомобили, потому как сделали принципиально другой автомобиль, все остальное вторично (точнее следует из этого). Сделали бы они очередной ДВС никакие бы огромные деньги им не помогли. У Apple кстати тоже в свое время ресурсов было гораздо меньше чем у Nokia ЕМНИП. Да и Tesla начала относительно крупные инвестиции начала привлекать через семь лет и это в США (мекке инноваций и стартапов).
Ну и никто не спорит, что в какой то момент действительно практически всегда нужно привлекать ресурсы, но фаза Proof-of-concept и другие также очень важны, так как в это время ты максимально мобилен / пластичен и не «страдаешь» от кризиса роста.
Четвертьвековая история — это всё-таки не только недостаток, но и мощное конкурентное преимущество. Это огромная пользовательская база, причём бизнес-пользователей, которые не особо любят менять знакомый им софт на незнакомый. Это огромное количество готовых отраслевых решений, которые можно просто взять и использовать. Это налаженная сеть сбыта и поддержки, оперативное отслеживание изменений в законодательствах стран, и соответственно регулярный выход обновлений локализованных конфигураций и т.д.
Для бизнеса 1С — это безусловно преимущества. Для развития — это скорее ограничение. Вспомните Kodak, Nokia, Ford (не знаю кто тогда был лидер на рынке лошадей :) ), автогигантов да и вообще любую инновацию на рынке. Там все тоже самое было, понятно что и сети заправок, продаж, сервиса (ремонтов) везде первоначально были на несколько порядков лучше у текущих игроков. Но в этом и фокус, что если ты фундаментально отстаешь, вопрос времени когда ты проиграешь. Пусть не через год, и не через 10 или 20 лет, но проиграешь. Вон сейчас автогиганты пытаются гнаться за Tesla, понятно что они не умрут совсем, но догонят вряд ли. Собственно в том числе поэтому, сейчас Tesla оценивается как все остальные автопроизводители вместе взятые.
Я вас уверяю, в Microsoft в проекте с исходниками Excel есть куча тестов, которые тестируют формулы в excel'е.
Не спорю. А много ли людей в Excel тестируют что Excel правильно рассчитал формулу?
Я написал это в том же комментарии. Он может скопировать эту строку из определения поля totalQuantity и не поменять плюс на минус, он может для подсчета количества временно заменить минус на плюс и забыть поменять обратно, он может случайно выделить минус и заменить его другим символом, например если работает на ноутбуке с включенным тачпадом.
Ну такие ошибки обычно просматриваются при коммите (именно случайные изменения которые не планируется делать).
Плюс есть еще важный нюанс, чем проще ошибка, тем быстрее она обнаруживается в результате flow'а разработки (если такая ошибка попадает в мастер, она очень быстро попадает в непрод среду и ее сразу обнаруживают).
Да, тесты низкоуровневых императивных компонентов менее критичны, если логика декларативна, и это совершенно не отменяет необходимость тестирования этой логики.
Не совсем понял эту мысль. Вы можете все же на простой вопрос ответить: вы согласны с тем, что чем декларативнее парадигма, тем меньше вероятность ошибки и тем меньше нужны тесты?
Тесты менее критичны, если у вас есть развитая система типов с зависимыми типами, там проверки внутри зависимых типов заменяют проверки в тестах. То есть например если у вас можно задать тип ActiveClient, который является Client, у которого is_deleted == 0, и использовать его в аргументах функций. Но тут причина не в декларативности, а именно в типизации. У вас можно так сделать?
На самом деле компилятор (а точнее оптимизатор, а еще точнее оптимизатор булевой логики условий) в lsFusion очень многое тестирует сам, в том числе например противоречивость условий. Но суть не в этом. Вы согласны с тем что например та же «чистота функций» (и отсутствие состояния), существенно важнее с точки зрения декларативности, а значит потенциальных ошибок, а значит и тестов? И что важность тестов количественный показатель, который нужно соизмерять со стоимостью их поддержки, и ущербами и вероятностью предполагаемых ошибок?
Я говорю не про 1С, а про тестирование.
Я просто пример привел, и то почему в том же 1С так носятся (и действительно нужно носится) с этими автотестами.
В контексте доработки типовой конфигурации тесты имеют смысл для вас. Вряд ли вы написали типовое решение 2 года назад и ничего в нем не меняете и не планируете. Я говорил про то, наличие тестов в типовом решении не означает, что надо заново писать тесты для каждого заказчика, который им пользуется, и просить за это в 2 раза больше денег.
Ок, а если конкретное решение удается тестировать именно flow'ом разработки (как я писал тут), а тому кто дорабатывает это решение, как мы выяснили, автотесты совсем не нужны, тогда что?
ru.lsfusion.org/solutions (хотя тут надо понимать, что некоторые решения «не наши», и мы сюда постепенно новые добавляем / будем добавлять)
Еще WMS в разработке, скоро выйдет. Про MyCompany (предполагается будет основой для многих решений) можно почитать тут: habr.com/ru/company/lsfusion/blog/541526
Ну и custom made'а много (всякие хитрые CRM для IT-бизнеса и BPM'ы для фондов), но это я так понимаю к вашему вопросу имеет мало отношения.
Вес нашего ядра — 3Мб, количество строк — в 3 раза больше чем у вас (если выкинуть xml форм)
Ух ты даже интересно как вы считали у нас количество строк (реально интересно). Но выкинуть xml форм это сильно. Тогда и в lsFusion надо выкинуть все кроме действий (то что в {} обернуто). Потому как в 1С те же формы в xml по сути задаются, а в lsFusion в синтаксисе языка. И тогда у вас разница в 30 раз получится.
Вы упорно игнорируете то, что я говорю. Зачем вы это делаете?
Еще раз, независимо от того, где там можно допустить ошибку и что там надо тестировать, кроме этого тестировать надо и конечный высокоуровневый результат. Тот самый, который считает с = a+b. Именно про эти тесты вам говорят, а не про тесты деталей сложной и запутанной реализации. Почему вы постоянно разговор на них переводите?
Потому что тесты не самоцель. Не, если так, то да можно и формулы в excel'е тестировать, но цель тестов увеличение надежности и если в каком-то случае на практике это не происходит, то и тесты в этом случае не нужны.
Вы не согласны, что при внесении изменений кто-то может случайно написать currentBalance = receivedQuantity (+) shippedQuantity или некорректно поменять реализацию receivedQuantity?
Что значит случайно написать? Тесты они против вредителей или против ошибок? Если человек заменяет — на + то значит так и надо (если он конечно не саботажем занимется). Собственно тесты нужны когда например вы пишете сложные сценарии инкрементальности и не учли какую-то ветку. То есть они нужны для борьбы со сложностью, а не с простотой.
Кстати, откуда вдруг взялось отсутствие полиморфизма и тонны if-ов? В C#, Java, PHP, да даже C++ есть полиморфизм.
Подождите, мы вообще о чем разговариваем? Я говорю, что чем выше декларативность, тем менее тесты критичны и наоборот. Полиморфизм одна из фишек, которая повышает декларативность, не более. Использование же только чистых функций например повышает декларативность гораздо больше. А в 1С декларативность на самом минимальном уровне и я понимаю почему тот же Melex так носится с этими автотестами. Без них дорабатывать условное УТ было бы совсем мазохизмом.
Ну не захотел и не захотел. Вы же говорите, что изменять код типовой для таких требований не надо. Соответственно, и тесты этого кода не должны измениться. На новый код можно отдельный тест написать.
Требования бывают разные, для одних надо, для других нет. Если типовые изменять не надо, то тесты для того кто дорабатывают не имеют смысла, а если надо то они вредят.
Т.е. есть кейс, где надо рассчитать сумму товара, навпример, и программист полез в общий модуль и там что то поменял, и документ работает отлично. Но при этом — другой документ стал рассчитывать не правильно.
Опять-таки все очень сильно зависит от уровня декларативности — эффектов последействий, состояний, модульности (а точнее декомпозиции), полиморфизма и т.п.
У меня был в свое время опыт работы вот именно с таким аля 1С кодом, тонной спагетти кода без типизации, полиморфизма, ранних проверок на уровне IDE / старта (динамическим исполнением), тоннами if'ов и да единственный способ это хоть как-то поддерживать это автотесты. Но автотесты это борьба с симптомами, а не болезнью. Серьезно, если бы вы хоть раз пописали бы на чем то хоть близко настолько высокодекларативном и с таким количеством возможностей как lsFusion у вас бы таких вопросов не возникало.
Melex, вот честно, я даже в вашей аргументации про веб запутался, то он плохо работает потому что не нужен, то он медленно работает потому как элементов гораздо больше (хотя при этом утверждаете что интерфейсы текущих решений на lsFusion перегружены и в 1С элементов гораздо меньше, что в свою очередь лучше).
Просто по общению я вижу, что вы даже не пытались разобраться в lsFusion. И это полностью ваше право. Но смущает, что вы также при этом уверенно пытаетесь сравнивать lsFusion с 1С, при этом явно намекая, что например я плохо разбираюсь в 1С. Хотя поверьте я на то чтобы разобраться с 1С потратил гораздо больше времени чем вы чтобы разобраться с lsFusion (при этом многие тут еще утверждают что у 1С низкий порог входа и разобраться с 1С проще простого).
Но никто в реале работать в браузере не будет
Кстати у нас реально много клиентов в браузере работает. У некоторых даже под 100 процентов.
Это раз, два — сравнивайте производительность тогда с 1с 8.1, у вас с ней интерфейсы одинаковые, но там вы явно проиграете, причем всухую.
Вы что-то явно путаете. По производительности 1С 8.1 проиграет вчистую, так как lsFusion поддерживает все фишки 8.3 из коробки (динамические списки с видимыми окнами, разделение на сервер и клиент с минимизацией общения и максимальной асинхронностью). Зайдите в демку MyCompany и откройте документы на 100к строк или другие формы типа подбора где номенклатуры тоже под 100к. 8.1 там бы уже лег давно. Да и веба там нет непонятно что вообще поэтому сравнивать.
Я не вижу у вас опыта крупных внедрений, где из 1с тянут все соки, отсюда и статьи ваши выглядят очень популистскими.
У нас очень большой опыт внедрений на десятках проектов большинство из которых с 500-1к одновременных пользователей, таблицами под 10 млрдов записей (причем например с онлайн приемом реализации из касс и онлайн расписыванию по партиям), с очень высокой глубиной автоматизации (где чуть ли не каждый поход в туалет автоматизирован и делается по 5 задач в день с ежедневным обновлением), в едином интегрированном контуре (с десятками тысяч связанных событий и сложными формами с кучей агрегированных данных как у брокеров) и т.д. и т.п. Не верите, могу онлайн презентацию провести, если вам интересно.
вы ничего не расчитываете на лету, типо размещения элементов, их подгонки, рассчет их положений
Вот это на мой взгляд самое зло из зол и за это я бы руки отрывал (и частично поэтому веб в 1С так тормозит). Мы наоборот старались делать layout'инг, который на css ложится и рендерится браузером. Благо HTML5 поддерживает достаточно много возможностей. Это как минимум позволяет веб-клиента использовать на мобильных устройствах.
и увидите, что в 1С можно работать, а у вас — нельзя
Если оно так у меня на мощном компе лагает, страшно представить как оно на мобилке работает.
дело тут не в мобильной или нет, а в том, сколько вы ресурсов тратите на все эти рассчеты. И когда вы начнете поддерживать тоже самое — врядли у вас будет сильно быстрее.
Мы то как раз почти все на сервере считаем. На клиенте что-то считать на мой взгляд это глупость в абстолютном большинстве случаев.
При равном количестве элементов и наполнения — вы проиграете даже в скорости открытия форм
Не понял, откройте любую форму в MyCompany или ERP там куда больше элементов и наполнения (вы же сами жаловались, что они перегружены), и там не только первичные данные как в 1С, а и кучу агрегированных данных выводится.
Покажите тогда плиз статью, где вы накидываете на оракл, сап и т.д., мне уже аж стало интересно
Вы тут на вентелятор кидаете, вот чем. Вы еще далеко не доросли до 1С как платформы, без обид. Вы бы наоборот, с обществом общались, спрашивали, и слушали, а не кидали статьи в виде, что все кругом ..., а вы Д'Артаньяны.
«Если бы я спросил что людям нужно, они бы сказали, что им нужна более быстрая лошадь» (с) Генри форд.
Я не понял где статьи, что все кругом… Я писал конкретные общеизвестные вещи / проблемы. Вы же понимаете, что явную типизацию, полиморфизм, прозрачные ограничения и материализации (а точнее материализованные представление), событийно-ориентированность, реактивность, непротиворечивость и нетекущесть абстракций, everything as a code, инъекции в язык (аля LINQ или Dynamics), использование нормальных IDE и т.п. не я придумал. Это все выстрадано многолетним опытом и стало стандартом во всем мире. А то что 1С все это игнорирует (и как вы говорите никого не спрашивает и не слушает) и остается в 80-х это собственно их проблемы.
Если есть такое — значит архитектура не продумана верно. ничего не должно вырезаться в виде середины строки запроса.
Очень странный тезис. Допустим у вас есть модуль Продаж, там форма клиентов, где показывается их список и какие-то еще поля. И допустим есть модуль Расчеты с клиентами, который расширяет эту форму клиентов добавляя туда задолженность. Соотвественно в Расчетах идет строка
EXTEND FORM clients
PROPERTIES (cl) debt;
где debt расчитывается сложными правилами из разных таблиц регистров. Соответственно если у клиента подключается модуль расчетов, то в запросе читающих список клиентов должно быть в том числе чтение этой задолженности (с соответствующими JOIN'ами подзапросами и т.п.). Если нет, то не должно быть (так как таблиц для расчетов вообще не будет в базе). Соответственно так как lsFusion сама собирает / компилирует / оптимизирует запросы эта проблема решается прозрачно для разработчика. Как такие вещи вы делаете? Или просто «не держите таким образом»?
Вы серъезно? Это проблема решается тупо одной функцией на каждый регистр, где адо добавить движения, или перехват текущих — если надо изменить. Хотя мы этого и не жалуем.
Все равно не понял, как вы решаете проблему сильной связности (без того же полиморфизма например). То есть модуль A у которого есть одна логика расчета, скажем в lsFusion WHEN CHANGED f(a) DO g(a) < — h(a); и в модуле B есть другая логика расчета WHEN CHANGED g(a) DO x(a) < — t(a). lsFusion сама посмотрит какие модули подключены, возьмет все события посмотрит что они используют, изменяют и выстраивает их в правильном порядке. А у вас как? Обработка проведения одна? Тогда вам в ней придется обращаться и к А, и к B и тогда не понятно как отключить модуль (ведь тогда IDE / сервер будут ругаться что функция расчета в A или B не найдена). А если много, то кто и как их в правильном порядке выстраивает?
А что тут понимать? Есть документ, внутри него светит регистр сведений, отменяете проведение — снимается активность строк, проводите — строки обновляются. Идет рассчет МД5 строки, если строка не изменилась, то проводки, даже при проведении не должны меняться. Блокировки — это элементы головняка, но решаются установкой блокировки на объект лока в таблице регистра сведений
Это вы все руками сами делаете? Тогда я понимаю зачем вам столько тестов надо.
Так что в жестком энтерпрайзе — нет места парадигмам, есть инструмент и вы его крутите. Например, когда в базе сотни миллиов цен — никто не будет в своем уме хранить историю — всю историю гонят в эластик.
Не понял к чему вы это. Нет места парадигмам очень странное утверждение. Парадигмы есть всегда, просто для некоторых задач подходят одни под другие другие. И причем тут эластик я не совсем понял (в задаче про объемы ничего сказано не было). Хотя на самом деле мы работаем с базами где есть таблицы с десятками миллиардов записей (причем принимаемых онлайн) и если они просто лежат, то никому не мешают (но в BI естественно инкрементально выгружаются и большая часть обращений к этим данным идет оттуда).
Следи за белым кроликом — все что вы привели в пример — додумайте до конца. Кнопка не справа внизу, или слева, кнопка там, где стоит курсор после предыдущего действия в ожидании нового. На хабре я пишу комент — у меня кнопка отправить — перед глазами. У вас — я переключаюсь на список документов слева вверху, у меня кнопка создать (т.е. следующее логическое действие) — справа внизу…
Что значит переключаюсь «на список документов слева вверху»? И почему вдруг следующее логическое действие — создать, почему не найти документ в списке, после чего его удалить / отредактировать и логично что эти кнопки тогда должны быть снизу, а не сверху. Ну и тоже самое с кнопкой ОК, она справа внизу, потому что вы ввели данные сверху-вниз, слева-направо и логично что ОК должно быть справа внизу и в 95% интерфейсов она именно там.
А потому что идеалогия бизнеса такая — справоник — это информация, которая не меняется, документ — это отражение бизнес процесса.
Да, только эти абстракции сильно текут. Скажем партия это что? С одной стороны справочник, так как на него ссылаются другие документы, а с другой стороны это может быть строка документа прихода (скажем в некоторых решениях на sFusion Batch абстрактный класс и InvoiceDetail его наследует). Или в WMS например есть атомарные операции «сборки одной позиции» это должно быть отдельным документом? Или строкой документа? Но тогда она в парадигму проведения / распроведения вообще не ложится. Со статусами тоже весело получается. И таких утечек сотни.
для отражения бизнес процесса — создайте/используйте этот класс, мы в нем все предусмотрели. И назовем этот класс — документ. Вот и все — вы стали 1С :)
Нет, 1С это более узкая песочница. Там справочники и документы куда более ограниченные и конкретные абстракции (на которые они пытаются натянуть потом все что можно, и BPM и WMS). lsFusion гораздо гибче в этом плане.
Мы внедряем 1С после сапа и после оракла, или рядом с ними, и когда мы говорим бизнесу — что ребята, если мы уйдем, вы найдете программиста, который вам разрулит всю систему по винтикам за пару дней. И мы не врем. А в случае когда даже в 1с умудряются быдлокодить — то что уж говорить про вашу систему :)
Вы не врете, но явно лукавите. Очень многие 1С программисты сейчас боятся того же УТ (и тем более ERP), потому как это тонны реального спагетти кода, без типизации, ранних проверок в IDE / на компиляции / старте, на куче if'ов, с запросами в строках склеиваемых в запутанных стеках вызовов. lsFusion просто на порядок декларативнее (а значит модульнее, надежнее и т.п.)
Ничего, это проходит, мы тоже такими были, и было прикольно :)
Что проходит? У меня опыт в этом бизнесе уже лет 20. И благодаря lsFusion мы например за последние 5 лет стали лидером на рынке крупного ритейла Беларуси убрав и 1С и других игроков с рынка. Именно благодаря тому что мы можем делать очень сложные решения, изменять их прямо на лету, внедрять бесшовно и в общем это все благодаря именно платформе. Сейчас соответственно двигаемся на другие рынки.
Наша команда занимается тем, что разарбтывает системы на базе 1С под другие рынки, и уже есть внедрения и куча опыта с очень крупными компаниями. И вам там никто ничего не будет говорит, откроют, посмотрят, не понравится — пойдут дальше. Ну и если нет своего представительства на тех рынках — тоже очень сложно.
Именно. Поэтому фидбек на русскоязычных рынках очень важен.
Русскоязычный хоть и токсичен, а мечтает на запад, и если ваше решение им даст возможсность туда свалить, то будут учить :)
Тут согласен, и кстати это скорее всего именно ключевой момент в борьбе с местными решениями. То есть «убийца 1С» ИМХО в текущей парадигме может придти только с запада. Даже если он на несколько порядков лучше.
Вы так критичны в своих словах, будьте немного аккуратнее — у нас тоже система полностью модульная, и сделана она на базе 1С. И от модульности есть сложности с интерфейсами, но они вполне решаемые, просто не надо на них забивать.
А как вы решаете проблемы модульности вот какого плана. В lsFusion выключаешь модуль, один показатель исчезает и он автоматически выпиливается из всех запросов (ну то есть, например, если JOIN нужен для другого показателя он остается, если нет выпиливается). Тоже самое вопрос с flow'ом, в lsFusion все состоит из набора небольших событий, из которых платформа сама собирает один большой flow. А как вы процедуры проведения разрезаете? И сколько у вас модулей в итоге получается? Скажем в том же MyCompany ЕМНИП под 530 модулей и достаточно разреженное дерево, я кидал выше скрин, из которого можно собрать любое поддерево).
Регистром сведений по регистратору и регламентные проводки в многопоточном режиме по куче регистров. Используется в очень крупных внедрениях. Где количество строк в одном документе — влегкую превышает 100 000 строк.
Все равно если честно не понял. Регистр сведений это же по сути просто таблица. То есть вы просто в обход базовой парадигмы документа просто в таблицу записываете? А что тогда с распроведением / проведением, удалением документа? Блокировками?
Про остальное чуть позже напишу, мне реально интересно.
Нет. То, что у вас написано в примере с currentBalance, ничем особенным не отличается от императивных языков, и ошибки там можно допустить точно те же.
currentBalance обычно материализуется и в императивных языках и обновляется руками (то есть например при проведении строится дельта, отнимаются старые значений, добавляются новым и так далее). Если вычисление сложное, то сложность его алгоритма инкрементальности растет экспоненциально (тут можно подробнее почитать). И там действительно очень много где можно допустить ошибку (и это все надо тестировать). В lsFusion например такой проблемы нет.
а вдруг хобана поменялся и расчет премии грузчикам, и рабочий график сторожа, потому что они тем или иным образом зависят от количества товаров, чего мы никак не ожидали и не планировали менять.
Это если у вас код императивен по уши, с эффектами последействий, состояниями, без полиморфизма (то есть тоннами if'ов) и т.п. На высокоуровневом языке у вас вероятность таких хобана на несколько порядков меньше.
Зачем тогда переделывать тесты, которые эту логику тестируют? Тесты надо будет написать только на новые вычисления.
Так старые же будут падать. То есть захотел заказчик считать показатель как не в типовой и все у вас вечный красный светофор, если вы не поправить этот тест из типовой.
Я не говорю что вероятности ошибок нет, а что она существенно меньше. Собственно это основной кейс функциональщины (не той что про лямбды, а той что про чистоту функций).
Нет. Вы изменили логику, у вас упали тесты в том месте, которое вы вообще не предполагали менять, вы поняли, что изменили неправильно. Это ни разу не monkey job.
Я знаю что такое тестирование. Я к тому что в высоко-декларативных логиках большинство изменений результатов выхода by-design и соответственно требуют изменения тестов. То есть грубо говоря заказчик говорит надо изменить расчет остатка, ок, мы его меняем, соответственно надо и все тесты переделывать. И таких изменений 95%. Строго говоря тесты то в основном для рефакторинга нужны, а когда у вас очень высокодекларативный код потребность в нем значительно снижается.
Простите, а зачем списывать с каждого заказчика в 2 раза больше за тесты на типовую конфигурацию или модуль, которые вы пишете один раз и распространяете вместе с кодом?
Я сейчас не про типовую. Да и опять таки большинство изменений заказчика в типовую, это изменение именно логики ее работы, а значит и тестов которые эту логику тестируют. Получается значительная двойная (а то и тройная) работа с не до конца понятной выгодой. Рефакторить то типовую вы не будете, инкрементальные вычисления в lsFusion из коробки.
Мир не черно-белый. Вы же согласны, что чем декларативнее логика, чем меньше там эффектов последействия, состояний и другой «нечистоты», тем значительно меньше вероятность ошибок и как следствие тестирование в таких случаях становится «тестированием ради тестирования» (то есть действительно основным кейсом в таком случае будет, изменил логику — сразу перегенерировал тесты под эту новую логику, а это будет являться конкретным monkey job). Возможно в каких-то алгоритмически-сложных вычислениях (но при этом с точным результатом !) тесты действительно могут играть важную роль, но на практике таких вычислений в бизнес-приложениях очень малый процент.
В любом случае, я думаю мы конечно еще будем добавлять возможности тестирования из коробки (в самом верхнем комментарии я писал как уже сейчас это можно делать), но пока все же не очевиден выигрыш именно при использовании настолько высокодекларативной технологии как lsFusion (во всяком случае если взять наш опыт работы с крупными проектами). То что тесты в императивных средах (особенно для ручной инкрементальности) нужны обязательно, тут вопросов нет от слова вообще.
У заказчика как правило нет компетенций в этой области, чтобы принимать обоснованные решения.
Ну если бы заказчику можно было сказать у вас нет компетенций и автоматически списать с него в 2 раза больше за то же тестирование, то вопросов нет. Но к сожалению в реальном мире это не так, и ему приходится объяснять риски и затраты, после чего он сам принимает решение. И видя что с настолько высокодекларативной платформой никакие ошибок на пару миллионов не случаются, платить за лишнюю работу отказывается. Ну а мы не сильно настаиваем (в конечном итоге заказчик то доволен, что у него доработки идут с космической скоростью и так дешево).
То есть с теслой тоже самое было. Где вы ее заправлять будете, где чинить, вы же за город выедете и встанете, она сырая и все такое. Но как обычно инноваторы, early adopter'ы и пошло поехало. Но конечно они это на самой благодатной почве делали — в Калифорнии. В Омске им бы конечно посложнее было :)
Это проблема всех корпораций. По факту все инновации идут за их пределами, так как корпорации слишком инертные. Да и им проще потом купить выскочек, чем самим делать (хотя понятно, что с гуглом, фейсбуком, теслой это например не прокатило, а скажем с инстаграммом или ютюбом прокатило).
Так и в тесле люди не на двигатель (под капот) смотрят, но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться (хотя повторюсь мало кто из пользователей знает что под капотом).
Немножко запутался. Понятно, что должна быть хотя бы теоретическая возможность производства продукта за ту стоимость, которая будет меньше чем преимущества, которые этот продукт дает. Если это есть, деньги найдутся рано или поздно. Зарядки и заводы это уже вторично.
Я не очень досконально изучал, как тесла удалось сделать автомобиль с пробегом в 400км на одной зарядке и с OPEX'ами в 120к (CAPEX'ы при таком громадном рынке и текущей стоимости денег не так важны) или около того. Но когда это стало осязаемым, дальше успех Тесла на мой взгляд был вопросом времени (но нет, я в них не вложился в свое время, так что это рассуждения в стиле «как моя жена после»).
Ну и работающий бизнес в определенной степени пока «внутренний» (в смысле indoor), сейчас главный вопрос как его (и можно ли) масштабировать «внешне» (outdoor) и это тоже своего рода Proof-of-Concept. Хотя конечно иметь при этом стабильный cash flow (даже с запасом), возможность для обкатки идей и т.п. безусловно приятный бонус, и позволяет не сильно переживать по поводу взлетит или не взлетит.
Да но эти ошибки как раз и возникают из-за состояний, то есть всяких race condition или сложных алгоритмов / сценариев. На чистых функциях и ограниченном числе операторов таких ошибок ГОРАЗДО меньше.
Ну ок, боюсь это утверждение строго математически я вам вряд ли докажу, поэтому давайте на этом и остановимся.
Так они тоже всего немного декларативнее 1С (хотя даже это уже очень важно). Поэтому естественно тоже носятся.
Ну там строго говоря, там такой же черно-белый комментарий, как и мы с вами спорим. Но давайте тогда последний вопрос: вы согласны, что если для задачи затраты на поддержание тестов > вероятности возникновения ошибки умноженной на ущерб от ее возникновения, то тесты лучше не поддерживать и наоборот?
Что значит ничего не теряет? Там тоже курица — яйцо было, когда например количество заправок измерялось десятками, против миллиона ДВС'ых, тоже самое касается сервисов / продаж и всего остального. Не говоря уже о том, что вы салон Тесла видели? Минимализм в чистом виде. Да и с надежностью по слухам там ерунда была (двери не закрывались). Но у них была главная вещь, фундаментально другая машина, с фундаментально другими характеристиками (например скорость разгона, шум, управляемость экологичность). Этого как правило достаточно, все остальное вопрос времени.
Вы причину со следствием путаете. Они смогли продавать такие автомобили, потому как сделали принципиально другой автомобиль, все остальное вторично (точнее следует из этого). Сделали бы они очередной ДВС никакие бы огромные деньги им не помогли. У Apple кстати тоже в свое время ресурсов было гораздо меньше чем у Nokia ЕМНИП. Да и Tesla начала относительно крупные инвестиции начала привлекать через семь лет и это в США (мекке инноваций и стартапов).
Ну и никто не спорит, что в какой то момент действительно практически всегда нужно привлекать ресурсы, но фаза Proof-of-concept и другие также очень важны, так как в это время ты максимально мобилен / пластичен и не «страдаешь» от кризиса роста.
Для бизнеса 1С — это безусловно преимущества. Для развития — это скорее ограничение. Вспомните Kodak, Nokia, Ford (не знаю кто тогда был лидер на рынке лошадей :) ), автогигантов да и вообще любую инновацию на рынке. Там все тоже самое было, понятно что и сети заправок, продаж, сервиса (ремонтов) везде первоначально были на несколько порядков лучше у текущих игроков. Но в этом и фокус, что если ты фундаментально отстаешь, вопрос времени когда ты проиграешь. Пусть не через год, и не через 10 или 20 лет, но проиграешь. Вон сейчас автогиганты пытаются гнаться за Tesla, понятно что они не умрут совсем, но догонят вряд ли. Собственно в том числе поэтому, сейчас Tesla оценивается как все остальные автопроизводители вместе взятые.
Не спорю. А много ли людей в Excel тестируют что Excel правильно рассчитал формулу?
Ну такие ошибки обычно просматриваются при коммите (именно случайные изменения которые не планируется делать).
Плюс есть еще важный нюанс, чем проще ошибка, тем быстрее она обнаруживается в результате flow'а разработки (если такая ошибка попадает в мастер, она очень быстро попадает в непрод среду и ее сразу обнаруживают).
Не совсем понял эту мысль. Вы можете все же на простой вопрос ответить: вы согласны с тем, что чем декларативнее парадигма, тем меньше вероятность ошибки и тем меньше нужны тесты?
На самом деле компилятор (а точнее оптимизатор, а еще точнее оптимизатор булевой логики условий) в lsFusion очень многое тестирует сам, в том числе например противоречивость условий. Но суть не в этом. Вы согласны с тем что например та же «чистота функций» (и отсутствие состояния), существенно важнее с точки зрения декларативности, а значит потенциальных ошибок, а значит и тестов? И что важность тестов количественный показатель, который нужно соизмерять со стоимостью их поддержки, и ущербами и вероятностью предполагаемых ошибок?
Я просто пример привел, и то почему в том же 1С так носятся (и действительно нужно носится) с этими автотестами.
Ок, а если конкретное решение удается тестировать именно flow'ом разработки (как я писал тут), а тому кто дорабатывает это решение, как мы выяснили, автотесты совсем не нужны, тогда что?
Еще WMS в разработке, скоро выйдет. Про MyCompany (предполагается будет основой для многих решений) можно почитать тут:
habr.com/ru/company/lsfusion/blog/541526
Ну и custom made'а много (всякие хитрые CRM для IT-бизнеса и BPM'ы для фондов), но это я так понимаю к вашему вопросу имеет мало отношения.
Ух ты даже интересно как вы считали у нас количество строк (реально интересно). Но выкинуть xml форм это сильно. Тогда и в lsFusion надо выкинуть все кроме действий (то что в {} обернуто). Потому как в 1С те же формы в xml по сути задаются, а в lsFusion в синтаксисе языка. И тогда у вас разница в 30 раз получится.
Потому что тесты не самоцель. Не, если так, то да можно и формулы в excel'е тестировать, но цель тестов увеличение надежности и если в каком-то случае на практике это не происходит, то и тесты в этом случае не нужны.
Что значит случайно написать? Тесты они против вредителей или против ошибок? Если человек заменяет — на + то значит так и надо (если он конечно не саботажем занимется). Собственно тесты нужны когда например вы пишете сложные сценарии инкрементальности и не учли какую-то ветку. То есть они нужны для борьбы со сложностью, а не с простотой.
Подождите, мы вообще о чем разговариваем? Я говорю, что чем выше декларативность, тем менее тесты критичны и наоборот. Полиморфизм одна из фишек, которая повышает декларативность, не более. Использование же только чистых функций например повышает декларативность гораздо больше. А в 1С декларативность на самом минимальном уровне и я понимаю почему тот же Melex так носится с этими автотестами. Без них дорабатывать условное УТ было бы совсем мазохизмом.
Требования бывают разные, для одних надо, для других нет. Если типовые изменять не надо, то тесты для того кто дорабатывают не имеют смысла, а если надо то они вредят.
Опять-таки все очень сильно зависит от уровня декларативности — эффектов последействий, состояний, модульности (а точнее декомпозиции), полиморфизма и т.п.
У меня был в свое время опыт работы вот именно с таким аля 1С кодом, тонной спагетти кода без типизации, полиморфизма, ранних проверок на уровне IDE / старта (динамическим исполнением), тоннами if'ов и да единственный способ это хоть как-то поддерживать это автотесты. Но автотесты это борьба с симптомами, а не болезнью. Серьезно, если бы вы хоть раз пописали бы на чем то хоть близко настолько высокодекларативном и с таким количеством возможностей как lsFusion у вас бы таких вопросов не возникало.
Просто по общению я вижу, что вы даже не пытались разобраться в lsFusion. И это полностью ваше право. Но смущает, что вы также при этом уверенно пытаетесь сравнивать lsFusion с 1С, при этом явно намекая, что например я плохо разбираюсь в 1С. Хотя поверьте я на то чтобы разобраться с 1С потратил гораздо больше времени чем вы чтобы разобраться с lsFusion (при этом многие тут еще утверждают что у 1С низкий порог входа и разобраться с 1С проще простого).
Кстати у нас реально много клиентов в браузере работает. У некоторых даже под 100 процентов.
Вы что-то явно путаете. По производительности 1С 8.1 проиграет вчистую, так как lsFusion поддерживает все фишки 8.3 из коробки (динамические списки с видимыми окнами, разделение на сервер и клиент с минимизацией общения и максимальной асинхронностью). Зайдите в демку MyCompany и откройте документы на 100к строк или другие формы типа подбора где номенклатуры тоже под 100к. 8.1 там бы уже лег давно. Да и веба там нет непонятно что вообще поэтому сравнивать.
У нас очень большой опыт внедрений на десятках проектов большинство из которых с 500-1к одновременных пользователей, таблицами под 10 млрдов записей (причем например с онлайн приемом реализации из касс и онлайн расписыванию по партиям), с очень высокой глубиной автоматизации (где чуть ли не каждый поход в туалет автоматизирован и делается по 5 задач в день с ежедневным обновлением), в едином интегрированном контуре (с десятками тысяч связанных событий и сложными формами с кучей агрегированных данных как у брокеров) и т.д. и т.п. Не верите, могу онлайн презентацию провести, если вам интересно.
Вот это на мой взгляд самое зло из зол и за это я бы руки отрывал (и частично поэтому веб в 1С так тормозит). Мы наоборот старались делать layout'инг, который на css ложится и рендерится браузером. Благо HTML5 поддерживает достаточно много возможностей. Это как минимум позволяет веб-клиента использовать на мобильных устройствах.
Если оно так у меня на мощном компе лагает, страшно представить как оно на мобилке работает.
Мы то как раз почти все на сервере считаем. На клиенте что-то считать на мой взгляд это глупость в абстолютном большинстве случаев.
Не понял, откройте любую форму в MyCompany или ERP там куда больше элементов и наполнения (вы же сами жаловались, что они перегружены), и там не только первичные данные как в 1С, а и кучу агрегированных данных выводится.
Вот.
«Если бы я спросил что людям нужно, они бы сказали, что им нужна более быстрая лошадь» (с) Генри форд.
Я не понял где статьи, что все кругом… Я писал конкретные общеизвестные вещи / проблемы. Вы же понимаете, что явную типизацию, полиморфизм, прозрачные ограничения и материализации (а точнее материализованные представление), событийно-ориентированность, реактивность, непротиворечивость и нетекущесть абстракций, everything as a code, инъекции в язык (аля LINQ или Dynamics), использование нормальных IDE и т.п. не я придумал. Это все выстрадано многолетним опытом и стало стандартом во всем мире. А то что 1С все это игнорирует (и как вы говорите никого не спрашивает и не слушает) и остается в 80-х это собственно их проблемы.
Очень странный тезис. Допустим у вас есть модуль Продаж, там форма клиентов, где показывается их список и какие-то еще поля. И допустим есть модуль Расчеты с клиентами, который расширяет эту форму клиентов добавляя туда задолженность. Соотвественно в Расчетах идет строка
где debt расчитывается сложными правилами из разных таблиц регистров. Соответственно если у клиента подключается модуль расчетов, то в запросе читающих список клиентов должно быть в том числе чтение этой задолженности (с соответствующими JOIN'ами подзапросами и т.п.). Если нет, то не должно быть (так как таблиц для расчетов вообще не будет в базе). Соответственно так как lsFusion сама собирает / компилирует / оптимизирует запросы эта проблема решается прозрачно для разработчика. Как такие вещи вы делаете? Или просто «не держите таким образом»?
Все равно не понял, как вы решаете проблему сильной связности (без того же полиморфизма например). То есть модуль A у которого есть одна логика расчета, скажем в lsFusion WHEN CHANGED f(a) DO g(a) < — h(a); и в модуле B есть другая логика расчета WHEN CHANGED g(a) DO x(a) < — t(a). lsFusion сама посмотрит какие модули подключены, возьмет все события посмотрит что они используют, изменяют и выстраивает их в правильном порядке. А у вас как? Обработка проведения одна? Тогда вам в ней придется обращаться и к А, и к B и тогда не понятно как отключить модуль (ведь тогда IDE / сервер будут ругаться что функция расчета в A или B не найдена). А если много, то кто и как их в правильном порядке выстраивает?
Это вы все руками сами делаете? Тогда я понимаю зачем вам столько тестов надо.
Не понял к чему вы это. Нет места парадигмам очень странное утверждение. Парадигмы есть всегда, просто для некоторых задач подходят одни под другие другие. И причем тут эластик я не совсем понял (в задаче про объемы ничего сказано не было). Хотя на самом деле мы работаем с базами где есть таблицы с десятками миллиардов записей (причем принимаемых онлайн) и если они просто лежат, то никому не мешают (но в BI естественно инкрементально выгружаются и большая часть обращений к этим данным идет оттуда).
Что значит переключаюсь «на список документов слева вверху»? И почему вдруг следующее логическое действие — создать, почему не найти документ в списке, после чего его удалить / отредактировать и логично что эти кнопки тогда должны быть снизу, а не сверху. Ну и тоже самое с кнопкой ОК, она справа внизу, потому что вы ввели данные сверху-вниз, слева-направо и логично что ОК должно быть справа внизу и в 95% интерфейсов она именно там.
Да, только эти абстракции сильно текут. Скажем партия это что? С одной стороны справочник, так как на него ссылаются другие документы, а с другой стороны это может быть строка документа прихода (скажем в некоторых решениях на sFusion Batch абстрактный класс и InvoiceDetail его наследует). Или в WMS например есть атомарные операции «сборки одной позиции» это должно быть отдельным документом? Или строкой документа? Но тогда она в парадигму проведения / распроведения вообще не ложится. Со статусами тоже весело получается. И таких утечек сотни.
Нет, 1С это более узкая песочница. Там справочники и документы куда более ограниченные и конкретные абстракции (на которые они пытаются натянуть потом все что можно, и BPM и WMS). lsFusion гораздо гибче в этом плане.
Вы не врете, но явно лукавите. Очень многие 1С программисты сейчас боятся того же УТ (и тем более ERP), потому как это тонны реального спагетти кода, без типизации, ранних проверок в IDE / на компиляции / старте, на куче if'ов, с запросами в строках склеиваемых в запутанных стеках вызовов. lsFusion просто на порядок декларативнее (а значит модульнее, надежнее и т.п.)
Что проходит? У меня опыт в этом бизнесе уже лет 20. И благодаря lsFusion мы например за последние 5 лет стали лидером на рынке крупного ритейла Беларуси убрав и 1С и других игроков с рынка. Именно благодаря тому что мы можем делать очень сложные решения, изменять их прямо на лету, внедрять бесшовно и в общем это все благодаря именно платформе. Сейчас соответственно двигаемся на другие рынки.
Именно. Поэтому фидбек на русскоязычных рынках очень важен.
Тут согласен, и кстати это скорее всего именно ключевой момент в борьбе с местными решениями. То есть «убийца 1С» ИМХО в текущей парадигме может придти только с запада. Даже если он на несколько порядков лучше.
А как вы решаете проблемы модульности вот какого плана. В lsFusion выключаешь модуль, один показатель исчезает и он автоматически выпиливается из всех запросов (ну то есть, например, если JOIN нужен для другого показателя он остается, если нет выпиливается). Тоже самое вопрос с flow'ом, в lsFusion все состоит из набора небольших событий, из которых платформа сама собирает один большой flow. А как вы процедуры проведения разрезаете? И сколько у вас модулей в итоге получается? Скажем в том же MyCompany ЕМНИП под 530 модулей и достаточно разреженное дерево, я кидал выше скрин, из которого можно собрать любое поддерево).
Все равно если честно не понял. Регистр сведений это же по сути просто таблица. То есть вы просто в обход базовой парадигмы документа просто в таблицу записываете? А что тогда с распроведением / проведением, удалением документа? Блокировками?
Про остальное чуть позже напишу, мне реально интересно.
currentBalance обычно материализуется и в императивных языках и обновляется руками (то есть например при проведении строится дельта, отнимаются старые значений, добавляются новым и так далее). Если вычисление сложное, то сложность его алгоритма инкрементальности растет экспоненциально (тут можно подробнее почитать). И там действительно очень много где можно допустить ошибку (и это все надо тестировать). В lsFusion например такой проблемы нет.
Это если у вас код императивен по уши, с эффектами последействий, состояниями, без полиморфизма (то есть тоннами if'ов) и т.п. На высокоуровневом языке у вас вероятность таких хобана на несколько порядков меньше.
Так старые же будут падать. То есть захотел заказчик считать показатель как не в типовой и все у вас вечный красный светофор, если вы не поправить этот тест из типовой.
Я не говорю что вероятности ошибок нет, а что она существенно меньше. Собственно это основной кейс функциональщины (не той что про лямбды, а той что про чистоту функций).
Я знаю что такое тестирование. Я к тому что в высоко-декларативных логиках большинство изменений результатов выхода by-design и соответственно требуют изменения тестов. То есть грубо говоря заказчик говорит надо изменить расчет остатка, ок, мы его меняем, соответственно надо и все тесты переделывать. И таких изменений 95%. Строго говоря тесты то в основном для рефакторинга нужны, а когда у вас очень высокодекларативный код потребность в нем значительно снижается.
Я сейчас не про типовую. Да и опять таки большинство изменений заказчика в типовую, это изменение именно логики ее работы, а значит и тестов которые эту логику тестируют. Получается значительная двойная (а то и тройная) работа с не до конца понятной выгодой. Рефакторить то типовую вы не будете, инкрементальные вычисления в lsFusion из коробки.
В любом случае, я думаю мы конечно еще будем добавлять возможности тестирования из коробки (в самом верхнем комментарии я писал как уже сейчас это можно делать), но пока все же не очевиден выигрыш именно при использовании настолько высокодекларативной технологии как lsFusion (во всяком случае если взять наш опыт работы с крупными проектами). То что тесты в императивных средах (особенно для ручной инкрементальности) нужны обязательно, тут вопросов нет от слова вообще.
Ну если бы заказчику можно было сказать у вас нет компетенций и автоматически списать с него в 2 раза больше за то же тестирование, то вопросов нет. Но к сожалению в реальном мире это не так, и ему приходится объяснять риски и затраты, после чего он сам принимает решение. И видя что с настолько высокодекларативной платформой никакие ошибок на пару миллионов не случаются, платить за лишнюю работу отказывается. Ну а мы не сильно настаиваем (в конечном итоге заказчик то доволен, что у него доработки идут с космической скоростью и так дешево).