Книга: The Programmers

Программная инженерия — распределенное программирование

Программная инженерия — распределенное программирование

Традиционный взгляд на работу состоит в том, что команда выполняет работу, а отдельный человек вносит вклад в общие усилия. Но как картостроители мы можем попытаться посмотреть на вещи всеми возможными способами, чтобы проверить, насколько они информативны. Мы можем обрисовать границу системы вокруг программирующей команды и заметить, что там нет ничего, что не смог бы сделать отдельный программист. Такие действия, как формулировка требований, проектирование, реализация, тестирование, управление, рецензирование, компилирование (build), архивирование и управление конфигурацией, должны быть выполнены отдельным программистом даже для выполнения небольшой работы. Поэтому мы можем рассматривать деятельность в программной инженерии как распределение того, что один человек мог делать совершенно эффективно в «любительском» («непрофессиональном») режиме во время обучения!

Мы распределяем программирование по тем же причинам, по которым распределяем любой вид обработки: пригодность (availability), параллелизм и специализация.

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

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

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

Оглавление книги