Тесла делает автомобили которые имеют все функции доступные другим автомобилям, плюс свою фишки. Человек при покупке теслы ничего не теряет, а только приобретает. Ваше решение пока такими свойствами не балует.
Что значит ничего не теряет? Там тоже курица — яйцо было, когда например количество заправок измерялось десятками, против миллиона ДВС'ых, тоже самое касается сервисов / продаж и всего остального. Не говоря уже о том, что вы салон Тесла видели? Минимализм в чистом виде. Да и с надежностью по слухам там ерунда была (двери не закрывались). Но у них была главная вещь, фундаментально другая машина, с фундаментально другими характеристиками (например скорость разгона, шум, управляемость экологичность). Этого как правило достаточно, все остальное вопрос времени.
Предвосхищая ответ, что не все сразу делается, скажу что тесла смогла делать и продавать такие автомобили не благодаря тому что они такие хорошие и в неё поверили. В неё до сих пор просто вкладывают огромные деньги.
Вы причину со следствием путаете. Они смогли продавать такие автомобили, потому как сделали принципиально другой автомобиль, все остальное вторично (точнее следует из этого). Сделали бы они очередной ДВС никакие бы огромные деньги им не помогли. У 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 раза больше за то же тестирование, то вопросов нет. Но к сожалению в реальном мире это не так, и ему приходится объяснять риски и затраты, после чего он сам принимает решение. И видя что с настолько высокодекларативной платформой никакие ошибок на пару миллионов не случаются, платить за лишнюю работу отказывается. Ну а мы не сильно настаиваем (в конечном итоге заказчик то доволен, что у него доработки идут с космической скоростью и так дешево).
Повторюсь — не с теми людьми вы общаетесь значит. Найдите серьезных людей, которые реально могут осветить эту тему, и которых не смогут просто так удалить. Если та статья была написана точно в таком же стиле — то я понимаю, почему ее удалили.
Да нет, там был человек с рейтингом, со статьями на Инфостарте, и статья была вообще не про 1С и уж точно не с критикой. Было что-то вроде lsFusion глазами 1С-разработчика, скорее наоборот ругательная на lsFusion, что некоторые вещи по другому и непонятно. Но ее все равно удалили. Поэтому не совсем понятно зачем двигаться на сайт конкурента, если в любой момент Инфостарт может тупо все забанить и запретить вообще упоминать там lsFusion.
Но будьте готовы, что этих людей — надо будет убеждать, и это те люди, которые понимают проблемы 1С, и ее приимущества, и с ними такой вброс не выйдет. Если надо помощь в поиске таких людей — напишите в личку, я поспрашиваю у некоторых, может кто и согласится.
Большое спасибо, я думаю мы в свое время воспользуемся вашим предложением. Но естественно, как вы наверное понимаете, русскоязычный сегмент не самая приоритетная цель. Согласитесь странно делать технологию, сложность реализации и инновационность подходов которой превышает скажем современные SQL-сервера, чтобы воевать с ней на очень маленьком да и еще весьма консервативном и консолидированном рынке (мы в свое время делали market research и чем-то похожая ситуация есть только в Бразилии). Русскоязычный сегмент хорош в качестве отличной проверки идей, без публичного выхода на мировой рынок (так как release early это хорошо, но только если ты собираешься fail fast, потому как иначе большинство запомнит тебя по первом впечатлению). А русскоязычный сегмент как уже говорилось консервативен и весьма токсичен (в хорошем смысле) и может указать тебе на твои недостатки, когда на западе тебе просто улыбнутся, но промолчат. Понятно что другие рынки могут отличаться (и скорее всего отличаются) от русскоязычного, но на рынке информационных систем очевидного окна возможностей нет, это уже давно brownfield, поэтому и сильно спешить тоже смысла особого нет. Поэтому если у вас есть знакомые, которые могли бы помочь в продвижении на англоязычный / мировой рынок (например с опытом medium/reddit, естественно после того как мы дообработаем весь фидбек и по сайту и по платформе и по остальному) мы бы были даже больше благодарны (я например знаю alexlash вроде этим занимается).
У той же 1с — все значительно лучше, посмотрите в ту же сторону УНФ последней. Ваша же модель напоминает Оракл, САП и голые SQL таблицы
Смотря о каких решениях речь, и опять таки спорный вопрос насколько отсутствие / наличие лишней информации это хорошо или плохо. Все что вы говорите это не от хорошей жизни, многие пользователи хотят видеть больше информации, даже если она не очень красиво или эргономично расположена. Да можно раскидать по вкладкам как это делает 1С, но это технические моменты. Плюс надо понимать, что lsFusion в отличии от остальных сильно модульна, обычно подключается только часть модулей и соответственно интерфейсы автоматически «разгружаются».
Что, кстати, в 1С сделать очень просто, и делается, но редко, в силу кучи причин.
Интересно как? Кто-то предлагал через подчиненные документы, но не понятно как это все потом сливать / изменять. И опять-таки, как мы спорили выше, оптимистичные блокировки во всех областях победили пессимистичные (и в SQL-серверах и в системе контроля версий и в электронных таблицах). Не вижу причин почему они не победят в бизнес-приложениях, так как это также удобно.
Ввод по строке — ужасен, вы заставляете открывать таблицу, прогружать ее и делать в ней поиск — зачем? Я знаю все свои склады, или клиентов, я хочу в поле ввести кусок текста и подставить, мне не надо формы открывать.
Тут согласен и это уже начали делать. Хотя мне с отдельным окном, если честно даже больше нравится (но может просто привык).
У вас таб гуляет по всему окну, зачем? Мне надо идти последовательно, я не хочу три кнопки нажимать на каждое действие.
Не совсем понял, можете пояснить немного.
Зачем справа внизу кнопки ОК и ЗАКРЫТЬ? Какова их функция в списках документов?
В списках документов ОК нужна и показывается, когда прямо на форме можно что-то изменять. Соответственно это сохранить и закрыть.
Почему кнопка добавить справа внизу — горячая зона — левый верхний квадрат экрана, у меня рука устала, когда я пытался пару документов сделать.
Философский вопрос. Дело в том что в большинстве UI, кнопки ОК и закрыть в правом нижнем углу. Скажем в Windows (например Печать), в Excel, в IDEA. Да даже тут на хабре кнопки отправить и предпросмотр снизу а не сверху (пусть и слева). То есть это дань традициям. Хотя да, я заметил что во многих бизнес-приложениях они начали мигрировать налево вверх, может и мы туда их мигрируем.
У вас нет контраста элементов, вот та одна — две основные кнопки, которые мне надо нажать для подтверждения и не искать их среди прочего серого фона.
Тут согласен, но надо понимать, что lsFusion делался изначально более абстрактным чем 1С и поэтому кноки ОК, Сохранить и Закрыть внутри ничем не отличаются от других добавленных разработчиком. Другое дело, что их действительно наверное стоило бы по умолчанию как-то контрастировать (но это всегда может сделать разработчик как это сделано в MyCompany).
При чем тут никто не смог? Вы просто взяли интерфейс для SQL таблиц, и попытались назвать его юзер френдли, или оправдаться тем что это ЕРП. Не ребят, так это не работает :)
Вот честно не понимаю, что мы имеете ввиду под «интерфейс для SQL таблиц». Мы как раз сделали максимально абстрактный интерфейс, который просто отображает множество объектов с различными их свойствами (естественно предполагая что все эти элементы могут быть связаны друг с другом). Это во многом 1С сделал узкую песочницу из «справочник-документ-отчет» и пытается любую логику подогнать под нее, и убедить всех что так и надо. Что же история рассудит, они как раз двигаются на мировой рынок, посмотрим как у них это получится.
Так и не понял вы предлагаете тестировать вычисления получается? То есть то что платформа правильно считае? Ну вот давайте собственно возьмем простой пример (чисто для демо): ru-documentation.lsfusion.org/pages/viewpage.action?pageId=2228636
Что конкретно тут предполагается тестировать? Что currentBalance считается правильно, так он декларативно описан (то есть это его определение). Или нужно посчитать на калькуляторе и вбить тест на проверку? Ну так это все равно что в Excel формулы проверять.
Еще раз я полностью согласен с тем что императивные вещи важно и очень нужно тестировать. Но чем декларативнее логика, чем меньше нужны тесты.
Ну и такой момент. Даже если бы тесты и можно делать в каких-то случаях, как думаете что выберет заказчик увеличение стоимости доработки в 2 раза или уменьшение надежности на 20% при условии hot downgrade'а и потенциального простоя не revenue-критичной части на пару минут (то что требования к revenue-критичной части выше с этим никто не спорит).
Не, я отлично понимаю, о чем вы спрашиваете. И честно говоря платформе сейчас на мой взгляд действительно не хватает покрытие тестами, но тут вот какая вещь. Когда платформа разрабатывалась совсем не было понятно, что в итоге получится, (в этом фокус всех инновационно революционных вещей). Соответственно наличие автотестов на раннем этапе скорее тормозило бы развитие платформы, так как за радикальными изменениями приходилось бы переделывать все тесты (так как сильно менялся бы результат), а даже без тестов такой рефакторинг был очень сложным (и тесты бы в таком случае скорее мешали). А когда архитектура стала более mature и стабильной тесты было делать уже поздновато (так как их важно делать на момент решения проблемы, но в этот момент совсем не понятно решение окончательное или нет). Плюс еще одна важная проблема — опять таки результат тестирования нечеткий, то есть основные тесты в основном нужны на оптимизатор / компилятор запросов, а тут опять-таки непонятны критерии (план не сравнишь, время не четкий параметр и т.п.). То есть в конечном итоге надежность можно было бы улучшить процентов на 20, а стоимость разработки в раза 3. Еще раз, я знаю что такое тестирование, и сам считаю, что во многих случаях оно очень важно, и мы постоянно думали / думаем как его прикрутить, чтобы в сумме (!) получить выигрыш, но пока не можем придумать.
Поэтому сейчас основной принцип тестирования для платформы такой: а) строго вертикальная архитектура без костылей (то есть жесткий code review, имхо в любом случае это самое эффективное, уделывающее все остальные, тестирование, которое снижает количество ошибок на порядки), б) специфический flow разработки — сначала идет в мастер, на котором работают большое количество разработчиков lsFusion, затем внутренняя альфа, которая идет на все демостенды, заказчикам не в production'е, затем есть пул заказчиков, у которых идут постоянные доработки по agile и с которыми есть соответствующие договоренности, которым подмешиваются новые версии (причем идет от небольших с простыми логиками, к большим со сложными), все версии накатываются в hot standby с откатом в пару минут (и с учетом постоянных изменений логики надежность поставок обновлений падает не больше чем на 10-20 процентов), после этого бета и накатывание большему числу заказчиков (вплоть до 30 из разных областей), потом final релиз, ну и hot fix'ы с автоматическими релизами (на самом деле все сборки, поставки заказчикам, релизы автоматизированы по самое не могу, вот часть инфраструктуры, тут ее исходники). Опять таки строго вертикальная чистая архитектура обеспечивает «полное покрытие» (когда у вас в архитектуре пирамидка и куча разных логик, то все узлы задействуются сами собой).
Что касается решений, то тут вот какой момент. Надо понимать что тот же lsFusion ERP это скорее конструктор из которого собираются первоначальные готовые решения, которые потом начинают сильно адаптироваться под конкретного заказчика и развиваться вместе с ним (по сути, если сейчас взять пяток крупных решений для клиентов даже из одной области, все они будут очень разными, вплоть до неузнаваемости). В этом смысле у нас бизнес-модель именно проектные решения (а не коробки) и ближе скажем к банковской ИТ-сфере, чем к классическим 1С-франчайзерам. Хорошо это или плохо сложный вопрос — для заказчика плюсы я писал тут, для подрядчика плюс в том, что он получает recurring revenue. То есть такой win-win. В любом случае доработка таких решений идет в agile и continious delivery. И теоретически я понимаю, что тут нужны тесты, но в платформе где императивность практически отсутствует (а точнее ее максимум 10%) реально не понятно что тестировать. По факту только что-то вроде «регрессивного» тестирование имеет смысл, да и то оно по сути будет тестировать платформу. Так как если кто-то изменил какое-то вычисление (например расчет какого-то показателя), по сути нужно опять таки менять сам тест.
Просто насколько я видел тестируют в основном императивщину (и чаще всего именно инкрементальность). То есть грубо говоря добавил документ проверил, что остаток пересчитался правильно, изменил строку документа проверил что остаток пересчитался правильно и т.п. А в lsFusion это все платформа делает сама, то есть реально не понятно, что тестировать.
Что значит ничего не теряет? Там тоже курица — яйцо было, когда например количество заправок измерялось десятками, против миллиона ДВС'ых, тоже самое касается сервисов / продаж и всего остального. Не говоря уже о том, что вы салон Тесла видели? Минимализм в чистом виде. Да и с надежностью по слухам там ерунда была (двери не закрывались). Но у них была главная вещь, фундаментально другая машина, с фундаментально другими характеристиками (например скорость разгона, шум, управляемость экологичность). Этого как правило достаточно, все остальное вопрос времени.
Вы причину со следствием путаете. Они смогли продавать такие автомобили, потому как сделали принципиально другой автомобиль, все остальное вторично (точнее следует из этого). Сделали бы они очередной ДВС никакие бы огромные деньги им не помогли. У 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 раза больше за то же тестирование, то вопросов нет. Но к сожалению в реальном мире это не так, и ему приходится объяснять риски и затраты, после чего он сам принимает решение. И видя что с настолько высокодекларативной платформой никакие ошибок на пару миллионов не случаются, платить за лишнюю работу отказывается. Ну а мы не сильно настаиваем (в конечном итоге заказчик то доволен, что у него доработки идут с космической скоростью и так дешево).
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=55935068
Документацию, как я понимаю вы тут нашли:
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=51216539
Есть еще места, например тут:
habr.com/ru/company/lsfusion/blog/460887/#fromext
Но там информация обрывками. Но, если что не понятно, заходите в slack, там могут на конкретные вопросы ответить.
Да нет, там был человек с рейтингом, со статьями на Инфостарте, и статья была вообще не про 1С и уж точно не с критикой. Было что-то вроде lsFusion глазами 1С-разработчика, скорее наоборот ругательная на lsFusion, что некоторые вещи по другому и непонятно. Но ее все равно удалили. Поэтому не совсем понятно зачем двигаться на сайт конкурента, если в любой момент Инфостарт может тупо все забанить и запретить вообще упоминать там lsFusion.
Большое спасибо, я думаю мы в свое время воспользуемся вашим предложением. Но естественно, как вы наверное понимаете, русскоязычный сегмент не самая приоритетная цель. Согласитесь странно делать технологию, сложность реализации и инновационность подходов которой превышает скажем современные SQL-сервера, чтобы воевать с ней на очень маленьком да и еще весьма консервативном и консолидированном рынке (мы в свое время делали market research и чем-то похожая ситуация есть только в Бразилии). Русскоязычный сегмент хорош в качестве отличной проверки идей, без публичного выхода на мировой рынок (так как release early это хорошо, но только если ты собираешься fail fast, потому как иначе большинство запомнит тебя по первом впечатлению). А русскоязычный сегмент как уже говорилось консервативен и весьма токсичен (в хорошем смысле) и может указать тебе на твои недостатки, когда на западе тебе просто улыбнутся, но промолчат. Понятно что другие рынки могут отличаться (и скорее всего отличаются) от русскоязычного, но на рынке информационных систем очевидного окна возможностей нет, это уже давно brownfield, поэтому и сильно спешить тоже смысла особого нет. Поэтому если у вас есть знакомые, которые могли бы помочь в продвижении на англоязычный / мировой рынок (например с опытом medium/reddit, естественно после того как мы дообработаем весь фидбек и по сайту и по платформе и по остальному) мы бы были даже больше благодарны (я например знаю alexlash вроде этим занимается).
Смотря о каких решениях речь, и опять таки спорный вопрос насколько отсутствие / наличие лишней информации это хорошо или плохо. Все что вы говорите это не от хорошей жизни, многие пользователи хотят видеть больше информации, даже если она не очень красиво или эргономично расположена. Да можно раскидать по вкладкам как это делает 1С, но это технические моменты. Плюс надо понимать, что lsFusion в отличии от остальных сильно модульна, обычно подключается только часть модулей и соответственно интерфейсы автоматически «разгружаются».
Интересно как? Кто-то предлагал через подчиненные документы, но не понятно как это все потом сливать / изменять. И опять-таки, как мы спорили выше, оптимистичные блокировки во всех областях победили пессимистичные (и в SQL-серверах и в системе контроля версий и в электронных таблицах). Не вижу причин почему они не победят в бизнес-приложениях, так как это также удобно.
Тут согласен и это уже начали делать. Хотя мне с отдельным окном, если честно даже больше нравится (но может просто привык).
Не совсем понял, можете пояснить немного.
В списках документов ОК нужна и показывается, когда прямо на форме можно что-то изменять. Соответственно это сохранить и закрыть.
Философский вопрос. Дело в том что в большинстве UI, кнопки ОК и закрыть в правом нижнем углу. Скажем в Windows (например Печать), в Excel, в IDEA. Да даже тут на хабре кнопки отправить и предпросмотр снизу а не сверху (пусть и слева). То есть это дань традициям. Хотя да, я заметил что во многих бизнес-приложениях они начали мигрировать налево вверх, может и мы туда их мигрируем.
Тут согласен, но надо понимать, что lsFusion делался изначально более абстрактным чем 1С и поэтому кноки ОК, Сохранить и Закрыть внутри ничем не отличаются от других добавленных разработчиком. Другое дело, что их действительно наверное стоило бы по умолчанию как-то контрастировать (но это всегда может сделать разработчик как это сделано в MyCompany).
Вот честно не понимаю, что мы имеете ввиду под «интерфейс для SQL таблиц». Мы как раз сделали максимально абстрактный интерфейс, который просто отображает множество объектов с различными их свойствами (естественно предполагая что все эти элементы могут быть связаны друг с другом). Это во многом 1С сделал узкую песочницу из «справочник-документ-отчет» и пытается любую логику подогнать под нее, и убедить всех что так и надо. Что же история рассудит, они как раз двигаются на мировой рынок, посмотрим как у них это получится.
ru-documentation.lsfusion.org/pages/viewpage.action?pageId=2228636
Что конкретно тут предполагается тестировать? Что currentBalance считается правильно, так он декларативно описан (то есть это его определение). Или нужно посчитать на калькуляторе и вбить тест на проверку? Ну так это все равно что в Excel формулы проверять.
Еще раз я полностью согласен с тем что императивные вещи важно и очень нужно тестировать. Но чем декларативнее логика, чем меньше нужны тесты.
Ну и такой момент. Даже если бы тесты и можно делать в каких-то случаях, как думаете что выберет заказчик увеличение стоимости доработки в 2 раза или уменьшение надежности на 20% при условии hot downgrade'а и потенциального простоя не revenue-критичной части на пару минут (то что требования к revenue-критичной части выше с этим никто не спорит).
Поэтому сейчас основной принцип тестирования для платформы такой: а) строго вертикальная архитектура без костылей (то есть жесткий code review, имхо в любом случае это самое эффективное, уделывающее все остальные, тестирование, которое снижает количество ошибок на порядки), б) специфический flow разработки — сначала идет в мастер, на котором работают большое количество разработчиков lsFusion, затем внутренняя альфа, которая идет на все демостенды, заказчикам не в production'е, затем есть пул заказчиков, у которых идут постоянные доработки по agile и с которыми есть соответствующие договоренности, которым подмешиваются новые версии (причем идет от небольших с простыми логиками, к большим со сложными), все версии накатываются в hot standby с откатом в пару минут (и с учетом постоянных изменений логики надежность поставок обновлений падает не больше чем на 10-20 процентов), после этого бета и накатывание большему числу заказчиков (вплоть до 30 из разных областей), потом final релиз, ну и hot fix'ы с автоматическими релизами (на самом деле все сборки, поставки заказчикам, релизы автоматизированы по самое не могу, вот часть инфраструктуры, тут ее исходники). Опять таки строго вертикальная чистая архитектура обеспечивает «полное покрытие» (когда у вас в архитектуре пирамидка и куча разных логик, то все узлы задействуются сами собой).
Что касается решений, то тут вот какой момент. Надо понимать что тот же lsFusion ERP это скорее конструктор из которого собираются первоначальные готовые решения, которые потом начинают сильно адаптироваться под конкретного заказчика и развиваться вместе с ним (по сути, если сейчас взять пяток крупных решений для клиентов даже из одной области, все они будут очень разными, вплоть до неузнаваемости). В этом смысле у нас бизнес-модель именно проектные решения (а не коробки) и ближе скажем к банковской ИТ-сфере, чем к классическим 1С-франчайзерам. Хорошо это или плохо сложный вопрос — для заказчика плюсы я писал тут, для подрядчика плюс в том, что он получает recurring revenue. То есть такой win-win. В любом случае доработка таких решений идет в agile и continious delivery. И теоретически я понимаю, что тут нужны тесты, но в платформе где императивность практически отсутствует (а точнее ее максимум 10%) реально не понятно что тестировать. По факту только что-то вроде «регрессивного» тестирование имеет смысл, да и то оно по сути будет тестировать платформу. Так как если кто-то изменил какое-то вычисление (например расчет какого-то показателя), по сути нужно опять таки менять сам тест.
Просто насколько я видел тестируют в основном императивщину (и чаще всего именно инкрементальность). То есть грубо говоря добавил документ проверил, что остаток пересчитался правильно, изменил строку документа проверил что остаток пересчитался правильно и т.п. А в lsFusion это все платформа делает сама, то есть реально не понятно, что тестировать.