Как вы организуете разработку сложного продукта?

Question

[nico]

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

В общем, проблема в том, что после каждого спринта я вижу, что тестеры находят кучи багов, которые мы потом дружно правим 3-4 дня. Потому, как, тебя просят добавить или починить функцию А, ты ее чинишь, но попутно, возможно, ломаешь явно фичу Б и неявно В (возможно будет ошибка при работе В и С). Какие-то вещи, особенно из domain покрыты тестами, но всего не покрыть да и логика сложная и код легаси местами.

Так вот, по идее, мне кажется, что возможно организовать разработку так, чтобы этих вот багов было минимум. Что нужно делать? больше тестов? Внимательнее вносить правки в код и проверять все на 100 раз? Или смириться, "так у всех"?

Answer 1

[Сергей Протько]

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

Тесты, TDD, рефакторинг, SOLID. И тогда нет боли. Но это увы далеко не на каждом проекте встретишь.

Потому, как, тебя просят добавить или починить функцию А, ты ее чинишь, но попутно, возможно, ломаешь явно фичу Б и неявно В

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

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

Баги это хорошо, регрессионные баги это плохо, это показатель того что с нашим кодом что-то не так. Уменьшить количество багов просто - нужно больше тестов с учетом различных инвариантов. Но иногда это избыточно, и проще просто словить и пофиксить баг.

Так же рекомедную вам ознакомитсья с практиками экстримального программирования, там много внимания удиляется обратной связи от момента когда разработчик что-то сломал до момента обнаружения проблемы (парное программирование, TDD).

Comments

[nico]

Сергей, вот в том то и дело, что я книг читаю много и как-то что-то где-то применяю (особенно из Working with Legacy Code и Art of unit testing), но это в рамках своей личной работы.
К сожалению, эти же книги меня заставляют смотреть на проект в целом. К сожалению, это потому, что не смотрел бы, жил бы счастливо и получал бы свои неплохие деньги за работу.
Однако, когда я смотрю на проект я вижу большое количество кода, основанного на хорошей архитектуре, но которые стал "smelly". Я добился того, что на новый функционал мы теперь пишем юнит тесты, но проблемы в существующих классах. Там все слишком запутанно и как это покрыть тестами я не представляю. Частично, да, но не на 70-80% как советуют книги. А без тестов рефакторить просто невозможно.

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

[Сергей Протько]

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

В целом это нормально, главное не пытаться "бежать" как там вам предлагали, а попытаться что-то с этим сделать. Тем более судя по описанию команда у вас адекватна.

[nico]

Сергей Протько: спасибо за информацию, буду пытаться копать в этом направлении

Answer 2

[Memorivardo]

Покройте код тестами. Сразу будете видеть, что отвалилось после каждого коммита.

Comments

[Mrrl]

Будут отваливаться тесты. Не рассчитанные на изменившиеся структуры данных и интерфейсы.

[Schullz]

Mrrl: так интерфейсы со структурами не каждый день меняются, всё равно от большинства тестов польза будет

[nico]

имеется сотня классов (с логикой, не POCO) их покрывать будем пол-года только

[nico]

плюс, я все же рядовой разработчик, да еще и на удаление, мое влияние на процесс ограничено

Answer 3

[xmoonlight]

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

Comments

[Сергей Протько]

RUP?

[xmoonlight]

Сергей Протько: нет! не до такого же маразма доходить... ) просто для ориентира кодеров и все... не более..

[Сергей Протько]

xmoonlight: есть еще такие веселые вещи как сторимэппинги, но они никак не позволяют оградить разработчиков от того бреда которые они потом пишут в коде. От этого спасет только код ревью и TDD.

[xmoonlight]

Сергей Протько: внутри блока - согласен, а при передаче от блока к блоку - проверять принимаемые структуры данных должны модульные стыки. Тогда массу ошибок автоматом переловит сама модульная архитектура. (это я из опыта и практики уже говорю)

[Сергей Протько]

xmoonlight: под "модульной" вы микросервисы подразумеваете? Хз... я люблю луковую архитектуру... и мне важно что бы внутри моей "луковицы" все было хорошо. А стыки это легко, интеграционные и E2E тесты хоть минимально иметь и проблем нет.

[xmoonlight]

Сергей Протько: луковую - это как? (я не сталкивался и не понимаю....)

[Сергей Протько]

xmoonlight: ну jeffreypalermo.com/blog/the-onion-architecture-part-1

я сейчас делаю перевод вот этой статьи: fideloper.com/hexagonal-architecture - там чуть интереснее и проще описано все это дело.

[xmoonlight]

Сергей Протько: мне напомнило QR-коды с треугольниками в тайлах: никому не нужно и гораздо хуже, зато сделали мы и она не похожа на другие...)

[Сергей Протько]

xmoonlight: мм вы о чем? Это обычная слоеная архитектура. Как показывает практика - лучше никто ничего не придумал пока-что.

[xmoonlight]

Сергей Протько: Слоёная - это всего навсего визуальное представление процесса. Ок. Я нарисую как я вижу и дам линк - будет понятней.

[Сергей Протько]

xmoonlight: какого процесса? Ну пока вы рисуете я обрисую свое виденье:

приложение состоит из 3-х слоев - Framework Layer (или Infrastructure Layer), Application Layer и Domain Layer

Domain Layer - бизнес объекты и сервисы содержащие бизнес правила, так же интерфейсы репозиториев для бизнес объектов

Application Layer - сервисы уровня приложения, хэндлеры команд и экзекюторы запросов если мы говорим про CQRS. По классу на юз кейс. Все что делают эти сервисы - управляют другими сервисами и бизнес объектами. По сути они дублируют содержание юз кейса. Весь этот слой и слой ниже никак не привязан к фреймворкам, базам данных и прочей чуши (конечно в идеале только, в реальночти чуть чуть просачивается). Для того что бы протестить этот слой (а значит всю бизнес логику) мне не надо подключать фреймворки и базы данных - максимальная скорость выполнения тестов, можно делать все через TDD.

Framework Layer - содержит реализацию интерфейсов объявленных в Application Layer и Domain Layer. У меня там весь фреймворк (контроллеры, http foundation и т.д.), библиотечки (aws sns например или еще чего), реализация доктриновский репозиториев и прочая чушь. Является поддерживающим слоем. То есть не влияет на бизнес логику, он нужно что бы выполнить то что хочет приложение (имэйл послать например). Но грубо говоря это только интерфейс, этот слой уже снаружи приложения, оболочка.

Вот... Framework Layer и Application Layer ходят DTO. Приложение ничего не знает о интерфейсе через которое с ним работают и все такое. Вот так можно жить и жить очень хорошо. Но надо развивать инструменты кодогенерации так как DTO писать руками скучно.

[xmoonlight]

Сергей Протько: я понял! я делаю почти так же: объектные роли - Domain Layer+DB, Application - манипуляция ролями (+логика), Framework - это уже объектные MVC.

Answer 4

[Максим Кузнецов]

В целом, похоже, что у вас в команде есть несколько проблем.
Во-первых, либо есть проблемы с архитектурой, либо неверно составлен план разработки. Это может быть связано с игнорированием ограничений agile. Мне кажется, что присутствует и то, и другое.
Во-вторых, программисты не сильно мотивированы писать качественный код, либо не имеют возможности этого делать. Возможно, у них не складывается модель предметной области, и, исправляя одну бяку, они тут же вносят новую. Есть смысл подумать о специализации конкретных разработчиков (или небольших групп разработчиков) на конкретных направлениях. Попробуйте разбить крупный проект на несколько отдельных "изолированных" проектов, в каждом из которых следует рассматривать смежные подпроекты как внешние системы. Каждому подпроекту нужна своя команда. Это сделает проект управляемым и понятным всем участникам.
А дальше, соглашусь с Сергей Протько , "Тесты, TDD, рефакторинг, SOLID".

Comments

[nico]

да в общем-то разработчиков всего 5 и практически каждый на чем-то специализируется (БД, фронтэнд и т.п.).
Вы правы, возможно это из-за отсутствия понимания предметной области, или, как указал xmoonlight схем бизнес-процессов, поэтому не всегда ясно что и как должно работать и за что отвечать.
Я правда, пока не представляю как это можно исправить, но подумаю. Проблема еще в том, что тим лид вечно занят где-то там в продакшене, особо с ним коммуникации нет, только с серам мастером, который по сути менеджер, не архитектор.

[Сергей Протько]

nico: если у вас нет понимания предметной области - это большая проблема, с учетом того что как вы сказали логика довольно сложная. В этом плане помогают user stories/use cases прописанные + схемки всякие.

[Максим Кузнецов]

nico: Если тим-лид занят где-то, кроме проекта, то у проекта нет тим-лида. Поэтому первое, что Вы должны сделать - найти технического лидера, который наведёт порядок в связке между требованиями и реализацией. Он же сформулирует корректный план разработки. И он же направит работу команды в правильное русло. Более подробно на эту тему я высказывался здесь: m-i-kuznetsov.livejournal.com/58244.html, загляните, там есть несколько цитат весьма уважаемых людей. Там же я описал похожую на Вашу ситуацию (хотя у нас тогда проект был несколько крупнее: несколько аналитиков, почти десяток штатных разработчиков, тестеры, плюс подрядчики).

Answer 5

[lamazavr]

высокая связанность кода, бегите

Comments

[nico]

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

Answer 6

[Елизавета Борисова]

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