Natlex

Привет, backend разработчик Natlex Александр тестил в своей работе GigaIDE и делится плюсами и минусами этой системы.

Если вас интересует ИТ-разработка, наш опыт работы и то, как мы помогаем клиентам превращать идеи в цифровые продукты, будем рады видеть в нашем ТГ-канале.

Немного теории

IDE (от англ. Integrated Development Environment) — это интегрированная среда разработки или программа, в которой разработчики пишут, проверяют, тестируют и запускают код, ведут большие проекты.

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

Недавно Сбер выпустил свое десктопное IDE решение GigaIDE на базе IDEA, хочу рассказать об опыте работы с ним.

Сначала хорошее

Работает. Даже вполне хорошо для решения текущих задач. Получилось достаточно быстро перейти с IDEA Ultimate, так как у последней, была заблокирована работа по лицензии на территории РФ.

AI chat & code completion – очень круто. Только ради этого функционала стоит попробовать поработать в GigaIDE. Подсказки кода впечатляют, особенно для типовых или рутинных блоков. Можно работать с существующим кодом и преобразовывать его.

А теперь о минусах

1. Нет доступа к плагинам из стандартного marketplace

Решается включением VPN. Это серьезное ограничение, но скорее всего этой проблемой «больна» любая версия IDE, запущенная из российского сегмента.

2. Производительность редактора из коробки просто никакая

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

Оказалось, дело в большом количестве плагинов, включенных и активированных по умолчанию. Это сделано скорее всего из-за первого пункта (отсутствие доступа к маркетплейс). Мое решение было отключить все плагины кроме минимального набора, необходимых для Java development. В итоге все нормально – летает!

3. Стандартная декомпиляция: пользы от нее как будто ее и нет

Код посмотреть не получится. Хотя обычно все равно в итоге нажимаешь download sources и уже смотришь исходники, а не декомпилированный код.

Стоит упомянуть досадный баг, из-за которого у проекта с несколькими maven репозиториями исходники скачиваются только из первого в списке, и если он фейлится, то сорцов не видать. Если первый стоит mavenLocal, то новые библиотеки в пролете, по крайней мере, пока не соберется проект (Gradle по умолчанию не затаскивает библиотеки в локальный мавен).

4. Keymap: какая боль, какая боль

Если вы любите переопределять комбинации клавиш, у меня плохие новости. В GigaIDE я не нашел возможности сделать export/import и пришлось по кусочкам переносить свои настройки. Название actions не всегда очевидны. Мне помогал поиск именно по сочетанию клавиш, который подсвечивал название action.

5. Autowired поля подсвечиваются как not initialised.

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

6. И еще минусы по Database Navigator и Docker

Database Navigator присутствует по умолчанию и работает, но не без проблем. Дежурный pgadmin стоит на всякий случай и иногда пригождается.

Запускать Docker прямо из GigaIDE нельзя. В IDEA это доступно с помощью Docker plugin, который можно доустановить при подключении через VPN. Иначе открываем терминал и по старинке docker-compose …

Резюме

За встроенную нейросеть хочется сказать спасибо разработчикам. Как я писал ранее, только ради нее можно попробовать GigaIDE в своей работе.

В целом, GigaIDE вполне достойная альтернатива. Хочется надеяться, у Сбера есть планы и вектор развития для этого инструмента.

Если вас интересует ИТ-разработка, наш опыт работы и то, как мы помогаем клиентам превращать идеи в цифровые продукты, будем рады видеть в нашем ТГ-канале.

Привет! QA Engineer Natlex Татьяна задалась вопросом можно ли применить кайдзен в ИТ-компании? И она смогла найти ответ на этот вопрос! В статье Татьяна рассказала о теории кайдзена, причинах выбора этой концепции, проблемах и результатах работы команды.

Немного теории

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

Впервые на практике кайдзен применили японские компании, в том числе Toyota. Опыт оказался позитивным и сегодня японская философия применяется на предприятиях по всему миру. Существует даже институт по изучению кайдзен.

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

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

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

Почему решили попробовать внедрить кайдзен?

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

Наша команда не первый день работала на проекте: мы планировали спринты, писали код, тестировали задачи. В то же время были видны недостатки, которые мешали работе, могли привести к нежелательным последствиям. Рабочий процесс не был статичным. Он периодически менялся, но больше точечно и вынуждено. И в какой‑то момент мы поняли, что нам нужны глобальные изменения.

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

Нами были обозначены болевые точки:

1. Труднодоступность и неактуальность документации. На тот момент требования описывались в задачах и регрессионных тестах. Функциональность менялась от версии к версии. Системы классификации задач не было. Только статьи на confluence, но без привязки к версии ПО. Поиск информации о том, как должна работать та или иная функциональность в конкретной версии, превращался в детективное расследование.

2. Многократные возвраты задач в разработку после тестирования. На момент анализа не было ясно в чем причина этой проблемы. Ко всему прочему постоянно возникали споры между тестировщиками и разработчиками о том, где будут исправления, в текущей задаче или в новой.

3. Частые ошибки в оформлении задач: незаполненные поля, отсутствие исправлений в нужной версии.

4. «Плавающий» онбординг нового сотрудника: полученная информация часто была неполной и зависела от того, кто адаптировал сотрудника.

Как мы действовали дальше?

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

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

После выявления проблем разработали и внедрили меры по улучшению процесса:

1. Наш сотрудник (по совместительству автор статьи:) прошел обучение по работе с требованиями для решения проблем с документацией. Мы разработали новый процесс работы с требованиями конкретно для нашей команды. Сегодня у нас есть четкая система по «превращению задач в документацию» с поддержкой актуальности.

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

Предотвратить болезнь легче, чем лечить ее. Бенджамин Франклин

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

4. Доработали и описали процесс работы команды. Задокументированный процесс помогает уменьшить количество недочётов в работе команды и оптимизировать онбординг.

Заключение

Возвращаясь к вопросу о применимости кайдзена в ИТ, можно сказать, что у нас получился «кайдзен на наш лад». Мы не использовали все инструменты и методики этой концепции, но проделанная работа соответствует перечисленным пяти элементам кайдзен: командная работа в брейншторм-группах с личной заинтересованностью и ответственностью.

На этом наш процесс улучшений в отдельно взятой ИТ‑команде не закончился, ведь это непрерывный и цикличный процесс:)

_________________________________________________________________________

Если вас интересует ИТ-разработка, наш опыт работы и то, как мы помогаем клиентам превращать идеи в цифровые продукты, будем рады видеть в нашем ТГ-канале.