📌Выбор стека технологий. Простым языком о сложном.📌
Настала пора определиться с технологиями на которых будет разрабатываться Ваш продукт.
И тут Вы либо имеете опыт и можете самостоятельно принимать участие в выборе и влиять на него, либо всецело доверяете Вашему тех директору, тех лиду или подрядчику и это право остается за ним.
Так или иначе выбор по стеку технологий и базовой архитектуры проекта надо будет сделать и от него будет зависеть как часто в будущем Ваши разработчики будут просить отрефакторить или переписать проект. Давайте разбираться что же выбрать, синяя или красная таблетка?!
Выбирайте синюю таблетку и тот стек в котором у Вашей команды больше всего опыта.
Можно конечно поддаться соблазну и выбрать красную, малоизведанную нишу, но будьте готовы к дополнительным тратам времени на исследование малознакомой технологии, решении неизвестных проблем, о которых мало где написано, а они уж поверьте будут появляться довольно часто. Хотя это может и положительно сказаться на мотивации, как известно программисты любят технологические вызовы.
В общем Вы лучше знаете свою команду и сделаете правильный выбор. А я поделюсь опытом как этот выбор проходил у нас, для нас он не был простым.
Как упоминалось выше, лучше выбирать проверенный стек технологий, если это не своеобразный технологический вызов для Вашей команды. Мы 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#.
Вот такой тернистый путь с выбором стека технологий мы, а теперь и Вы, вместе с нами прошли.
п.с. Особенно буду благодарен тем кто поделится собственным неожиданным опытом выбора стека технологий в комментариях.
... Продолжение следует...
#разработка #управлениепроектами #IT #github #jira #eTime