Да, после других языков могу уверенно сказать что это дико важно. Кто-то может сказать что equals и так можно было негенерить легко resharper-ом. Если у тебя небольшой проект, то это правда. Но когда у тебя в проекте сотни сущностей и тебе регулярно надо рефакторить, необходимость следить за всеми эти Equals дико утомляет. Беда equals в том что само его существование в коде требует от тебя написания тестов на equals. В команде из 5 человек кто-то обязательно забудет исправить equals, забудет исправить тест на equals, хотя можно было бы писать намного более компактный вариант класса + не писать абсолютно не нужные тесты, так как record гарантирует идентичность кодогенерации сравнения на выходе. После других языков меня и бесконечный {get; set;} бесят (да даже после того же F#) стал жутко раздражать. И после других языков вроде kotlin вообще не понимаешь, какого черта надо это все руками делать сегодня, когда за тебя все это может и должен делать компилятор.
Языки стремятся к удобству, без него язык можно считать мертвым: я писал SPA приложения на JS до того как это стало мейнстримом, до появления Angular, React, Vue, backbone, knokout под IE6 и могу сказать что без Babel писать на ТОЙ старой версии языка JS без Babel - дикий ад, мне до сих пор в кошмарах снится работа с часовыми поясами в офлайне на JS той версии). Тот же TypeScript появился как будущее развитие JS и фактически вытеснил JS в средних и больших проектах, так как JS очень медленно развивался из-за того что каждое нововведение требовало обсуждения консорциума W3C и поддержки всеми браузерами. Так что если выбирать между JS старой версии и JS с Babel - я ногами и руками за последнее. Как и в выборе между C# 2 и C# 10. До Kotlin я предпочитал писать на C# под Android. Сейчас более богатый на плюшки kotlin удобнее чем C#. А вместо Xamarin Native можно писать на KMM.
С тех пор как появился var а потом и Linq регулярно слышу от коллег как Microsoft хоронит C# такими плюшками. Уже в год появления Linq слышал кучу возмущений от коллег по поводу Linq и насколько это все ненужный мусор, а сейчас без Linq трудно представить C#.
Некоторые даже возмущались по поводу async/await - а сейчас async/await перекочевал из C# во многие языки.
И так КАЖДЫЙ год с КАЖДОЙ новой версией C# очередная волна хоронителей C# дает о себе знать.
Возьмите тот же Kotlin, в нем от рождения плюшек намного больше чем в C# и там где инертность была маленькая (мобильная разработка) Kotlin очень быстро вытеснил Java и фактически стал дефолтным языком разработки. А там где была большая инертность (корпоративная серверная разработка на Java порой обладают очень большим объемам легаса кода) как только Kotlin начал вытеснять и серверную разработку, Java начала активно тырить фичи из Kotlin и быстро развиваться, хотя до этого годами спорили надо ли вводить var или нет.
Если когда-нибудь писали на функциональных языка типа F# и другие, то поймете насколько все плохо в C# и что C# крайне плохо подходит для моделирования сложной предметной области. Тот же pattern matching не довезли нормально (безумно удобно когда компилятор сразу подсказывает что у тебя пропущены некоторые кейсы). Очень не хватает Union Type. Безумно не хватает тех же val как в kotlin-е. Те же Record-ы должны были появиться гораздо раньше, так как после других языков жутко бесило писать все время {get; set;} бесконечно количество раз. Кодогенерация должна была появиться намного раньше, так как писать раскрытый вариант {get; set; } Для каждого свойства в MVVM тоже очень раздражает (Fody спасал, но о нем знало и использовало очень мало людей). Отставание от современных языков как раз и губит C#.
А вот популярность C# как раз таки начала падать при Балмере, когда он забил на C#, .NET и C# вообще перестал развиваться и Microsoft активно рекламировал и призывал использовать тот же JS при разработке в WinRT. Даже покрытие API Winrt под .NET было меньше чем покрытие API Winrt JS-ом. И наоборот, при Наделла популярность C# снова начала расти, так как при нем активно стали развивать .net core
Как показывает практика, обычно все наоборот: 1. Язык губит как раз таки остановка развития языка (примерно как Kotlin вытеснил почти полностью Java на Android, как только появилась альтернатива Java).
2. А еще язык губит непродуманная политика Microsoft, когда на C# хоронят один за другим платформы (как писали выше - Silverlight, WinRT, UWP, WP, WebForms). Тот же Xamarin/Maui на очереди к моему большому сожалению, так как Microsoft забивает на мнение комьюнити и развивает тот же Maui с тем же подходом что и Xamarin (Я перешел с Xamarin на Flutter и оказалось что Flutter + ASP.NET Core значительно удобнее и быстрее для разработки, чем Xamarin/MAUI + ASP.NET Core).
На практике плюшки дают выбор, а не убивают язык, а с тем, что бы команда писала не в разнобой, в одинаковом стиле, писала наиболее компактный идентичный код, сегодня вполне успешно справляются инструменты вроде Resharper и Rider, которые умеют одним хоткеем преобразовать код из одного вида в другой и могут рекомендовать конкретный стиль/плюшки для использования. (и да, для больших команд в 10-20 человек правила можно настраивать и при желании можно вообще запретить использовать конкретные плюшки и не давать компилироваться и мержится с выбранными (новым или старым) стилем кода).
Можете не переживать за автора. Ведь статья (которая появилась столько времени спустя после голосования, что уже странно) всего лишь подтверждает, что технически все работало, а не то что были странные аномалии в голосах. Т.е. статья полностью нейтральная и соответствует риторике властей и Венедиктова, что техническая группа не нашла проблем, а не то, что не было аномалий с перегослованиями и т.д. и т.п., так что автору ничего не грозит :)
Если бы программированию обучали исключительно топовые эксперты нашей индустрии, то некому было бы учить программистов, так как подавляющее большинство экспертов, попросту не хотят и/или не умеют обучать людей, а если и пишут, то часто пишут для таких же экспертов как они сами. К сожалению не все могут быть Jon Skeet-ом. https://habr.com/ru/post/137317/
я тут обнаружил что в методе: getToken можно передать любую чушь и все равно получишь токен:
У меня пуштокен возвращается даже при:
val token = HmsInstanceId.getInstance(context).getToken("any value instead of appId :) ", "HCM")
в декомпилированных исходниках библиотеки можно обнаружить:
if (TextUtils.isEmpty(var0)) {
var3.setAppId(Util.getAppId(var2));
}
где var0 — appId
больше нигде ни для чего передаваемый appId не используется, так что главное что бы он не был пустым
Не могли бы подсказать, есть ли аналогичное решение в HMS ?
Кратко говоря суть задачи в следующем:
Мы из Firebase из своего аккаунта можем отправлять пуши клиентам встроившим библиотеку и им для этого не приходится сообщать нам app id/ app secret.
А если HMS не поддерживает такой способ отправки пушей то для корректной работы библиотеки нам придется просить клиентов предоставлять нам appId/app secret от их боевых приложений и хранить их у себя и отправлять пуши уже от имени этих приложений. Что уже не очень приятно как клиентам так и нам
Есть менеджеры, которые используют оценки для того что бы потом по ним предъявлять претензии к разработчикам. Такие оценки всегда вредны. Часто "эффективные менеджеры" доводят это до абсурда. Мне пришлось работать с одним руководителем который требовал точной почасовой оценки исследовательских математико-лингвистических задач. При этом не упуская возможности при каждом удобном случае унижать и высмеивать команду, сравнивая с командой фронтенд разработчиков, которые оценивали свою работу в часах и достаточно хорошо придерживались этих сроков.
На практике, в типовых задачах корпоративной разработки, декомпозиция и оценка задач чаще всего бывает крайне полезна (если использовать его без кнута). Допустим, если разработчик говорит неделя, то в процессе декомпозиции на более мелкие задачи (например 4-8 часов), часто выясняется что упускают мелкие задачи и срок выростает с недели до двух. Кроме того, при декомпозиции с тимлидом, часто выясняется, что изначально задача была неправильно понята и разработчик мог сильно усложнить логику какой-нибудь небольшой подзадачи. Т.е. тут главный профит не в том что разработчик потратит меньше времени, а в том что код будет проще, без ненужной/неиспользуемой запутанной логики.
Владельцы/руководители считают деньги и всегда хотят знать сколько денег уйдет на разработку и когда смогут запустить продукт. Плохой менеджер просто транслирует цифры наверх, и потом винит разработчиков. Грамотный менеджер или тимлид использует оценку не для того, что бы потом предъявлять претензии за эти сроки, а для того что бы встроить оценку в налаживание коммуникации и обмен опытом внутри команды и сам дает окончательную оценку руководству, в зависимости от состояния/квалификации команды и ответственность за обозначенные оценки берет на себя.
Если клепаете Hello! World пачками, то возможно инструментарий VS Code лучше, чем тяжелые инструменты корпоративной разработки. Но если пишете большие кровавые корпоративные приложения, какие аналоги NDepend, или Resharper Architecture Diagramm и других инструментов этого вида есть в мире node.js? Я без иронии, в моем опыте из-за отсутствия инструментов подобного класса приходится отказывать от node.js по мере роста сложности приложений.
Ну нельзя же так обламывать. Внимательно и долго читал введение, только приготовился прочитать о том как конкретно удалось решить проблему с использованием CQRS, приготовился увидеть как красиво все разложили по доменам вместо "Большого кома грязи", собирался увидеть как распутали сложную запутанную логику, увидеть за счет чего удалось переиспользовать фичи, и вместо всего это как то резко свелось к одному рекламному обзацу "Мы взяли CQRS и стало хорошо". :)
Не совсем. Взять те же книги. Книга выражает некую мысль, страсть автора. Книга вызывает эмоции. Тем не менее книги выпускаются огромным тиражом. И ценность от этого не падает. Ценность картин определяется оригинальностью картины, даже если отличить копию от оригинала можно только радиоуглеродным анализом. Копия, по какой то причине, выражает огромное количество эмоций пока покупатель не обнаружит что это копия. Т.е. ценность картины сугуба субъективна и эмоции вызывает, к примеру, в зависимости от того знаем ли мы что это копия или оригинал. Что же касается картины искусственного интеллекта, то это по сути такой же холст, такие же кисти конкретного автора. Здесь автором является Дмитрий, а картина — результат который автор выразил с помощью инструмента. Чем ЭТА картина отличается от тех же фотографий который делались целый день с определенным интервалом, а потом выбирались самые удачные кадры и вешались на всяких галерееях?
Самый интересный вопрос: Если вдруг нагрузка будет превышена, то сервис прекратить работу или спишутся деньги? Есть ли возможность влиять на поведение при достижении лимита?
Недостатки вроде:
"Нет параллельной разработки"
"Нет цели для команд" надуманные.
У нас обычно фронт и бек разработчик совместно садились и договаривались о моделях данных и методах, воплощая это в виде заглушек генерирующих контракт на бекенде (C#/Swagger), оттуда генерировали клиент (Angular/TypeScript) и уже потом бек и фронт разработчик парралельно наполняли клиентскую и серверную логику заменяя заглушку на код возвращающий боевые данные. По сути результат такой же как если бы писали JSON схемы вначале, но в подходе с заглушками с совместным моделированием данных и методов на каком нибудь ЯП гораздо быстрее чем ручками составлять JSON а потом строить модели от этих JSON.
Наконец то Flutter заставил команду Xamarin двигаться в правильном направлении. Если вместо сторонних поделок появится официальное решение уже хорошо. Но один только XAML сильно недостаточно. Часто редактирование XAML без редактирования ViewModel в C# бессмысленно и весь этот профит от HotReload XAML становится почти бесполезным. Небольшая польза появляется только в конце разработки когда активная фаза разработки завершена и надо подправить стили, внешний вид и все такое.
Теперь мы можем писать код на cтеке, который оптимален для решения конкретной задачи. И рационально использовать любых хороших разработчиков, которые к нам попали
К сожалению в подавляющем большинстве случаев это скорее минус нежели плюс. Не надо забывать что код надо больше поддерживать в будущем и адаптировать, нежели написать один раз и забыть о нем. Не надо забывать что разработчики не только приходят в проект но и уходят из проекта. Очень печально видеть проекты в которых в команде из 5 человек ипользуют 3-4 стека технологий на микросервисах, потому что каждый новый пришедший человек считал что стек X отстой, стек Y крут, стек Y отстой, стек Z крут и т.д.
А потом когда человек уходит из проекта (по самым разным причинам) иногда всю работу приходиться полностью переписывать с нуля, так как или разраба не могут найти на этот стек или там все очень плохо написано на самом деле: у кого то качество покрытия логов реализовано плохо, у кого то вообще реализовано с SQL инъекциями. А код ревью не сильно спасет так как надо разбираться в коде в другом стеке.
Не надо разводить зоопарк просто потому что разработчик хороший, это обходиться потом очень и очень дорого.
Попробуйте объяснить эту философию архитектору проекта на несколько миллионов строк кода. В проектах с кровавым энетрпрайзом, где задействовано куча народу разных мастей, гораздо безопаснее вообще насовсем запретить использование приватных методов (например джунам или командам внедрения), нежели разрешить если очень хочется, а потом разгребать последствия вот такой вот философии "как бы нельзя, но на самом деле можно если хочеться".
я предлагаю закруглятся со спором. Или перейти в личку. Судя по всему кроме нас двоих остальной аудитории этой статьи наше обсуждение вообще не интересно. А мы уже заспамили большую ветку, что не очень вежливо :)
Да, после других языков могу уверенно сказать что это дико важно. Кто-то может сказать что equals и так можно было негенерить легко resharper-ом. Если у тебя небольшой проект, то это правда. Но когда у тебя в проекте сотни сущностей и тебе регулярно надо рефакторить, необходимость следить за всеми эти Equals дико утомляет. Беда equals в том что само его существование в коде требует от тебя написания тестов на equals. В команде из 5 человек кто-то обязательно забудет исправить equals, забудет исправить тест на equals, хотя можно было бы писать намного более компактный вариант класса + не писать абсолютно не нужные тесты, так как record гарантирует идентичность кодогенерации сравнения на выходе.
После других языков меня и бесконечный {get; set;} бесят (да даже после того же F#) стал жутко раздражать. И после других языков вроде kotlin вообще не понимаешь, какого черта надо это все руками делать сегодня, когда за тебя все это может и должен делать компилятор.
Языки стремятся к удобству, без него язык можно считать мертвым:
я писал SPA приложения на JS до того как это стало мейнстримом, до появления Angular, React, Vue, backbone, knokout под IE6 и могу сказать что без Babel писать на ТОЙ старой версии языка JS без Babel - дикий ад, мне до сих пор в кошмарах снится работа с часовыми поясами в офлайне на JS той версии).
Тот же TypeScript появился как будущее развитие JS и фактически вытеснил JS в средних и больших проектах, так как JS очень медленно развивался из-за того что каждое нововведение требовало обсуждения консорциума W3C и поддержки всеми браузерами.
Так что если выбирать между JS старой версии и JS с Babel - я ногами и руками за последнее. Как и в выборе между C# 2 и C# 10. До Kotlin я предпочитал писать на C# под Android. Сейчас более богатый на плюшки kotlin удобнее чем C#. А вместо Xamarin Native можно писать на KMM.
С тех пор как появился var а потом и Linq регулярно слышу от коллег как Microsoft хоронит C# такими плюшками. Уже в год появления Linq слышал кучу возмущений от коллег по поводу Linq и насколько это все ненужный мусор, а сейчас без Linq трудно представить C#.
Некоторые даже возмущались по поводу async/await - а сейчас async/await перекочевал из C# во многие языки.
И так КАЖДЫЙ год с КАЖДОЙ новой версией C# очередная волна хоронителей C# дает о себе знать.
Возьмите тот же Kotlin, в нем от рождения плюшек намного больше чем в C# и там где инертность была маленькая (мобильная разработка) Kotlin очень быстро вытеснил Java и фактически стал дефолтным языком разработки. А там где была большая инертность (корпоративная серверная разработка на Java порой обладают очень большим объемам легаса кода) как только Kotlin начал вытеснять и серверную разработку, Java начала активно тырить фичи из Kotlin и быстро развиваться, хотя до этого годами спорили надо ли вводить var или нет.
Если когда-нибудь писали на функциональных языка типа F# и другие, то поймете насколько все плохо в C# и что C# крайне плохо подходит для моделирования сложной предметной области. Тот же pattern matching не довезли нормально (безумно удобно когда компилятор сразу подсказывает что у тебя пропущены некоторые кейсы). Очень не хватает Union Type. Безумно не хватает тех же val как в kotlin-е. Те же Record-ы должны были появиться гораздо раньше, так как после других языков жутко бесило писать все время {get; set;} бесконечно количество раз. Кодогенерация должна была появиться намного раньше, так как писать раскрытый вариант {get; set; } Для каждого свойства в MVVM тоже очень раздражает (Fody спасал, но о нем знало и использовало очень мало людей). Отставание от современных языков как раз и губит C#.
А вот популярность C# как раз таки начала падать при Балмере, когда он забил на C#, .NET и C# вообще перестал развиваться и Microsoft активно рекламировал и призывал использовать тот же JS при разработке в WinRT. Даже покрытие API Winrt под .NET было меньше чем покрытие API Winrt JS-ом. И наоборот, при Наделла популярность C# снова начала расти, так как при нем активно стали развивать .net core
Как показывает практика, обычно все наоборот:
1. Язык губит как раз таки остановка развития языка (примерно как Kotlin вытеснил почти полностью Java на Android, как только появилась альтернатива Java).
2. А еще язык губит непродуманная политика Microsoft, когда на C# хоронят один за другим платформы (как писали выше - Silverlight, WinRT, UWP, WP, WebForms). Тот же Xamarin/Maui на очереди к моему большому сожалению, так как Microsoft забивает на мнение комьюнити и развивает тот же Maui с тем же подходом что и Xamarin (Я перешел с Xamarin на Flutter и оказалось что Flutter + ASP.NET Core значительно удобнее и быстрее для разработки, чем Xamarin/MAUI + ASP.NET Core).
На практике плюшки дают выбор, а не убивают язык, а с тем, что бы команда писала не в разнобой, в одинаковом стиле, писала наиболее компактный идентичный код, сегодня вполне успешно справляются инструменты вроде Resharper и Rider, которые умеют одним хоткеем преобразовать код из одного вида в другой и могут рекомендовать конкретный стиль/плюшки для использования. (и да, для больших команд в 10-20 человек правила можно настраивать и при желании можно вообще запретить использовать конкретные плюшки и не давать компилироваться и мержится с выбранными (новым или старым) стилем кода).
Можете не переживать за автора. Ведь статья (которая появилась столько времени спустя после голосования, что уже странно) всего лишь подтверждает, что технически все работало, а не то что были странные аномалии в голосах. Т.е. статья полностью нейтральная и соответствует риторике властей и Венедиктова, что техническая группа не нашла проблем, а не то, что не было аномалий с перегослованиями и т.д. и т.п., так что автору ничего не грозит :)
Если бы программированию обучали исключительно топовые эксперты нашей индустрии, то некому было бы учить программистов, так как подавляющее большинство экспертов, попросту не хотят и/или не умеют обучать людей, а если и пишут, то часто пишут для таких же экспертов как они сами. К сожалению не все могут быть Jon Skeet-ом. https://habr.com/ru/post/137317/
я тут обнаружил что в методе: getToken можно передать любую чушь и все равно получишь токен:
У меня пуштокен возвращается даже при:
val token = HmsInstanceId.getInstance(context).getToken("any value instead of appId :) ", "HCM")
в декомпилированных исходниках библиотеки можно обнаружить:
if (TextUtils.isEmpty(var0)) {
var3.setAppId(Util.getAppId(var2));
}
где var0 — appId
больше нигде ни для чего передаваемый appId не используется, так что главное что бы он не был пустым
единственный способ задать appId сейчас это файл agconnect-services.json
Поэтому пока что этот способ отправки пушей недоступен:
https://firebase.google.com/docs/cloud-messaging/concept-options#receiving-messages-from-multiple-senders
Здравствуйте!
Мы сейчас адаптируем свою библиотеку для сервиса авторизации и нотификации для работы с HMS.
В связи с этим у нас возникла потребность в аналогичном функционале:
https://firebase.google.com/docs/cloud-messaging/concept-options#receiving-messages-from-multiple-senders
Не могли бы подсказать, есть ли аналогичное решение в HMS ?
Кратко говоря суть задачи в следующем:
Мы из Firebase из своего аккаунта можем отправлять пуши клиентам встроившим библиотеку и им для этого не приходится сообщать нам app id/ app secret.
А если HMS не поддерживает такой способ отправки пушей то для корректной работы библиотеки нам придется просить клиентов предоставлять нам appId/app secret от их боевых приложений и хранить их у себя и отправлять пуши уже от имени этих приложений. Что уже не очень приятно как клиентам так и нам
В статье action-ы передачи токена в UI не совпадают:
com.huawei.codelabpush.ON_NEW_TOKEN
com.huawei.push.codelab.ON_NEW_TOKEN
Есть намного более простой способ получения токена:
https://developer.huawei.com/consumer/en/doc/development/HMS-Plugin-Guides-V1/applypushtoken-0000001050136500-V1
спросоня промахнулся, вопрос адресовался автору статьи ))
Есть менеджеры, которые используют оценки для того что бы потом по ним предъявлять претензии к разработчикам. Такие оценки всегда вредны. Часто "эффективные менеджеры" доводят это до абсурда. Мне пришлось работать с одним руководителем который требовал точной почасовой оценки исследовательских математико-лингвистических задач. При этом не упуская возможности при каждом удобном случае унижать и высмеивать команду, сравнивая с командой фронтенд разработчиков, которые оценивали свою работу в часах и достаточно хорошо придерживались этих сроков.
На практике, в типовых задачах корпоративной разработки, декомпозиция и оценка задач чаще всего бывает крайне полезна (если использовать его без кнута). Допустим, если разработчик говорит неделя, то в процессе декомпозиции на более мелкие задачи (например 4-8 часов), часто выясняется что упускают мелкие задачи и срок выростает с недели до двух. Кроме того, при декомпозиции с тимлидом, часто выясняется, что изначально задача была неправильно понята и разработчик мог сильно усложнить логику какой-нибудь небольшой подзадачи. Т.е. тут главный профит не в том что разработчик потратит меньше времени, а в том что код будет проще, без ненужной/неиспользуемой запутанной логики.
Владельцы/руководители считают деньги и всегда хотят знать сколько денег уйдет на разработку и когда смогут запустить продукт. Плохой менеджер просто транслирует цифры наверх, и потом винит разработчиков. Грамотный менеджер или тимлид использует оценку не для того, что бы потом предъявлять претензии за эти сроки, а для того что бы встроить оценку в налаживание коммуникации и обмен опытом внутри команды и сам дает окончательную оценку руководству, в зависимости от состояния/квалификации команды и ответственность за обозначенные оценки берет на себя.
Если клепаете Hello! World пачками, то возможно инструментарий VS Code лучше, чем тяжелые инструменты корпоративной разработки. Но если пишете большие кровавые корпоративные приложения, какие аналоги NDepend, или Resharper Architecture Diagramm и других инструментов этого вида есть в мире node.js? Я без иронии, в моем опыте из-за отсутствия инструментов подобного класса приходится отказывать от node.js по мере роста сложности приложений.
Ну нельзя же так обламывать. Внимательно и долго читал введение, только приготовился прочитать о том как конкретно удалось решить проблему с использованием CQRS, приготовился увидеть как красиво все разложили по доменам вместо "Большого кома грязи", собирался увидеть как распутали сложную запутанную логику, увидеть за счет чего удалось переиспользовать фичи, и вместо всего это как то резко свелось к одному рекламному обзацу "Мы взяли CQRS и стало хорошо". :)
Не совсем. Взять те же книги. Книга выражает некую мысль, страсть автора. Книга вызывает эмоции. Тем не менее книги выпускаются огромным тиражом. И ценность от этого не падает. Ценность картин определяется оригинальностью картины, даже если отличить копию от оригинала можно только радиоуглеродным анализом. Копия, по какой то причине, выражает огромное количество эмоций пока покупатель не обнаружит что это копия. Т.е. ценность картины сугуба субъективна и эмоции вызывает, к примеру, в зависимости от того знаем ли мы что это копия или оригинал. Что же касается картины искусственного интеллекта, то это по сути такой же холст, такие же кисти конкретного автора. Здесь автором является Дмитрий, а картина — результат который автор выразил с помощью инструмента. Чем ЭТА картина отличается от тех же фотографий который делались целый день с определенным интервалом, а потом выбирались самые удачные кадры и вешались на всяких галерееях?
Самый интересный вопрос: Если вдруг нагрузка будет превышена, то сервис прекратить работу или спишутся деньги? Есть ли возможность влиять на поведение при достижении лимита?
Недостатки вроде:
"Нет параллельной разработки"
"Нет цели для команд" надуманные.
У нас обычно фронт и бек разработчик совместно садились и договаривались о моделях данных и методах, воплощая это в виде заглушек генерирующих контракт на бекенде (C#/Swagger), оттуда генерировали клиент (Angular/TypeScript) и уже потом бек и фронт разработчик парралельно наполняли клиентскую и серверную логику заменяя заглушку на код возвращающий боевые данные. По сути результат такой же как если бы писали JSON схемы вначале, но в подходе с заглушками с совместным моделированием данных и методов на каком нибудь ЯП гораздо быстрее чем ручками составлять JSON а потом строить модели от этих JSON.
Наконец то Flutter заставил команду Xamarin двигаться в правильном направлении. Если вместо сторонних поделок появится официальное решение уже хорошо. Но один только XAML сильно недостаточно. Часто редактирование XAML без редактирования ViewModel в C# бессмысленно и весь этот профит от HotReload XAML становится почти бесполезным. Небольшая польза появляется только в конце разработки когда активная фаза разработки завершена и надо подправить стили, внешний вид и все такое.
К сожалению в подавляющем большинстве случаев это скорее минус нежели плюс. Не надо забывать что код надо больше поддерживать в будущем и адаптировать, нежели написать один раз и забыть о нем. Не надо забывать что разработчики не только приходят в проект но и уходят из проекта. Очень печально видеть проекты в которых в команде из 5 человек ипользуют 3-4 стека технологий на микросервисах, потому что каждый новый пришедший человек считал что стек X отстой, стек Y крут, стек Y отстой, стек Z крут и т.д.
А потом когда человек уходит из проекта (по самым разным причинам) иногда всю работу приходиться полностью переписывать с нуля, так как или разраба не могут найти на этот стек или там все очень плохо написано на самом деле: у кого то качество покрытия логов реализовано плохо, у кого то вообще реализовано с SQL инъекциями. А код ревью не сильно спасет так как надо разбираться в коде в другом стеке.
Не надо разводить зоопарк просто потому что разработчик хороший, это обходиться потом очень и очень дорого.
Попробуйте объяснить эту философию архитектору проекта на несколько миллионов строк кода. В проектах с кровавым энетрпрайзом, где задействовано куча народу разных мастей, гораздо безопаснее вообще насовсем запретить использование приватных методов (например джунам или командам внедрения), нежели разрешить если очень хочется, а потом разгребать последствия вот такой вот философии "как бы нельзя, но на самом деле можно если хочеться".
Смущает нарушение коммутативности в DSL в неочевидных местах:
var order = Create.Order
.Dated(3.May(2019))
.With(Pizza.Pepperoni.CountOf(1).For(500))
.With(Pizza.Margarita.CountOf(1).For(650))
.Please();
Вернет не то же самое, что
var order = Create.Order
.With(Pizza.Pepperoni.CountOf(1).For(500))
.With(Pizza.Margarita.CountOf(1).For(650))
.Dated(3.May(2019))
.Please();
Или такое поведение было задумано изначально?
я предлагаю закруглятся со спором. Или перейти в личку. Судя по всему кроме нас двоих остальной аудитории этой статьи наше обсуждение вообще не интересно. А мы уже заспамили большую ветку, что не очень вежливо :)