Технологии,
которые мы используем

Ну, где ты?

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

Пишем на JavaScript, ES6

Используем фреймворки Vue.js, Node.js, Express.js

Работаем с PWA / SPA / Vue Storefront

(если всё ненативное считать хипстерским)

Сообщество Vue.js активно развивается, а порог вхождения при изучении здесь ниже, чем, например, у React, — это делает его простым в освоении даже для джуниор-разработчиков.

Для тестов — CodeceptJS, Cypress

Собираем и компилируем с помощью webpack 4

Для работы со стилями используем препроцессоры Less и Sass

Используем поисковый движок Elasticsearch

Пишем микросервисный front, где каждый сервис отвечает за свой набор бизнес-функций

>

>

>

>

>

Сейчас активно используем трендовый Go, Node.js, и есть один проект на Ruby — на любителя :) Для некоторых проектов используем Node.js.

Фреймворки
и базы данных
Symfony, Zend, Magento, Slim, MySQL, MongoDB

Для развёртывания среды и контейнеризации
используем Docker (Kubernetes, OpenShift)

В качестве
брокера очередей
RabbitMQ

Микросервисы
пишем на Node.js, PHP, Go

Изначально мы много работали с международными e-Commerce-проектами. Сейчас спектр наших задач расширился — появилось много архитектурно сложных проектов, и это неудивительно, ведь если 5–10 лет назад, чтобы опережать конкурентов, компаниям достаточно было иметь «представительство в сети», то теперь обязательными условиями достижения успеха стали автоматизация всех процессов и создание IT-инфраструктуры для всего производственного цикла.

Мы работаем с системами и сервисами: PIM, BPMS, BI -системы, Vue Storefront, API — Swagger, GraphQL, S3.

Для управления версиями — GitLab. Всегда применяем схему непрерывной доставки (совокупность GitLab Flow, тестовых стендов).

Редакторы исходного кода: PhpStorm и Visual Studio Code (лучшие, на наш взгляд).

Но настолько ли это важно?

Те, кто в разработке давно, помнят громкие взлёты и падения. Где сейчас Kohana, Silverlight, Flash, Perl?

Каких-то пять лет назад писать на Ruby on Rails или jQuery было 80-м левелом крутости, а сейчас это стек для любителей (ну ведь Ruby правда классный!). Т. е. популярность фреймворков и языков меняется настолько быстро, что на долгосрочном проекте можно начать писать на суперхайповом стеке, а закончить уже на «мёртвом».

График 1. Спад популярности технологий

* На основе использования их тегов с 2008 года на площадке Stack Overflow. Источник: stackoverflow.com.

График 2. Рост популярности технологий

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

Если посмотреть на топ самых известных разработчиков, выявить взаимосвязь между языками, на которых они пишут, и их успехами не получится. Значит, секрет в чём-то другом?

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

Любой язык может устареть. Гораздо важнее быть развитой личностью, в разрезе профессии это значит уметь работать с ценностью на самом высоком уровне, а не просто кодить.

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

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

Парадигма Agile предполагает, что команда может самостоятельно обеспечить поставку ценности.

В рамках спринта предоставляется результат, с которым клиент или product owner может начать прикладную работу

Каждый разработчик реализует свои задачи, соотнося их с бизнес-целями проекта

Роль тимлида в наших командах близка к роли наставника, а проектный менеджер берёт на себя решение бюрократических вопросов

В наших командах плоская структура, ответственность за проект несут все

Мы уделяем много внимания обучению и развитию осознанности команды, учим работать на самом высоком уровне ценностей, приоритизировать задачи (Impact Mapping), оценивать фичи с точки зрения рентабельности бизнеса (юнит-экономика), непрерывно улучшать процессы на проекте (TQM), повышать качество кода (TDD).

Андрей Путин

Генеральный директор, партнёр kt.team

Если речь идёт о каких-то маленьких проектах, например о создании лендинга, конечно, можно работать и по техническому заданию. Всем понятно, что эта кнопка зелёная и справа, а эта — синяя и слева. Но мы реализуем крупные продуктовые решения, а это совсем другая среда для работы. Сейчас каждый член команды прокачивается именно в методологии. А разработка по техническому заданию, хоть даже на самом модном стеке, — это что? Это то, что сводит на нет любое развитие.

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

Каждый член команды может участвовать в совершенствовании процесса работы: частоты коммуникаций с product owner'ом, длительности спринтов и других процессов.

Таким образом мы развиваем бизнес-мышление и создаём условия для проявления ответственности, инициативности и личностного роста каждого человека в команде.

Мы активно внедряем test-driven development (TDD) на наших проектах. Это позволяет менять сам принцип написания кода — сначала пишутся тесты, потом происходит реализация модулей так, чтобы тесты срабатывали (не путать с юнит-тестами). В итоге TDD приближает архитектуру кода к идеальной, позволяет масштабировать её, унифицирует код (т. е. разные разработчики пишут почти одинаково) и сильно упрощает процесс дальнейшей поддержки и работы с проектом.

Также мы пробуем парное программирование (pair programming). Например, один разработчик пишет, второй проверяет или советует, как улучшить.

Это обязательные практики при гибком и адаптивном подходе к созданию ПО — на наш взгляд, единственно возможном подходе при продуктовой разработке.

Сергей

Старший инженер kt.team

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