Я знаю что такое расширения и упоминал несколько раз в своих статьях.
Нужно понимать, что:
а) во-первых, расширения это частный случай модульности, когда у вас основное решение — один модуль, а расширение — еще один модуль зависящий от этого модуля. Поэтому в идеальной системе должна быть не только возможность добавлять свои модули, но и выключать существующие модули и / или выбирать между ними.
б) в императивных языках возможности расширений очень ограничены (тут я писал об этом). Критически важно уметь расширять запросы, иметь событийную архитектуру, полиморфизм и т.п. (вот тут я приводил примеры этой проблематики и человек мне так ничего и не ответил на них)
И если бы вы чуть больше погрузились в lsFusion, то поняли бы что в плане расширений / модульности lsFusion превосходит существующие технологии на порядок. Впрочем, естественно, никто не мешает вам «подождать на берегу», пока время подтвердит или опровергнет этот тезис :)
В этом и фокус, что по опыту в настолько высокодекларативной среде как lsFusion, такие ошибки не возникают. Проверено опытом (при том что у нас у многих клиентов по 5 доработок в день и ежедневные обновления).
Подождите, важная часть SaaS это multi-tenancy, а если есть доработки (где с multi-tenancy очень много вопрос), то это чистый PaaS и скорее ближе к хостингу. Ну и собственно весь смысл в SaaS это отсутствии тесного контакта с клиентом (в том числе, например, за счет интуитивности интерфейсов и всяческих подсказок), а доработки это как раз классическая модель рынка бизнес-приложений.
И как бы 1С не развивали технологию расширений, но когда все сделано на SQL запросах, но при этом жестко императивно в строках без оптимизатора, когда нет полиморфизма, эти расширения по определению будут очень ограниченными (собственно такая проблема с модульностью яркий тому пример). Уж точно далеко для подходов используемых в lsFusion.
А средний бизнес это какой? Вот у нас сейчас основные клиенты это компании с 4-10к сотрудников и 200-500 млнов долларов в год оборотами. И основное что мы им продаем это как раз то что я писал в этом комментарии. То есть набор модулей из которых собирается решение, но что главное непрерывную реализацию всех хотелок с космической скоростью без накапливания технического долга (собственно у нас по сути на этом рынке в этом плане непонятно кто вообще конкуренты, потому как вести столько проектов одновременно в agile практически никто не может). Сейчас у нас процентов 70 крупного ритейла Беларуси и я думаю в течении ближайших 5-10 лет мы еще больше увеличим эту долю. И все это на мой взгляд именно благодаря платформе (всем этим 30 пунктам этой статьи). Это достаточно уникальное value который мало кто на рынке может предложить.
А рынок готовых решений судя по оборотам в ЕГРЮЛ соответствующих компаний (и общению с ними) наоборот сильно сужается, так как большинство как-то уже автоматизированы и на самом деле по опыту единственный вариант им что-то внедрить, это: внедрить as is с непрерывной интеграцией, после чего превратить в to be из смеси а) того что есть у тебя, б) то что всегда хотел заказчик, но у него не было, в) оставить то что есть, что себя уже зарекомендовало. Ну а дальше непрерывный цикл доработок по agile в рамках новых идей / изменений бизнеса и т.п.
У вас почему-то две крайности получается. Либо коробка (причем без модульности у вас может быть много лишних данных и проверок, которые придется заполнять или которые просто будут убивать эргономичность), либо разработка с нуля. Хотя очевидно, что идеальное решение это крупноблочное строительство с доработкой отдельных блоков и разработкой недостающих. И модульность с возможностями рефакторинга / быстрой и простой разработки тут выходят на первый план.
Я думал мы с другими электромобилями сравниваем. Ок тогда все это плюс разгон за 4 секунды, без передач и вообще трущихся частей (то есть гораздо меньше обслуживания надо), с очень крутой безопасностью (нельзя перевернуть, двигатель в салон не уедет), бесшумность, экологичность, возможность заправлять ночью (пусть и очень долго).
Как будто другие компании не выпускали «спорные» с дизайнерской точки зрения машины.
Кстати именно такие нет. Но опять-таки я тут все вместе сравнивал.
Фейсбук делал совершенно новый продукт. Рынок соц. сетей с ним только появлялся. Кто-то думает что сейчас может появится другой фейсбук?
Я про пирамиду и финпоказатели. Но вообще уже появлялись другие фейсбуки — инстаграмм, твиттер, ютуб, тикток, вот сейчас клабхаус например.
Но в отличии от ракет, в автомобилях такой революции не свершилось.
То есть переход с бензина на электричество (и скажем зарядка автомобилей дома по ночам) — это не революция? Ну ок.
Ваши представления об онлайн сервисах устарели. Например, QuikBooks Online, Xero, 1С Fresh предлагаю возможность покупки дополнительных модулей и расширений от партнеров и заказную разработку этих модулей.
Я в курсе, но это уже тогда PaaS'ы (то есть по сути хостинг) и к классическим онлайн-сервисам имеют опосредованное отношение. И явно не то что автор того, на что я отвечал, имел ввиду.
Ну не знаю, в моем понимании коробочное решение это нажал кнопку установить, потыкал пару галочек и работай. А конструктор это набор некоторых блоков, из которых ты выбираешь часть ( часть которых опять-таки приходится изменять), часть блоков разрабатываешь (ЕМНИП даже САП утверждает, что у них пропорция где-то процентов 60-70 готовых с кастомизацией глубиной процентов 30 + 30-40 абсолютно новых). Но если доработка / добавление подвержены сильному техническому долгу (а это определяется платформой), то даже если у вас и 90 процентов готовых модулей, то в конечном итоге может быть дешевле вообще все с нуля сделать.
Если она запускается и работает как надо, значит на данный момент ошибок в ней нет, независимо от их вероятности.
Ну или вы просто не все сценарии оттестировали.
что вероятность того, что ваш код при доработках разойдется с ожидаемыми требованиями, это 10 в минус очень большой степени и поэтому тесты писать не надо.
Это с чего вы так решили? Может быть так: вероятность в течении цикла жизни ПО (скажем условные 5 лет) возникновения ошибки 5%, ущерб 10к долларов, затраты на поддержкание тестов в течении этого времени 600 долларов, соответственно в этом случае тестировать экономически неэффективно.
. А эта оценка неправильная, и от декларативности или императивности это не зависит.
Ну конечно. Как раз чем меньше у вас эффектов последействий, чем меньше у вас связанности кода, чем больше действий делается автоматически уже отлаженной платформой, тем естественно меньше вероятность получить ошибку в результате какого нибудь изменения (это собственно азы программирования) и тем меньше необходимость в автотестах.
По каким? Задумайтесь что такого сверх нового в тесле? Какую инновацию они привнесли кроме «автопилота»? В чем главное преимущество электромобиля перед бензиновым?
Ну это был по сути первый полноценный седан с возможностью проезжать 450км (а не 150), быстрой зарядки, нормальной динамики и безопасности, оригинальными (пусть и спорными) дизайнерскими решениями в духе минимализма и т.п. То есть именно законченный MVP.
Продолжатся так бесконечно не будет.
Я все тоже самое слышал и про эппл и про убер и особенно про фейсбук в свое время. И? Назовите мне хоть один реально лопнувший такой «пузырь» за последние 10 лет?
Проиграет в чем? Тойота стала хуже продаваться? Инвесторы от неё отвернулись?
Ну то что рост продаж у Теслы в разы превосходит Тойоту, и Тесла уже стоит в 2 раза дороже Тойоты и так с огромной вероятностью будет всегда.
А я и не говорю про «разработку кастомных решений». Я как раз говорю про ультрамодульные решения (где из модулей как из кубиков собирается каркас), а потом дорабатывается «as is», а потом непрерывно меняется под «to be» / новые направления / идеи. И в том насколько это возможно быстро и дешево делать, платформа играет важнейшую роль.
Ну и вы правильно заметили, что у малого и среднего бизнеса не то что нет потребности работать по такой модели, а именно что нет денег. Но это опять таки вопрос к платформе, насколько дешевой у вас получится доработка / крупноблочная разработка на ней.
Нет, как раз наоборот. Коробки потеснились (и будут дальше тесниться) онлайн-сервисами, а покупки бессрочных лицензий потеснились подписками. Но спрос на готовые решения только растёт, а спрос на кастомизацию наоборот, падает. Кастомизация — это потребность среднего и крупного бизнеса. 99% остальных заказчиков покрывают все свои потребности типовыми конфигурациями.
Теперь совсем запутался. То что ниша ИТ-решений малого (!) бизнеса постепенно замещается в основном онлайн-сервисами с этим никто не спорит. Но это не про ERP-платформы (и ни про 1С, Dynamics, ни про lsFusion) вообще. В онлайн сервисах не важны ни разработчики (так как нет кастомизации) ни франчи (так как продажи собственно идут онлайн через соотвествующие каналы). Тут важнее интуитивность полученного продукта (material design, документированность причем прямо внутри продукта, то есть всякие подсказки и т.п.), А ИТ-решение для среднего и крупного бизнеса сейчас это именно и только про кастомизацию.
Плюс важный момент- то что во всяком случае на постсоветском пространстве бизнес консолидируется (вертикально — федерально и / или регионально и горизонтально — когда сети например начинают и производством и оптовой и интернет торговлей заниматься) и соответственно все смещается в сторону среднего и крупного бизнеса. А значит спрос на готовые решения наоборот скорее падает, и это очень кстати хорошо видно, если посмотреть по ЕГРЮЛ обороты поставщиков именно коробочного софта в разных нишах.
К слову например если взять белорусский рынок, то скажем в ИТ для банковской сферы есть две компании обороты и количество сотрудников, которых превышает обороты и количество всех 1С франчайзеров вместе взятых. А эти компании только и занимаются что «кастомизацией».
Они это начали делать одновременно. Ну т.е. первые пользователи Теслы уже имели доступ и к заправкам, и к обслуживанию
Ага только по сравнению с ДВС там выбор был ультраограниченный.
Но съем сливок с продаж происходит отнюдь не от этой волны.
Ну это как бы очевидно, но не понятно какое отношение имеет к тому, о чем мы разговариваем.
Эм, нет, они попадают в прод потому что их никто не заметил, а никто их не заметил потому что логика сложная, а не потому что реализация этой логики императивная или декларативная.
Давайте так, есть два вида сложности essential и accidental. И способ реализации логики влияет именно на вторую часть сложности. То есть представьте что вы логику реализуете максимально декларативно:
sum(Invoice i) = GROUP SUM quantity(InvoiceDetail id) * price(id) IF invoice(id) = i;
И то же самое реализуете скажем на ассемблере. Где вероятность ошибки выше? А вероятность ошибки напрямую влияет на необходимость тестирования. И все сводится к следующему:
Нет, потому что вы неправильно оцениваете вероятность возникновения ошибки.
Что значит вы неправильно оцениваете? Я привел формулу в которой предполагается, что вероятность оценена правильно в принципе. Или вы предполагаете что эта вероятность 100% всегда. Ну я вас разочарую, скажем часто во многих системах в качестве идентификатора генерят UUID. Вы же в курсе что он может повторяться, но вероятность его повторения 10 в минус очень большой степени (вероятность столкновения земли с астероидом). И ничего используют в продакшн системах с ошибками на миллион.
А если вероятность не 100%, то вы по сути спорите с определением, так как любой бизнес это максимизация матожидания прибыли, и если в моем сравнение левая часть больше, то смысла в тестах нет по определению.
Я может чего-то путаю, но Приус это гибрид и по основном характеристикам не сравнится с Тесла (то есть это что-то среднее, ни рыбо ни мясо).
И собственно Тойота хороший пример, что имей ты хоть бесконечно денег, огромную долю на рынке, опыт, сервисы и все такое, если ты фундаментально отстаешь, в перспективе (пусть и глобальной) ты все равно проиграешь.
Но да многие все сваливают на хайп, не понимая, что путают причину со следствием.
Так же и с софтом. Вы вполне успешно продадите такое:
«Наша система позволяет вести партионный учёт, считает себестоимость по FIFO, LIFO, по среднему, умеет вести SKU, интегрируется с… » и так далее.
Все зависит от того, что именно считать продуктом на этом рынке. Время «коробок» ушло на постсоветском рынке (и продолжает уходить). Сейчас ИТ-решения это не более чем полуфабрикат (или конструктор), основное в них не то, что есть там изначально (это всего лишь средство, один из факторов), а как это решение можно адаптировать под конкретного заказчика, внедрить в нем все его know how, сделать это бесшовно без рисков остановки бизнеса, а главное чтобы решение постоянно изменялось вместе с бизнесом, адаптируясь под новые идеи и пути развития бизнеса. На западе рынок давно пришел к этому («САП невозможно внедрить, его можно перестать внедрять»), и на постсовестком рынке последние лет 5 тоже (собствено у всех уже как-то что-то автоматизировано, а рынок экстенсивно не растет).
Соответственно в такой парадигме двигатель это именно платформа, то есть то насколько решение будет гибким, модульным и быстро и легко дорабатываться без накопления технического долга.
С Теслой было не то же самое. Выходя на рынок, они вкинули кучу денег, решив вопросы «где заправлять» и «где чинить».
Ну тут мне кажется перепутано причина со следствием, это было одновременно (сначала люди не знали где заправлять и чинить, но все равно покупали из-за инноваций), но постепенно появилось и то и другое. То есть не то что Тесла сначала настроило миллион заправок и обучила миллион техников, а только потом смогла продавать.
Это с чего вдруг? Функционал, известность, саппорт и доступность специалистов на рынке это кузов / салон авто, бренд, СТО, заправки и наличие механиков. А двигатель это как раз платформа.
То есть с теслой тоже самое было. Где вы ее заправлять будете, где чинить, вы же за город выедете и встанете, она сырая и все такое. Но как обычно инноваторы, early adopter'ы и пошло поехало. Но конечно они это на самой благодатной почве делали — в Калифорнии. В Омске им бы конечно посложнее было :)
Проблемы-то у них возникли не из-за груза накопленного опыта, а из-за грубых управленческих ошибок.
Это проблема всех корпораций. По факту все инновации идут за их пределами, так как корпорации слишком инертные. Да и им проще потом купить выскочек, чем самим делать (хотя понятно, что с гуглом, фейсбуком, теслой это например не прокатило, а скажем с инстаграммом или ютюбом прокатило).
И смотреть они будут не на то, какая там внутри красивая объектная архитектура, и как эффективно работает внутренний ORM, а на то, насколько система соответствует текущим потребностями бизнеса «из коробки», насколько она понятна пользователям, какие риски внедрения и т.д.
Так и в тесле люди не на двигатель (под капот) смотрят, но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться (хотя повторюсь мало кто из пользователей знает что под капотом).
Чтобы продать автомобиль его нужно сделать. Если вы можете делать супер автомобили, но только 10 шт. в год, никакого лидерства вам не увидеть, даже если это супер автомобиль. Как пример печальный опыт DeLorean. Если бы денег в теслу не вложили, не было бы достаточного количество «зарядок», не было бы завода про производству нужного количества батарей.
Немножко запутался. Понятно, что должна быть хотя бы теоретическая возможность производства продукта за ту стоимость, которая будет меньше чем преимущества, которые этот продукт дает. Если это есть, деньги найдутся рано или поздно. Зарядки и заводы это уже вторично.
Я не очень досконально изучал, как тесла удалось сделать автомобиль с пробегом в 400км на одной зарядке и с OPEX'ами в 120к (CAPEX'ы при таком громадном рынке и текущей стоимости денег не так важны) или около того. Но когда это стало осязаемым, дальше успех Тесла на мой взгляд был вопросом времени (но нет, я в них не вложился в свое время, так что это рассуждения в стиле «как моя жена после»).
Ну и работающий бизнес в определенной степени пока «внутренний» (в смысле indoor), сейчас главный вопрос как его (и можно ли) масштабировать «внешне» (outdoor) и это тоже своего рода Proof-of-Concept. Хотя конечно иметь при этом стабильный cash flow (даже с запасом), возможность для обкатки идей и т.п. безусловно приятный бонус, и позволяет не сильно переживать по поводу взлетит или не взлетит.
Воот. И бывают такие ошибки, которые не так уж просто обнаружить, которые проявляются только при определенных обстоятельствах, и которые вполне проходят в прод-среду. Для них и придумали тесты, которые должны запускаться при любых изменениях исходного кода.
Да но эти ошибки как раз и возникают из-за состояний, то есть всяких race condition или сложных алгоритмов / сценариев. На чистых функциях и ограниченном числе операторов таких ошибок ГОРАЗДО меньше.
Я уже несколько раз ответил — нет.
Нет
Ну ок, боюсь это утверждение строго математически я вам вряд ли докажу, поэтому давайте на этом и остановимся.
С автотестами носятся не только в 1С, а и в Java, C#, PHP, С++, где вполне себе есть полиморфизм.
Так они тоже всего немного декларативнее 1С (хотя даже это уже очень важно). Поэтому естественно тоже носятся.
Вам же в ответе на этот комментарий все объяснили.
Ну там строго говоря, там такой же черно-белый комментарий, как и мы с вами спорим. Но давайте тогда последний вопрос: вы согласны, что если для задачи затраты на поддержание тестов > вероятности возникновения ошибки умноженной на ущерб от ее возникновения, то тесты лучше не поддерживать и наоборот?
Нужно понимать, что:
а) во-первых, расширения это частный случай модульности, когда у вас основное решение — один модуль, а расширение — еще один модуль зависящий от этого модуля. Поэтому в идеальной системе должна быть не только возможность добавлять свои модули, но и выключать существующие модули и / или выбирать между ними.
б) в императивных языках возможности расширений очень ограничены (тут я писал об этом). Критически важно уметь расширять запросы, иметь событийную архитектуру, полиморфизм и т.п. (вот тут я приводил примеры этой проблематики и человек мне так ничего и не ответил на них)
И если бы вы чуть больше погрузились в lsFusion, то поняли бы что в плане расширений / модульности lsFusion превосходит существующие технологии на порядок. Впрочем, естественно, никто не мешает вам «подождать на берегу», пока время подтвердит или опровергнет этот тезис :)
И как бы 1С не развивали технологию расширений, но когда все сделано на SQL запросах, но при этом жестко императивно в строках без оптимизатора, когда нет полиморфизма, эти расширения по определению будут очень ограниченными (собственно такая проблема с модульностью яркий тому пример). Уж точно далеко для подходов используемых в lsFusion.
А рынок готовых решений судя по оборотам в ЕГРЮЛ соответствующих компаний (и общению с ними) наоборот сильно сужается, так как большинство как-то уже автоматизированы и на самом деле по опыту единственный вариант им что-то внедрить, это: внедрить as is с непрерывной интеграцией, после чего превратить в to be из смеси а) того что есть у тебя, б) то что всегда хотел заказчик, но у него не было, в) оставить то что есть, что себя уже зарекомендовало. Ну а дальше непрерывный цикл доработок по agile в рамках новых идей / изменений бизнеса и т.п.
Я думал мы с другими электромобилями сравниваем. Ок тогда все это плюс разгон за 4 секунды, без передач и вообще трущихся частей (то есть гораздо меньше обслуживания надо), с очень крутой безопасностью (нельзя перевернуть, двигатель в салон не уедет), бесшумность, экологичность, возможность заправлять ночью (пусть и очень долго).
Кстати именно такие нет. Но опять-таки я тут все вместе сравнивал.
Я про пирамиду и финпоказатели. Но вообще уже появлялись другие фейсбуки — инстаграмм, твиттер, ютуб, тикток, вот сейчас клабхаус например.
То есть переход с бензина на электричество (и скажем зарядка автомобилей дома по ночам) — это не революция? Ну ок.
Я в курсе, но это уже тогда PaaS'ы (то есть по сути хостинг) и к классическим онлайн-сервисам имеют опосредованное отношение. И явно не то что автор того, на что я отвечал, имел ввиду.
Ну или вы просто не все сценарии оттестировали.
Это с чего вы так решили? Может быть так: вероятность в течении цикла жизни ПО (скажем условные 5 лет) возникновения ошибки 5%, ущерб 10к долларов, затраты на поддержкание тестов в течении этого времени 600 долларов, соответственно в этом случае тестировать экономически неэффективно.
Ну конечно. Как раз чем меньше у вас эффектов последействий, чем меньше у вас связанности кода, чем больше действий делается автоматически уже отлаженной платформой, тем естественно меньше вероятность получить ошибку в результате какого нибудь изменения (это собственно азы программирования) и тем меньше необходимость в автотестах.
Хотя баги у нас по определению имеют максимальный приоритет. Важно чтобы фундаментальные вещи были надежны как калашников, а рюшечки всегда вторичны.
Ну это был по сути первый полноценный седан с возможностью проезжать 450км (а не 150), быстрой зарядки, нормальной динамики и безопасности, оригинальными (пусть и спорными) дизайнерскими решениями в духе минимализма и т.п. То есть именно законченный MVP.
Я все тоже самое слышал и про эппл и про убер и особенно про фейсбук в свое время. И? Назовите мне хоть один реально лопнувший такой «пузырь» за последние 10 лет?
Ну то что рост продаж у Теслы в разы превосходит Тойоту, и Тесла уже стоит в 2 раза дороже Тойоты и так с огромной вероятностью будет всегда.
Ну и вы правильно заметили, что у малого и среднего бизнеса не то что нет потребности работать по такой модели, а именно что нет денег. Но это опять таки вопрос к платформе, насколько дешевой у вас получится доработка / крупноблочная разработка на ней.
Теперь совсем запутался. То что ниша ИТ-решений малого (!) бизнеса постепенно замещается в основном онлайн-сервисами с этим никто не спорит. Но это не про ERP-платформы (и ни про 1С, Dynamics, ни про lsFusion) вообще. В онлайн сервисах не важны ни разработчики (так как нет кастомизации) ни франчи (так как продажи собственно идут онлайн через соотвествующие каналы). Тут важнее интуитивность полученного продукта (material design, документированность причем прямо внутри продукта, то есть всякие подсказки и т.п.), А ИТ-решение для среднего и крупного бизнеса сейчас это именно и только про кастомизацию.
Плюс важный момент- то что во всяком случае на постсоветском пространстве бизнес консолидируется (вертикально — федерально и / или регионально и горизонтально — когда сети например начинают и производством и оптовой и интернет торговлей заниматься) и соответственно все смещается в сторону среднего и крупного бизнеса. А значит спрос на готовые решения наоборот скорее падает, и это очень кстати хорошо видно, если посмотреть по ЕГРЮЛ обороты поставщиков именно коробочного софта в разных нишах.
К слову например если взять белорусский рынок, то скажем в ИТ для банковской сферы есть две компании обороты и количество сотрудников, которых превышает обороты и количество всех 1С франчайзеров вместе взятых. А эти компании только и занимаются что «кастомизацией».
Ага только по сравнению с ДВС там выбор был ультраограниченный.
Ну это как бы очевидно, но не понятно какое отношение имеет к тому, о чем мы разговариваем.
Давайте так, есть два вида сложности essential и accidental. И способ реализации логики влияет именно на вторую часть сложности. То есть представьте что вы логику реализуете максимально декларативно:
sum(Invoice i) = GROUP SUM quantity(InvoiceDetail id) * price(id) IF invoice(id) = i;
И то же самое реализуете скажем на ассемблере. Где вероятность ошибки выше? А вероятность ошибки напрямую влияет на необходимость тестирования. И все сводится к следующему:
Что значит вы неправильно оцениваете? Я привел формулу в которой предполагается, что вероятность оценена правильно в принципе. Или вы предполагаете что эта вероятность 100% всегда. Ну я вас разочарую, скажем часто во многих системах в качестве идентификатора генерят UUID. Вы же в курсе что он может повторяться, но вероятность его повторения 10 в минус очень большой степени (вероятность столкновения земли с астероидом). И ничего используют в продакшн системах с ошибками на миллион.
А если вероятность не 100%, то вы по сути спорите с определением, так как любой бизнес это максимизация матожидания прибыли, и если в моем сравнение левая часть больше, то смысла в тестах нет по определению.
И собственно Тойота хороший пример, что имей ты хоть бесконечно денег, огромную долю на рынке, опыт, сервисы и все такое, если ты фундаментально отстаешь, в перспективе (пусть и глобальной) ты все равно проиграешь.
Но да многие все сваливают на хайп, не понимая, что путают причину со следствием.
Все зависит от того, что именно считать продуктом на этом рынке. Время «коробок» ушло на постсоветском рынке (и продолжает уходить). Сейчас ИТ-решения это не более чем полуфабрикат (или конструктор), основное в них не то, что есть там изначально (это всего лишь средство, один из факторов), а как это решение можно адаптировать под конкретного заказчика, внедрить в нем все его know how, сделать это бесшовно без рисков остановки бизнеса, а главное чтобы решение постоянно изменялось вместе с бизнесом, адаптируясь под новые идеи и пути развития бизнеса. На западе рынок давно пришел к этому («САП невозможно внедрить, его можно перестать внедрять»), и на постсовестком рынке последние лет 5 тоже (собствено у всех уже как-то что-то автоматизировано, а рынок экстенсивно не растет).
Соответственно в такой парадигме двигатель это именно платформа, то есть то насколько решение будет гибким, модульным и быстро и легко дорабатываться без накопления технического долга.
Ну тут мне кажется перепутано причина со следствием, это было одновременно (сначала люди не знали где заправлять и чинить, но все равно покупали из-за инноваций), но постепенно появилось и то и другое. То есть не то что Тесла сначала настроило миллион заправок и обучила миллион техников, а только потом смогла продавать.
То есть с теслой тоже самое было. Где вы ее заправлять будете, где чинить, вы же за город выедете и встанете, она сырая и все такое. Но как обычно инноваторы, early adopter'ы и пошло поехало. Но конечно они это на самой благодатной почве делали — в Калифорнии. В Омске им бы конечно посложнее было :)
Это проблема всех корпораций. По факту все инновации идут за их пределами, так как корпорации слишком инертные. Да и им проще потом купить выскочек, чем самим делать (хотя понятно, что с гуглом, фейсбуком, теслой это например не прокатило, а скажем с инстаграммом или ютюбом прокатило).
Так и в тесле люди не на двигатель (под капот) смотрят, но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться (хотя повторюсь мало кто из пользователей знает что под капотом).
Немножко запутался. Понятно, что должна быть хотя бы теоретическая возможность производства продукта за ту стоимость, которая будет меньше чем преимущества, которые этот продукт дает. Если это есть, деньги найдутся рано или поздно. Зарядки и заводы это уже вторично.
Я не очень досконально изучал, как тесла удалось сделать автомобиль с пробегом в 400км на одной зарядке и с OPEX'ами в 120к (CAPEX'ы при таком громадном рынке и текущей стоимости денег не так важны) или около того. Но когда это стало осязаемым, дальше успех Тесла на мой взгляд был вопросом времени (но нет, я в них не вложился в свое время, так что это рассуждения в стиле «как моя жена после»).
Ну и работающий бизнес в определенной степени пока «внутренний» (в смысле indoor), сейчас главный вопрос как его (и можно ли) масштабировать «внешне» (outdoor) и это тоже своего рода Proof-of-Concept. Хотя конечно иметь при этом стабильный cash flow (даже с запасом), возможность для обкатки идей и т.п. безусловно приятный бонус, и позволяет не сильно переживать по поводу взлетит или не взлетит.
Да но эти ошибки как раз и возникают из-за состояний, то есть всяких race condition или сложных алгоритмов / сценариев. На чистых функциях и ограниченном числе операторов таких ошибок ГОРАЗДО меньше.
Ну ок, боюсь это утверждение строго математически я вам вряд ли докажу, поэтому давайте на этом и остановимся.
Так они тоже всего немного декларативнее 1С (хотя даже это уже очень важно). Поэтому естественно тоже носятся.
Ну там строго говоря, там такой же черно-белый комментарий, как и мы с вами спорим. Но давайте тогда последний вопрос: вы согласны, что если для задачи затраты на поддержание тестов > вероятности возникновения ошибки умноженной на ущерб от ее возникновения, то тесты лучше не поддерживать и наоборот?