Итак, с методологией мы вроде в прошлый раз разобрались, будем использовать Agile. Теперь попробуем разобраться со стеком на чем будем реализовывать продукт.
На текущий момент самая распространенная модель разработки, это 3-х звенная система. Немного погрузимся из чего она состоит, если кто-то не знает:
- FrontEnd - если коротко, это UI (User Interface), то что вы видите и можете по этому покликать, поскролить и т.д. Как правило это Web интерфейс или Мобильное приложение в редких случаях установочная программа (но это уже ближе к 2-х звенной системе поэтому её мы рассматривать не будем). FrontEnd скачивается или устанавливается на каждый компьютер каждого пользователя.
- BackEnd - его еще кто-то называет Application, это такой зверь, который устанавливается на сервере компании, никому не передается и отвечает за бизнес-логику программы. Это когда бизнес приходит к разработчикам и говорит, я хочу так-то и так-то, только UI должен остаться таким же :)
- DB - База данных, тут уже не будем останавливаться, это просто хранение данных в специальных системах на сервере. Называются они еще СУБД и их тоже не мало (MySQL, MSSQL, Oracle, Postgres, GreenPlum, MongoDB, и т.д.) . Но я бы не рекомендовал нагружать их разработчиков кодом, без лишней необходимости.
В Сбере классическим решением было бы использовать для FrontEnd разработки - React на языке JavaScript, Backend разработки - язык Java или Python, СУБД Postgres. (Не будем вдаваться в детали, но в Сбере «свой Блекджек …», и поверх этих технологий, стоит еще куча надстроек кибербезопасности банка, обычным компаниям это может и не понадобиться)
Но, как я и написал «...было бы...», но мы выбрали другой путь, это стек из React (язык JavaScript) + Node.js (как ни странно, тоже JavaScript), и я постараюсь объяснить почему:
Мы хотели чтобы команда разработчиков была максимально «независима» от языка программирования, и оба стека тут на JavaScript.
Если разработчику который пишет FrontEnd, понадобилось «вытащить» какую-то дополнительную информацию для пользователя, ему не нужно: делать задачу BackEnd разработчику, то поставит её в беклог, через неделю её оценит, потом реализует эту задачу, сделает релиз, и только тогда, FrontEnd разработчик сможет этим воспользоваться и дописать свой функционал. Это удлиняет процесс разработки, гораздо проще зайти в код backend’а самому добавить пару строк кода, и сразу воспользоваться им для своей задачи. Так мы сокращаем LD (LeedTime) с 4-6 недель до 1-й недели.
- Кто-то может сказать - «Вы просто не проводите АНАЛИЗ!!!! Если бы вы всё проанализировали, написали ТЗ и завели бы в спринт, вы бы сделали это так же за 1 неделю!» И он будет прав, с двумя оговорками. Во первых, Анализ - тоже дело времени и время на анализ тоже нужно включать в разработку, а это тоже, как правило 1-2 недели. Во вторых, это уже меньше похоже на Agile, а больше смахивает на WaterFall, а мы всё таки выбрали Agile как методологию.
- Это же касается и BackEnd разработчиков, если в BackEnd’е поменялся какой-то формат, то ему, чаще всего, проще зайти во фронт и поправить там пару строк кода.
- Гибкость языка. Особенно это чувствуется на Backend’е. Те кто знает как строга и типизирована та же Java, тот понимает, что любое изменение может сильно удлинить процесс написания кода. Отсутствие типизации в JavaScript, тоже «палка о двух концах», но она позволяет выводить в ПРОМ функционал гипотезы, и если гипотеза действительно подтверждается, уже типизировать готовый код (а как оказывается делается это в JavaScript достаточно просто)
- Встроенная асинхронность. JavaScript - изначально язык для Web-разработки, и он специализирован на асинхронности работы пользователей. Если коротко, пока один пользователь ждет вычислений другие пользователи продолжают работу с системой без задержек, он чего пользователи не ждут друг друга а работают «параллельно». Тут конечно есть тонкости разработки, и при «кривых» ручках можно «положить» и весь сервер, но эти задачи, как оказалось на практике, легко разрешаемые.
- Предвзятость к JavaScript особенно в BackEnd’е. OldSchool’ьные разработчики могут сказать - «да ваш JavaScript однопоточный, он нерационально использует ресурсы сервера! Из всех ядер процессора он использует только один!» И в принципе будут правы, если они никогда профессионально не занимались разработкой BackEnd’ом на JavaScript. В этом языке «под капотом», существует такое понятие как Кластер (Cluster), используя его вам даже нет большой необходимости использовать сложные системы контейнеризации по типу Kubernetes, и существуют Worker’ы, которые предназначены для вычисления сложной математики и обработки BigData на сервере не останавливая работу других пользователей.
Получилось как-то много, но вроде полезно :)
Итак, что мы имеем на выходе, чтобы начать процесс разработки продукта:
- Сокращение штата. Вместо Аналитика, FrontEnd и BackEnd разработчика, DevOps инженера, вам достаточно одного FullStack JavaScript разработчика.
- Не нужно закупать лицензии на ПО и оборудование (ну может IDE купить нормальную разработчику, чтобы он не сильно «расстраивался», но JetBrains к сожалению в России сейчас недоступен) :)
- Не нужны мощные сервера для ПРОМа и уж тем более для разработки, на нашей практике, сервер на 4-х ядрах процессора и 8 Гб ОЗУ спокойно переваривал 2500 пользователей или 100 одновременных запросов в секунду. Меньше я бы не рекомендовал.
- Если вам понадобится в будущем упаковать продукт в программу (по типу EXE или DMG), то это легко решается с помощью инструмента для JavaScript - Electron
- Если вам понадобиться в будущем упаковать продукт в мобильное приложение, то это с «приседаниями», но можно реализовать с помощью Cordova, или в крайнем случае переписать на тот же React Native.
Итого:
Почти для всех операционных систем и мобильных приложений мы используем один язык разработки JavaScript, и для всего этого достаточно одного разработчика. Сами разработчики JavaScript достаточно хорошо распространенны на рынке труда, как ни как всем нужен какой-никакой UI. :)
