Выбор стека технологий. Простыми словами о сложном выборе.
Делимся личным опытом, который может быть полезен кому-то еще.
Настала пора определиться с технологиями на которых будет разрабатываться Ваш продукт. И тут Вы либо имеете опыт и можете самостоятельно принимать участие в выборе и влиять на него, либо всецело доверяете Вашему тех директору, тех лиду или подрядчику и это право остается за ним.
Так или иначе выбор по стеку технологий и базовой архитектуры проекта надо будет сделать и от него будет зависеть как часто в будущем Ваши разработчики будут просить отрефакторить или переписать проект. Давайте разбираться что же выбрать, синяя или красная таблетка?!
Выбирайте синюю таблетку и тот стек в котором у Вашей команды больше всего опыта.
Можно конечно поддаться соблазну и выбрать красную, малоизведанную нишу, но будьте готовы к дополнительным тратам времени на исследование малознакомой технологии, решении неизвестных проблем, о которых мало где написано, а они уж поверьте будут появляться довольно часто. Хотя это может и положительно сказаться на мотивации, как известно программисты любят технологические вызовы.
В общем Вы лучше знаете свою команду и сделаете правильный выбор. А я поделюсь опытом как этот выбор проходил у нас, для нас он не был простым.
Как упоминалось выше, лучше выбирать проверенный стек технологий, если это не своеобразный технологический вызов для Вашей команды. Мы 6 лет занимаемся разработкой на C# и это не сайтики-визитки, писали софт по станциям зарядок для электромобилей, роботизированным складам и др, но не об этом речь, в этом посте не было планов чем-то меряться… хотелось для полноты картины подчеркнуть, что опыт разработки на C# у нас есть, казалось бы бери да делай. Ну мы взяли и стали делать.
Но сюрприз, сюрприз…по прошествии года разработки (а дело было в недалеком 2020) выяснилось что монолитная архитектура нам уже не особо подходит. Этот выбор был сделан для более легкого порога вхождения в проект и скорости разработки. Но т.к. стало ясно, что необходимо делать несколько независимых сервисов в одном приложении, то монолит уже не вписывается в концепт. Да и в дополнении экспертиза по Angular (клиенткий фреймворк) у нашей команды сильно ослабла после ухода лида фронтенд команды…
В общем так незаметно подкрался провал первой попытки написания аналога Jira, все наработки остались в столе. Про эту откровенно говоря неудачную попытку расскажу в следующем посте, т.к. ошибок было очень много и потянет на целое руководство «как не стоит разрабатывать приложения».
Сменив настрой на позитивный, мы переработали стек технологий в пользу микросервисной архитектуры с взаимодействием сервисов через шину RabbitMQ, C#, net core, Linq2Db в качестве ORM, бд Postgres и Fluent migrator. А клиентский фреймворк сменили с Angular на Blazor с использованием Flux и Micro Frontends. И это был отчасти технологический вызов для нас, т. к. крупных приложений дошедших до прода мы на нем не писали. На момент середины 2021г, когда мы делали этот выбор, в нашем багаже было всего 1 релизное небольшое приложение на Blazor и 1 масштабный проект с тем же стеком, но который был еще далек до релиза.
Для тех кто не в курсе Blazor — довольно молодой клиентский фреймворк от Microsoft, а как известно из истории Microsoft, они могут и забросить свою разработку, привет Silverlight и привет слёзы разработчиков Silverlight. Сейчас с Blazor чуть проще, но все равно приколов и сложностей всегда хватает как и с любой новой технологией.
Мы этот выбор делали осознанно и исключительно из того что большинство команды имело хороший опыт работы с C#.
Вот такой тернистый путь с выбором стека технологий мы, а теперь и Вы, вместе с нами прошли.
п.с. Особенно буду благодарен тем кто поделится собственным неожиданным опытом выбора стека технологий в комментариях.
…Продолжение следует…
Да уж, выбирать технологии Microsoft для веб проекта — как-то не очень, как по мне. Если десктоп приложение то ок, но право же, освоить golang или какой-нибудь PHP для разработчиков было бы проще, чем потом всё это разгребать на стадии "готово на 80%". Даже Java была бы лучше.
Денис, поведайте нам чем технологии Microsoft вас разочаровали. мы их много лет используем в коммерческой разработке, разочарований пока не наступило)
кроссплатформенностью разочаровывают, тем, что MS бросает "старые" каждые 4 года, как вы упомянули в ситуации с silverlight и сложностью с разработчиками.
Да, есть нюансы и история как у любой технологии. С появлением .net core с кроссплатформенностью стало все ок, а с появлением Blazor и wasm приложения стали возможными.
Мы стараемся следить и за новыми фреймворками и языками программирования...главное делать это на расстоянии от прода)
Основной посыл статьи в том, чтоб выбирать наиболее известный для команды стек технологий.
не слежу за .net, возможно стало за годы лучше. На импортозамещенных эльбрусах уже работает? MS не чинит препятствий для РФ компаний? В open source свой без подписания соглашений всё ещё не принимают патчи?
Так то выбор технологий понятен, вам нужно было чем-то загрузить команду, которые в это умеют, пока простаивают. А если бы от продукта плясали, то команду бы пришлось менять.
С Эльбрусами не имели дел, но если в docker контейнере, то в целом уже не так важно где запускать.
Препятствия есть и хостить у них в облаках как минимум не получится. .net - opensource, но мы не контрибьютили, не подскажу.
Второй заход на разработку после первого провала делали от продукта как раз, собственно и выбор стека основан на потребностях продукта. Самое рискованное был Blazor в данном выборе, т.к. не писали на нем крупных сервисов и это довольно молодой клиентский фреймворк. Параллельно нашему продукту зарелизили несколько коммерческих крупных проектов на Blazor и сейчас уже повеселее.
по описанию Blazor этот — вообще какой то ужас 🤣 wasm и c# вместо яваскрипта 🙀 Но кто не рискует, тот, как говорится, не пьёт шампанского. Жду продолжения истории.