Реальная история, как разработать аналог Jira и GitHub за 2 млрд. руб

Выбор стека технологий. Простыми словами о сложном выборе.

Делимся личным опытом, который может быть полезен кому-то еще.

Начало истории

Часть 2. Целевая аудитория. Важность проработки персон в проекте

Настала пора определиться с технологиями на которых будет разрабатываться Ваш продукт. И тут Вы либо имеете опыт и можете самостоятельно принимать участие в выборе и влиять на него, либо всецело доверяете Вашему тех директору, тех лиду или подрядчику и это право остается за ним.

Так или иначе выбор по стеку технологий и базовой архитектуры проекта надо будет сделать и от него будет зависеть как часто в будущем Ваши разработчики будут просить отрефакторить или переписать проект. Давайте разбираться что же выбрать, синяя или красная таблетка?!

Выбирайте синюю таблетку и тот стек в котором у Вашей команды больше всего опыта.

Можно конечно поддаться соблазну и выбрать красную, малоизведанную нишу, но будьте готовы к дополнительным тратам времени на исследование малознакомой технологии, решении неизвестных проблем, о которых мало где написано, а они уж поверьте будут появляться довольно часто. Хотя это может и положительно сказаться на мотивации, как известно программисты любят технологические вызовы.

В общем Вы лучше знаете свою команду и сделаете правильный выбор. А я поделюсь опытом как этот выбор проходил у нас, для нас он не был простым.

Как упоминалось выше, лучше выбирать проверенный стек технологий, если это не своеобразный технологический вызов для Вашей команды. Мы 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#.

Вот такой тернистый путь с выбором стека технологий мы, а теперь и Вы, вместе с нами прошли.

п.с. Особенно буду благодарен тем кто поделится собственным неожиданным опытом выбора стека технологий в комментариях.

…Продолжение следует…