Эта статья является продолжением предыдущий , который поднял много хороших и интересных вопросов.
Когда я начал писать ответы на комментарии, то понял, что многого не рассказал.
Поэтому я решил написать новую полноценную статью, но под другим углом: добавил личный опыт и причинно-следственные связи.
Если вы не читали предыдущую, ничего страшного.
Вам не обязательно это читать.
Главная мысль — в середине 2017 года я инициировал изменение основного стека разработки разрабатываемых backend-приложений Наша компания от .
Net (C#) до Node.js (машинописный текст).
Как это произошло, жалею ли я о принятом решении и собираюсь ли вернуться? Подробнее об этом ниже.
Фон
Сначала небольшой рассказ о себе.Я родился программистом, а не менеджером.
Своё первое приложение, о котором не стыдно рассказать, я сделал в 2003 году на C++ в Visual Studio 6 IDE, ещё будучи студентом.
Это была игра «Трансформеры», в которой использовались D3D, DirectSound и почти все остальные модули, входившие в состав DirectX 9 на тот момент, неважно «я программист».
Мы с одноклассником писали эту игру около года.
Это было именно то программирование, о котором я мечтал с детства — очень высокотехнологичное, с использованием инкапсуляции, полиморфизма и прочих прелестей ООП, а также хитрых алгоритмов и необычных структур данных, таких как кучи Фибоначчи.
Тогда казалось, что для студентов 3 курса без опыта работы и четкого портфолио это была единственная возможность устроиться на работу в очень популярную на тот момент компанию GameDev. Но у нас ничего не получилось.
После 4-часового собеседования, в ходе которого, помимо прочего, мы написали на бумаге алгоритм пересечения двух строк на ассемблере, нам отказали, сославшись на то, что они не готовы сейчас идти на контакт со студентами.
С# .
Net Через пару месяцев после этой неудачи я оказался в крупной (более 100 программистов) компании-разработчике программного обеспечения, где с появлением C# перешёл на него.
В результате общения с более опытными и высококвалифицированными коллегами я узнал на практике такие интересные вещи, как:
- аспектно-ориентированное программирование (АОП) для устранения служебного кода из бизнес-логики;
- генерация кода с использованием tt-шаблонов для сокращения рутины создания аналогичного кода;
- NServiceBus, MSMQ, WCF для межсервисной связи;
- Внедрение зависимостей (DI);
- принцип построения интерфейсов с учетом опций загрузки данных (DLO) для указания связанных объектов, информацию о которых также необходимо получить в результате выполнения запроса.
Что-то вроде самописного GraphQL, которого на тот момент не существовало в публичном виде;
- профилирование и оптимизация SQL-запросов;
- создание веб-приложений с использованием ASP.Net MVC, Knockout и angular.js.
Ну я же программист, не могу без этого! 
Отдел, в котором я работал, разрабатывал интерфейсы, через которые данные из СУБД становились доступными другим системам.
Год за годом в голове стала крепнуть мысль, что в бездушном предприятии все именно так и что ООП для задач типа «возьми это, покрути немного и дай туда» — не лучшая идея.
На уровне реляционной СУБД и контрактов данных в REST API ООП поддерживается только энтузиазмом разработчика, который хочет писать на ООП и только на нем.
А логика промежуточного слоя (между взятием из базы и отдачей потребителю) по сложности и связности отнюдь не GameDev и легко может быть написана в функциональном стиле.
В середине 2015 года, имея 8-летний опыт работы на C#, я пошел в компанию за интересными задачами.
Благодаря накопленному опыту как на бэкенде, так и на фронте, я сразу стал руководителем разработки нового достаточно крупного проекта — онлайн-платформы для p2p и b2p кредитования.
Бэкенд включал C#.
Net Framework 4.6, микросервисную архитектуру, связь микросервисов через WCF, postgreSQL 9.5, ORMLite, генерацию кода ORM-классов для таблиц истории и скриптов для выкатки/перекатки объектов СУБД, около 150 таблиц в СУБД, postsharp 2.1 для AOP, сокетов на SignalR, целевых страниц и WEB API на основе ASP.Net MVC. Что касается angular.js и JS, потому что.
машинописный текст в то время еще не широко использовался.
CI/CD, потоковая репликация на дублирующийся узел.
После завершения проекта в середине 2016 года мы провели ретроспективу вместе с основными разработчиками.
Были выявлены следующие проблемы, которые также являются перспективами развития:
- во фронтенд-части любой рефакторинг легко может привести к невнимательным ошибкам из-за отсутствия статической типизации JavaScript и дороговизны полноценных UI-тестов;
- в системе много логики, которую нужно было писать и поддерживать в двух местах — на C# на бэкенде и на фронте на JS. Эта логика была связана с работой кредитного калькулятора: расчеты плана платежей, пролонгации, досрочного закрытия договора и т.д. По требованиям этот калькулятор также должен был присутствовать на WEB сайте и работать без доступа к бэкенду.
;
- Часто возникала необходимость провести незначительную модификацию, затрагивающую бэк и фронт одновременно, что делал один фулстэк одновременно с двумя программистами — отдельный бэкенд и отдельный фронтенд. При этом в случае одного фулстака разработку и тестирование таких задач было гораздо проще планировать спринтами;
- В системе много кода, связанного с преобразованиями моделей данных в/из DTO. Было бы лучше написать этот код и поддерживать его в актуальном состоянии не вручную, а путем генерации кода;
- Найти в стеке хорошего full-stack программиста (C#, angular или React) для усиления команды сложно.
Но чтобы закрыть проблему рефакторинга кода JavaScript на переднем крае, мы единогласно решили перейти с angular.js на angular.io с поддержкой машинописных сценариев «из коробки».
Я влюбился в Typescript с первого взгляда.
Конечно, это был не такой уж строго типизированный C#, а скорее намек на типизацию, с помощью которой программист описывал свои ожидания от структуры объекта, с которым он работал.
И наши ожидания.
ну, вы помните.
Но все равно это был настоящий прорыв после чистого JavaScript, и рефакторинг фронтенд-части этого проекта перестал быть существенной проблемой.
Это значит, что цель достигнута!
Node.js
В начале 2017 года, после того как typescript показал себя с лучшей стороны, идея попробовать написать бэкенд на typescript мне показалась логичной.На тот момент у меня были следующие требования к backend-разработке:
- код развертывания/развертывания СУБД, включая триггерные функции и таблицы истории, должен создаваться автоматически – методом кодогенерации или ORM;
- код для создания моделей DTO и преобразователей в/из них должен создаваться автоматически с помощью генерации кода;
- Описание Swagger REST API должно автоматически генерироваться из исходного кода;
- должна быть полноценная ORM-система, позволяющая работать с MS SQL, PostgreSQL, mongoDb, а также писать собственные запросы для особых случаев;
- должны быть библиотеки интеграции с redis, RabbitMQ, Socket, потому что.
вероятность использования этих инструментов в новых проектах очень высока;
- кроссплатформенность – чтобы у разработчиков был выбор ОС;
- стабильность и отказоустойчивость;
- возможность оптимизировать узкие места производительности с помощью проверенных и проверенных технологий;
- удобная IDE, которая позволяет легко писать, рефакторить и отлаживать код.
За пару часов в Google я нашел с десяток сервисов, работающих в условиях высокой нагрузки в реальном времени, реализованных на ноде.
Я также узнал, что оптимизацию узких мест производительности следует выполнять на C++.
Чтобы изучить возможности генерации кода, я нанял талантливого технического выпускника с небольшим опытом работы с C# и вообще без опыта работы с JS/TypeScript. Чтобы, среди прочего, проверить порог входа в TypeScript. Ежемесячным итогом работы умного выпускника стали три библиотеки – grunt-генерировать-представление-модель , grunt-генерировать-историю-модель , хрюканье-создание-базы данных , который наша компания до сих пор использует в проектах.
Только приставка «хрюканье-» уже не актуальна.
Он основан на оригинальных версиях, когда они также работали как плагины для создания проектов.
В конце лета 2017 года я созвал собрание технических специалистов, на котором представил возможности node.js, и большинством голосов мы решили сделать следующий коммерческий проект в связке с node.js (TS ) + angular.io (ТС).
Так получилось, что в это время в нашей компании стартовали одновременно два проекта:
- коммуникационная платформа, позволяющая сотрудникам офиса общаться с клиентами через Telegram, WhatsApp, FB, VK и Viber в одном окне;
- и проект по автоматизации внутренних бизнес-процессов одного из наших клиентов.
С тех пор все новые проекты мы делаем на TS. Бэкенд — на node.js, фронтенд — на React (почему перешли с angular.io на React — тема отдельной статьи), а мобильные приложения — на React-native.
Ретроспектива три года спустя
С момента внедрения node.js наша компания реализовала более 10 проектов с использованием этого стека.
Какие преимущества вы получили от перехода с .
Net C# на Node.js Typescript? Разработчики:
- легко и с удовольствием повышают свои компетенции в смежных областях.
Например, в начале этого года к нам в компанию пришел верстальщик, и за время испытательного срока успел поучаствовать в проекте как backend-разработчик и как разработчик мобильных приложений.
Учитывая то, что на наших проектах обязательны CI, CD и code review, я доволен результатом своей работы (CI проходит, количество комментариев по code review уменьшается от пул-реквеста к пул-реквесту);
- получите удовольствие от быстрого перезапуска обновленной версии в режиме разработки с помощью инструмента nodemon. Достаточно сохранить изменение в файле, и утилита мгновенно на него отреагирует, скомпилирует и запустит обновленную версию бэкенда;
- напишите максимально многоразовый код (один для бэка, Интернета и мобильных устройств);
- работа в привычной ОС и IDE;
- иметь больше возможностей для обмена опытом и развития, потому что вокруг все фуллстаки, но кто-то в одном круче, а кто-то в другом;
- не разрешать споры между бэкендёрами и фронтендёрами;
- планируют небольшие доработки функционала, затрагивающие бэк и фронт на одного full-stack разработчика;
- подбирают исполнителя под задачу в зависимости от индивидуальных особенностей разработчиков, независимо от того, бэкендёр это или фронтендёр.
Например, более аккуратный и дотошный разработчик чаще проектирует до пикселя, а программист с хорошо развитым алгоритмическим мышлением чаще пишет логику на лицевой и оборотной сторонах;
- Они рассматривают широкий круг кандидатов: неважно, кодите ли вы на React, пишете на Angular или Node.js, а может быть, вы программист, работающий на React-native? Мы приветствуем всех, особенно тех, кто имеет опыт и понимание необходимости использования машинописи в проектах;
- имеет широкий выбор при формировании команды для нового проекта;
- может ускорить разработку за счет подключения новых разработчиков;
- не ломает голову над тем, кем заменить тимлида или сотрудника на проекте, когда он уходит в отпуск;
- в 90% случаев соблюдает сроки и трудозатраты, указанные на старте проекта.
- один отличный и еще один хороший разработчик, которые не хотели переходить на node.js, у нас больше не работают;
- Отладка машинописного кода с использованием точек останова из VS Code в сочетании с nodemon — отстой.
Точки останова иногда не срабатывают, иногда срабатывают, но не там.
В итоге это приводит к тому, что рано или поздно разработчик сдается и начинает отлаживать код вставками в console.log;
- Машинопись — это ваши ожидания, ваши проблемы.
Часто у новичков возникают проблемы, когда они, например, объявляют целочисленную переменную, в которую получают значение из внешней библиотеки или, скажем, ввод из формы, и долго недоумевают, как так получилось, что у них получилось строковое значение в переменной;
- если при компиляции ts в js появляются циклические зависимости (например, файл a.ts импортирует b.ts, а b.ts импортирует a.ts), то ошибка возникает на этапе выполнения (значения созданные экземпляры импортируемых классов не определены), причем не на этапе компиляции;
- Инфраструктура npm иногда (по нашему опыту 1-2 раза в год) преподносит неприятные сюрпризы.
При обновлении версии любой библиотеки, подключенной через ^ в зависимой библиотеке (зависимость зависимости) ломается все приложение.
Чтобы минимизировать подобные проблемы, был создан служебный файл, описывающий все дерево зависимостей package-lock.json. Но в случаях, когда разработка ведется на разных операционных системах, возникают ситуации, когда этот механизм не работает без кропотливого ручного вмешательства.
- Для написания расширений на C++ необходима высокая квалификация.
Но так получилось, что за три года у нас ни разу в этом не было необходимости.
Производительность уровня JS не вызывала беспокойства;
- Возможности реализации ООП и отражения гораздо беднее, чем в C#.
Но опять же, функциональное программирование с использованием промежуточного программного обеспечения — хорошая альтернатива для очень широкого круга задач;
- самый легкий VS Code по сравнению с мощным VS;
- вместо мощного LINQ встроенные JS-методы для работы с массивами, такие как фильтр, карта, сокращение, сортировка;
- Полноценный VS имеет лучшие инструменты для профилирования приложения под нагрузкой.
Общий
Я не жалею о решении перевести компанию на node.js. Плюсы наших проектов (к которым относятся автоматизация внутренних бизнес-процессов любой сложности, тендерные площадки, p2p/b2b/b2p-платформы, CRM-системы, социальные WEB-сервисы, MVP любых бизнес-идей) на мой взгляд перевешивают недостатки.Сроки реализации проекта не нарушены.
Активно идет набор новых сотрудников, а у тех, кто прошел испытательный срок, горят глаза и рвутся руки в бой! 
В то же время, конечно, есть области, где node.js на данный момент не работает. Это GameDev, Data Science, Machine Learning, AI. Но это понятно.
Если бы для всего был идеальный инструмент, других бы не осталось.
Теги: #программирование #разработка #C++ #.
NET #OOP #node.js #.
net core #разработка с #Node
-
Будущая Тенденция В Erp-Консалтинге Ярка
19 Oct, 24 -
Космические Нелегалы Spacebee
19 Oct, 24 -
Выпущена Java Se 7
19 Oct, 24 -
Выпущен Twitter Bootstrap 3 Rc 1
19 Oct, 24
