Подходы к делегированию разработки членам команды

Question

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

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

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

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

Answer 1

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

Answer 2

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

Рассмотрите шаблон проектирования MVP.

Сначала вы должны разработать диаграммы UML и Class, чтобы каждая группа могла следовать правильным API.

Например, это можно сделать, если одна команда работает над вызовами API и моделями данных.Тогда они могли бы предоставить интерфейс и макетную реализацию.Другие команды, которым нужны вызовы API, могут использовать эти интерфейсы.Таким образом, обе команды могут работать синхронно!

Это означает, что если одна команда работает над слоем VIEW, они знают, чего хочет PRESENTER или как он работает.Они знают все об именах представлений, именах объектов и т. Д. Или, если одна команда работает на уровне PRESENTER, им нужен интерфейс (API) контроллеров модели.Поэтому команда, отвечающая за работу на уровне модели, должна предоставить эти API.

Это означает, что вы должны сделать архитектуру до того, как кто-то начнет кодировать!

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