Pull to refresh

Comments 13

Так и не понял из статьи, каков конечный профит от внедрения .net. Вы много пишете про героические костыли и преодоление сопротивления коллег, но что именно стало лучше? Приложения потребляют меньше ресурсов, быстрее работают, требуют меньше обслуживания (в статье есть намёки, что как раз наоборот) — что из этого?

Слишком часто повторяется слово «внедрять», но нет ответа, зачем менять привычное шило на недоваренное мыло. Инструмент должен выбираться под задачи, а не по принципу «мы можем, и поэтому будем».
Зачем дотнет, я раскрывал здесь:
За последнее время мы довольно ощутимо выросли в плане использования .NET. Если еще лет 5 назад дотнета в Альфе было не так много (в основном — в корпоративных приложениях, кредитовании корпоративного бизнеса, инвестиции и прочее), с такой нагрузкой справлялись примерно 16-20 человек. А сейчас в банке активно развиваются сегменты массового и среднего корпоративного бизнеса, что стало хорошим толчком к развитию кредитных систем.

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


Но повторюсь, делалось это все ради того, чтобы сделать end-to-end продуктовые команды, где 1 full-stack разработчик (фронт + .NET) мог сделать полностью конечную фичу для клиента, в которой нужно будет поправить что-то и на фронте и на бэкэнде, который исторически был написан на .NET-те.
Также плюсом такого решения является то, что мы можем использовать сразу оба рынка специалистов и .NET и Java.

Альтернативой было:
  1. Либо развивать .NET системы только как бэкэнд решения с сервисами, которые потом потреблялись бы middle системами на Java, что требует наличие в команде и Java и .NET разработчика для реализации полной end-to-end фичи для клиента. Так происходит в некоторых командах прямо сейчас и минус этого в необходимости двух разных компетенций в команде и иногда в коммуникации между разработчиками.
  2. Либо переписывать все .NET системы на Java технологии, но это огромные косты т.к. системы огромные и эту идею отбросили почти сразу после ее оценки.


Касательно костылей, мы их потихоньку фиксим, а с появление новых версий .NET Core они явно будут уходить в прошлое.

Касательно проблем с производительностью — их замечено не было, .NET Core работает +- также как и Java Spring Boot, например. Это в целом подтверждают бенчмарки тут

Я ответил на ваш вопрос?

Ответили, но логика вашего ответа мне малопонятна.


Вот вы говорите


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

То есть, вы почему-то вместо повышения эффективности использования уже имеющегося инструмента стремитесь заменить и сам инструмент, и тех работников, которые должны его использовать. Если у вас уже была хорошая команда джавистов, то переучивание их на соседнюю, но менее развитую и сильно отличную в мелочах технологическую платформу — это неэффективно. Или они у вас настолько дорогие, что оказалось дешевле набрать с рынка новых?


Касательно


делалось это все ради того, чтобы сделать end-to-end продуктовые команды, где 1 full-stack разработчик (фронт + .NET) мог сделать полностью конечную фичу для клиента

— в банковском энтерпрайзе такого не бывает, это утопия. Никогда не поверю (я имею достаточно опыта, чтобы не поверить). Либо продукты, о которых идёт речь, нишевые, и далеко не основные для бизнеса.


В общем, складывается ощущение, что решение скорее политическое, чем оправденное технологически.

То есть, вы почему-то вместо повышения эффективности использования уже имеющегося инструмента стремитесь заменить и сам инструмент, и тех работников, которые должны его использовать. Если у вас уже была хорошая команда джавистов, то переучивание их на соседнюю, но менее развитую и сильно отличную в мелочах технологическую платформу — это неэффективно. Или они у вас настолько дорогие, что оказалось дешевле набрать с рынка новых?

Я нигде не писал, что мы переучиваем джавистов на дотнет. Джависты по прежнему и в большом количестве работают и требуются в банке на направлениях там, где они всегда и были и это отражено в основном статье:
И мы встали перед выбором — либо переписывать все это на Java, которая у нас исторически всегда была сильной стороной, да и до сих пор превалирует в рознице

Вопрос у нас скорее стоял переучивать .NET-чиков на JAVA с риском их ухода их банка вместе с экспертизой по ряду ключевых систем.

Поэтому сейчас ситуация такая, что и .NET развивается и Java развивается и никого принудительно ничему не переучивают, а наоборот стараются развивать оба направления.

— в банковском энтерпрайзе такого не бывает, это утопия. Никогда не поверю (я имею достаточно опыта, чтобы не поверить). Либо продукты, о которых идёт речь, нишевые, и далеко не основные для бизнеса.

Ну тут мне нечего сказать, ваш опыт — ваше право не верить. Могу лишь еще раз повторить, что такие команды есть и продукты вполне не нишевые.
Вы опять не поняли вопроса. Вот была Java, большая команда, «сильная сторона». Потом стали что-то писать на C# (или на чем там) и набрали аж 25% спецов от общего кол-ва программистов. Вопрос — зачем? Почему не продолжали испорльзовать Java и ее экосистему? Или мы что-то не поняли?
В банке всегда существовала и .NET (> 8 лет) и JAVA, просто в различных направлениях бизнеса.
В тех направлениях, где была сильна JAVA продолжилась использоваться JAVA, где был силен .NET — продолжился использоваться на .NET, только уже используя некоторые наработки JAVA направления и часть ее экосистемы — микросервисная архитектура, Docker, Apache Mesos, Ansible, Spring Boot Config Server, Jenkins и т.п.

Вы правы, можно было бы этого не делать и напротив бэкэндовых систем на .NET писать JAVA middle бизнес слой и не нанимать тех самых 25% .NET, а нанять такое же количество но JAVA. Но минусы у этого решения следующие и я их уже описывал:
Либо развивать .NET системы только как бэкэнд решения с сервисами, которые потом потреблялись бы middle системами на Java, что требует наличие в команде и Java и .NET разработчика для реализации полной end-to-end фичи для клиента. Так происходит в некоторых командах прямо сейчас и минус этого в необходимости двух разных компетенций в команде и иногда в коммуникации между разработчиками.

+ к этому добавляется высоконкуретный рынок JAVA разработчиков с точки зрения работодателя (Yandex, Mail.ru, Tinkoff, Sberbank и т.д.)

Давно мучает вопрос, но до этого момента я не знал кого спросить. Но обо всем поп порядку.
Вы банк, а это значит, что вы как никто другой заботитесь о скорости загрузки страницы и в случае ssr, её выдачи. И раз вы упомянули о том что работаете и с react и с angular, то значит обязательно должны были производить замеры сравнения производительности. Кто быстрее? Кто быстрее на клиенте и при ssr? Это, конечно, если вы о angular, а не angularjs…
В банке в >95% используется только ReactJS
Деталей выбора фреймворка я вам не скажу, т.к. конкретно JavaScript framework был выбран не нами, а экспертами именно по JavaScript. Мы просто используем их выбор
Я постараюсь найти их контакты, которые смогут ответить на этот вопрос.
serpentcross, привет!
Можешь ты подскажешь почему ReactJS, а не angular был выбран?
DINAMITmax, сорри что так поздно отвечаю)) — не мог никак залогиниться. Хабр писал, что — «нет такого email» :D

А теперь делу: На самом деле, всё сводится к банальному выбору архитектора, который работал в лабе с самого начала. Он типа сказал, что «а я вот только реакт знаю, давайте на нём делать».
Хотя я ещё подозреваю, что тут имело место быть то, что всё таки нам нужен был прежде всего уровень представления (UI), и реакт как нельзя лучше его реализует. А ангуляр это аж целый MVC :)
А жесткой связки, как я наблюдал с .NET и Angular, что прям вообще их никак не разделить
— что???
Единственная жесткая связка — это при реализации Universal SSR на базе .Net core, что на мой взгляд не лучший выбор, в остальном нет никаких жестких связок. Или вы про извращенное желание совместить работу Razor и Angular? — так такие извращения чаще с React делают(ибо его поставить сбоку легче).
Лучшие вариант это: .net core Web Api и отдельный фронт на Nginx/Node (Angular,React и т.д/SSR)
Ключевая фраза в моем сообщение:
как я наблюдал

Именно так в основном делали фронт в тех проектах, что я видел, где пытались использовать Angular (тогда еще 2 версии) вместе с .NET

Сейчас мы с ReactJs делаем именно так, как вы написали:
Лучшие вариант это: .net core Web Api и отдельный фронт на Nginx/Node (Angular,React и т.д/SSR)

То, что также можно делать и с Angular, я не знал. Спасибо, что просветили.
Изложу лишь факты и рекомендации:
1) в статье нет конкретики и полезных знаний, которые можно применить в других проектах (в будущем пишите более детально и конкретно по знаниям, а также подкрепляйте свои выводы конкретными данными и цифрами и четким описанием как делали сравнение)
2) текст не отредактирован должным образом-очень много выпячивания с Я (старайтесь обезличивать, ведь заслуга всегда командная, даже если Вы это сделали-лучше всего аккумулировать это с командой, тем более Вы-руководитель, а значит должны быть едины с командой
3) «доверяй своей команде» (то, чего не умеете сами-делегируйте тому, кто умеет, в частности здесь текст стоит отдать на редактирование имеющим опыт в публикациях людям)
4) не сопротивляйтесь критике (как Вы и сами писали в статье «художник видит», но для объективной оценки всегда нужно все свои выводы подкреплять фактами и конкретикой (см п 1), а также всегда подвергать все авторитеты и выводы сомнениям и перепроверять их лично прежде чем что-то советовать и уж тем более публиковать)
5) вот хороший пример статьи, которая похожа на Вашу: habr.com/ru/post/437610
6) Вас читают и Ваши подчиненные (так пишите статьи так, чтобы это вызывало гордость в их умах, а не выглядело как голый пиар себя самого), и весь русскоязычный интернет (так пишите статьи так, чтобы описанные знания и опыт могли люди применить в своих работах)
Желаю Вам совершенствоваться и избавляться от сильного себялюбия, т к Вы ответственны за своих подчиненных. Так будьте достойным руководителем во всем
Sign up to leave a comment.