Комментарии 12
итого. одно легаси с костылями заменили другим с другими костылями (я представляю сколько их там, если приходилось учиться вебу, не говоря уже про гугловскую поделку) . Ждем обзор, через время от нового менеджера. Как все начало тормозить и надо срочно переводить на новые технологии!
Добрый день! Неаккуратные кусочки кода мы отправили на рефакторинг и сейчас поступаем таким же образом (как, впрочем, и написано в статье). Гигиена кода очень важна. С запуска нареканий нет.
Спасибо за комментарий
Это пока. Уверен, что в момент запуска предыдущей версии тоже не было нареканий. Ведь все списывалось на наличие и отработку базового функционала (большинство доп бизнес процессов переводятся на ручной режим.. потерпите немного, сейчас мы тут основное допилим) . Все начинается после полноценной сдачи в работу и поддержку. Когда подписаны бумаги, что все слелано и отговорок уже не может быть. А бизнес не ждёт. У него свой техдолг. Первое время как то можно отпинываться, но через пол года, год станет невозможно. Придется начинать выполнять их задачи. А объёмы данных растут, а интеграций всё больше. И начинается самый увлекательный процесс - костылегенерация. Это мы ещё не знаем, как и кто писал самое основное - бэк, как и кем разрабатывалась семантическая модель данных (ведь старые то ушли... или их ушли.. это вопросы и тут только ваша версия). если с кривым вебом, двузвенкой (давно научились справляться, путем кластера терминальных серверов, для узких каналрв и тд) можно жить и прогнозировать, то с кривым бэком, кривой структурой БД и невозможностью ее лёгкой адаптации (потому что писали как умели, а не как надо) вы долго не протянете. совершенно не важно на чем у вас фронт написан. это вкусовщина и особой роли не играет. хоть в Excel. всегда важны данные. их непротиворечивость, скорость отклика на мутации и чтение. По этому. Вы конечно проделали работу за деньги, но радоваться пока не чему. Нужна наработка на отказ. Я более чем, уверен, что когда все у вас начнёт безумно тормозить и сыпаться (а это будет. это объективная реальность. меняются задачи и структура данных) вы не придете и не напишите здесь объективный отчет по этому поводу.
Ниже Ваши сомнения развеял разработчик @pavel_horoshun — ознакомьтесь, пожалуйста.
Предыдущее приложение разрабатывалась в 2012 году, конечно же, за годы технологи уходят вперед.
Наверное, самое главное качество команды — учиться на ошибках, находить их, признавать и фиксить, а не закрываться костылями.
увы. там маркетинговый текст. не технический. ни одного технического термина. все сплошь стеки, управленческие шаблоны и тому подобное словоблудие. ещё раз повторюсь. для инфосистем подобного типа фронт имеет второстепенное значение. Первичен быстро и качественно работающий бэк, жующий гигантские объемы данных и при этом быстро отдающий данные и фронту и клиентам.
Из статьи я понял что, нужного результата помогли достичь:
грамотный владелец продукта Сергей по-настоящему вовлекшийся приоритизацией
боевой менеджер проекта Елизавета вдохновляющая команду жесткими сроками
сверхусиленный тимлид Аркадий придумывающий поднятие настроя с помощью мемов
Сложности создавала только беспецедентная пачка из 21 необученных и неуправляемых ноунеймов
+
Спасибо за комментарий.
Отчасти вы правы, задачу покорили люди и их упорство — у нас получилось, благодаря большому желанию и заинтересованности. Мы учились новому, к примеру, брали USM, примеряли, чтобы закрыть определённую цель.
Про «пачку» утверждение неверное — опыта у многих членов команды было немного именно в вебе. Как раз из-за управляемости и быстрой обучаемости (и тому, что крепкая база все же была) мы построили систему.
Изначально «новая команда без опыта» казалась большой сложностью, но благодаря усилиям и желанию участников, обучение пошло быстро. Команда сплотилась и это позволило взять обороты.
Вывод такой:
Сильно хотеть, мотивировать друг друга и не бояться инвестировать время;
Идти на компромиссы (не программировать все и сразу, а выбрать базу и не ставить перед собой нереальную задачу);
Брейнстормить, какие еще варианты для решения одной и той же задачи существуют (как «где взять ресурсы, когда ключевые люди уходят на критичном пути», «как реализировать сложное проще», «как научить хороших и талантливых людей новому быстрее»);
Находиться в контакте друг с другом, слышать (а это в ИТ-мир сложно);
Исправлять ошибки, когда их нашли.
И никто не упомянул аналитиков и тестировщиков :) А стоило. Наши прекрасные девушки и весёлые парни не давали нам, разработчикам, расслабиться - выявляли ошибки в самых сложных местах, где, казалось бы, уже всё предусмотрено. По сути, грань между тестировщиком и аналитиком была не столь явна - каждый старался погрузиться в бизнес-задачи по-максимуму. Ну а там, где компетенций не хватало, подключалась Елизавета и помогала принять верное решение. Способность Елизаветы быть в курсе всех бизнес-требований, возможность удержать всё в голове - это круто, однозначно.
Ну а нам просто не мешали. В команде всего было 3 ведущих разработчика, были новички и ребята с опытом. Не все выдержали темпа - двое уволились ещё до релиза, и порой приходилось работать за двоих, а иногда и за троих. Зато было интересно. Мы зашли в проект как подрядчики, за плечами был успешно внедренный большой проект с большим стеком современных технологий разработки и множеством собственных оригинальных решений, и для нас это была возможность распространить свои компетенции, внедрить новые идеи и перенять лучшие практики. Аркадий как тимлид шел нам навстречу - не препятствовал внедрению наших решений, наоборот, старался помочь во всём. А мы прокачивались в Ангуларе у Аркадия - благо было чему поучиться.
Что мы имеем в итоге с технической стороны.
Мощное front-end приложение на Angular с развитым графическим интерфейсом. Использование реактивных форм, RxJs, elfStore позволило построить интерфейс средней и высокой степени сложности с учетом всех требований дизайна и пользователя. Обратная сторона - достаточно высокий порог вхождения, требующий от разработчика глубоких знаний ангулара, веба в целом и определенный интелектуальный уровень.
Модульные тесты для самых ответственных и сложных форм на Ангуларе.
На бэке - паттерны CQRS (simple), DDD (Domain Driven Design), TDD (Test Driven Development), активное внедрение практик SOLID. Изначально было поставлена идея использовать подходы KISS, SRP - и за этим старались следить. Также внедрили ряд интересных решений по бизнес-логике - отдельной статьи заслуживает, например, реализация модуля Контроля и Уведомлений. Другие идеи - обновленная версия аудита, например - ещё внедряется, есть ряд идей, которые пока ждут своей очереди.
Хорошая документация технических заданий. Да, поначалу не всё было гладко, но мы все учились, и в текущий момент аналитики красавцы - пишут грамотные ТЗ с таблицами, диаграммами, проработкой деталей на самом низком уровне. И что мы имеем: современное, перспективное приложение, способное к дальнейшему развитию и привлекающее сотрудников любого уровня - от senior'а разработчика до крутых аналитиков. Так что ждём, когда к нам присоединятся наши новые сотрудники, и готовы к новым интересным задачам.
Я вот одного понять не могу, почему когда кто-то что-то делает полезное и делится этим с окружающими, находятся комментаторы-критики, которые всё готовы обхаять. Это прежде всего не профессионально и выглядит убого. Надо искать в любых работах и достижениях позитив.
Хотелось бы посмотреть "наворотов" от критиков. Чего они достигли.
Я уверен, что коллектив Россельхозбанка сделал полезную фичу.
Апгрейд системы мониторинга для банка: как мы заменили legacy-систему на современное Web-приложение за 9 месяцев