Хочешь присоединиться к нашей команде?
Заполни заявку
Выбери офис
 

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

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

Сейчас наш стек представлен следующими технологиями

Frontend


Пишем на JavaScript, ES6
Используем фреймворки Vue.js, Node.js, Express.js
Работаем с
PWA / SPA / Vue Storefront
Почему Vue.js?
Нормальный хипстерский фреймворк :)
(если всё ненативное считать хипстерским)
Сообщество Vue.js активно развивается, а порог вхождения при изучении здесь ниже, чем, например, у React, — это делает его простым в освоении даже для джуниор-разработчиков.
Для тестов — CodeceptJS, Cypress

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

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

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

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

Backend

Из классики — PHP/Magento
Сейчас активно используем трендовый Go, Node.js, и есть один проект на Ruby на любителя :) Для некоторых проектов используем Node.js.
Фреймворки
и базы данных
Symfony, Zend, Magento, Slim, MySQL, MongoDB

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

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

Используем Magento как CMS для управления контентом и бизнес-логикой (управления заказами, остатками, «Корзиной»), используем интеграции через REST API.

Изначально мы много работали с международными e-Commerce-проектами. Сейчас спектр наших задач расширился — появилось много архитектурно сложных проектов, где Magento — не монолит, а связь нескольких систем (Storefront, API, Elastic, PIM, набор микросервисов).

Ещё немного о технологиях

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

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

Редакторы исходного кода: PhpStorm и Visual Studio Code (лучшие, на наш взгляд).
Стек не самое главное
На каком стеке лучше развиваться? А что будет в тренде в следующие год-два? А что лучше: PHP или Python? Vue или React? Если столкнулись два фаната — битва в песочнице обеспечена.
Но настолько ли это важно?
Те, кто в разработке давно, помнят громкие взлёты и падения. Где сейчас Kohana, Silverlight, Flash, Perl?

Каких-то пять лет назад писать на Ruby on Rails или jQuery было 80-м левелом крутости, а сейчас это стек для любителей (ну ведь Ruby правда классный!). Т. е. популярность фреймворков и языков меняется настолько быстро, что на долгосрочном проекте можно начать писать на суперхайповом стеке, а закончить уже на «мёртвом».
График 1. Спад популярности технологий
* На основе использования их тегов с 2008 года на площадке Stack Overflow. Источник: stackoverflow.com.
График 2. Рост популярности технологий
Пробовать новые технологии — это интересно и круто, и каждая современная IT-компания обязана дать своим командам возможность осваивать новое. Поэтому у нас есть и Go, и Python, и Node.js, и Kubernetes, и Vue.js…
Но это не волшебная таблетка ни для развития разработчика, ни для самой компании, если главная цель — повышение культуры разработки.
Если посмотреть на топ самых известных разработчиков, выявить взаимосвязь между языками, на которых они пишут, и их успехами не получится. Значит, секрет в чём-то другом?

Вся соль в принципах

Основная ценность, за которую мы бьёмся, — повышение культуры и качества разработки. И это в том числе про методологии, подходы, инструменты и процессы внутри компании. Мы часто пробуем новое, а оставляем то, что отражается на результате и нравится команде.
Развить свою личность, а не «выучить ещё один язык»!
Любой язык может устареть. Гораздо важнее быть развитой личностью, в разрезе профессии это значит уметь работать с ценностью на самом высоком уровне, а не просто кодить.

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

Как мы это делаем внутри компании

Повышаем осознанность команды через подход True Agile

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

Парадигма Agile предполагает, что команда может самостоятельно обеспечить поставку ценности.
В рамках спринта предоставляется результат, с которым клиент или product owner может начать прикладную работу
Каждый разработчик реализует свои задачи, соотнося их с бизнес-целями проекта
Роль тимлида в наших командах близка к роли наставника, а проектный менеджер берёт на себя решение бюрократических вопросов
В наших командах плоская структура, ответственность за проект несут все
Мы уделяем много внимания обучению и развитию осознанности команды, учим работать на самом высоком уровне ценностей, приоритизировать задачи (Impact Mapping), оценивать фичи с точки зрения рентабельности бизнеса (юнит-экономика), непрерывно улучшать процессы на проекте (TQM), повышать качество кода (TDD).
Андрей Путин
Генеральный директор, партнёр kt.team
Если речь идёт о каких-то маленьких проектах, например о создании лендинга, конечно, можно работать и по техническому заданию. Всем понятно, что эта кнопка зелёная и справа, а эта — синяя и слева. Но мы реализуем крупные продуктовые решения, а это совсем другая среда для работы. Сейчас каждый член команды прокачивается именно в методологии. А разработка по техническому заданию, хоть даже на самом модном стеке, — это что? Это то, что сводит на нет любое развитие.

Ответственность через свободу в принятии решений

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

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

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

Повышаем качество кода через экстремальное программирование (extreme programming, XP)

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

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

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

О ценностях

Всё, что мы делаем, — это не только и не столько про набор инструментов, хотя, безусловно, мы ориентируемся на практики, которые сейчас применяют крупнейшие IT-компании.
Наша цель — формирование культуры как философии, подхода к разработке и оценке качества, осознания собственной ответственности и роли, степени доверия и уровня взаимодействия в командах.
Ведь культура — это не бизнес-процесс в BPM-системе, её невозможно создать или обеспечить извне. И как компания мы никому не можем гарантировать культуру!

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

И это точно больше про людей, чем про любые технологии.
Хочешь присоединиться к нашей команде?
Заполняй заявку, даже если не нашлась подходящая вакансия или у тебя остались сомнения. Наш менеджер сориентирует тебя и ответит на все вопросы.
Здесь ты можешь написать о своём опыте и достижениях и оставить ссылку на портфолио
+7 495 369-20-29 (доб. 127)
Или свяжись с нами любым удобным тебе способом.

Пишем статьи и делимся опытом в нашем блоге


Полезная статья о сути работы Node.js и Event Loop, которая поможет разработчикам осознанно и более гибко управлять потоком выполнения программы.

Тимлид: что это за роль, как стать тимлидом, обязанности тимлида, что должен знать и уметь тимлид. Советы от kt.team, как IT-специалисту ускорить свой рост в команде.

Скандал на «Стачке» и удаление сексистского спикера. А что на самом деле происходит с женщинами в IT? Наш опыт.

Или подписывайся на наши новости

Жизнь kt.team кипит онлайн
на нашей странице в Instagram!

© 2020 ООО «КТ Групп»
ООО «КОМПЛИЦЕРТЕ ТЕХ»
Komplizierte Technologien, GmbH
офисы
Москва: ул. Ильинка, д. 4 (Гостиный Двор)
Тольятти: ул. Офицерская, д. 12А, корп. 1 (ТЦ «Рим»)
Краснодар: ул. Северная, д. 490 (БЦ «Кутузовский»)