www.gnuman.ru

Резюме | Контакты | Работа | Page Title Eraser | GrayModern2 | Статьи
Путешествия | Фотоальбомы | Проект 365 | Блог | Черный список
Как выиграть суд у ГИБДД и вернуть права | Технический департамент своими руками

О вреде многозадачности применительно к людям

Автор: Джоэл Спольски
Переводчик: Дмитрий Майоров
В английском оригинале статья называется Human Task Switches Considered Harmful


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

Поскольку этот сайт для программистов, для разминки я предложу программистскую задачку.

Предположим, что у вас есть две отдельных вычислительных задачи (A и B), которые нужно выполнить. Каждая задача требует для полного выполнения 10 секунд процессорного времени. В вашем распоряжении есть один процессор, и для упрощения будем считать, что других задач в очереди нет.

На нашем процессоре многозадачность необязательна. Так что вы можете выполнить вычисления по очереди...

Последовательная обработка

Computation A Computation B
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

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

Многозадачность

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Какой вариант вы выберете? Первая реакция у большинства людей: многозадачность лучше. В обоих случаях для получения обоих ответов придётся ждать 20 секунд. Но давайте подумаем, сколько времени придётся ждать каждого ответа по отдельности.

В обоих случаях от момента начала вычислений до получения результата B (синий цвет) пройдёт 20 секунд. Но посмотрите на задачу A. При использовании многозадачности с момента начала вычислений до получения её результата прошло 19 секунд... тогда как при последовательной обработке результат был готов через 10.

Иными словами, в этом удачно притянутом за уши примере среднее время меньше (15 секунд вместо 19.5) при последовательной обработке, чем при многозадачности. (Вообще-то этот пример не так уж сильно притянут -- он основан на реальной проблеме, которую Джареду пришлось решать на работе).

Метод Задача A занимает Задача B занимает В среднем
Последовательно 10 seconds 20 seconds 15
Параллельно 19 seconds 20 seconds 19.5

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

Метод Задача A занимает Задача B занимает В среднем
Последовательно 10 секунд 20 + 1 переключение =
20.5 секунд
15.25
Параллельно 19 + 18 переключений =
28 секунд
20 + 19 переключений = 29.5 секунд 28.75

Теперь... ладно, не смейтесь, я знаю, что это глупость ... что если переключения занимают целую минуту?

Метод Задача A занимает Задача B занимает В среднем
Последовательно 10 секунд 20 + 1 переключениe =
80 секунд
45 секунд
Параллельно 19 + 18 переключений =
1099 секунд
20 + 19 переключений = 1160 секунд почти 19 минут!

Чем дольше переключение между задачами, тем больше потери времени от многозадачности.

Само по себе это не слишком революционная мысль, не правда ли? Скоро я стану получить злые письма от деятелей, обвиняющих меня в том, что я "против" многозадачности. Будут ехидно спрашивать "что, хочется обратно во времена DOS, чтобы обязательно выходить из WordPerfect, прежде чем запустить Lotus 1-2-3?"

Но я не про это. Я всего лишь хочу, чтобы вы согласились, что при данном примере:

а) последовательная обработка обеспечивает в среднем более быстрое получение результатов, и

б) чем дольше переключение между задачами, тем больше потери времени от многозадачности.

Хорошо, возвращаемся к более интересной теме управления людьми, а не процессорами. Особенность тут в том, что у программистов переключение между задачами происходит очень, очень, очень долго. Потому что это такое занятие, при котором приходится держать в голове много всякой всячины одновременно. Чем больше, тем быстрее движется работа. Программисту, работающему в полную силу, приходится удерживать в голове миллион разных вещей: названия переменных, структур данных, системных вызовов и вспомогательных функций, которые были ранее написаны и часто используются, даже название подкаталога, где живут исходники. Если послать этого программиста на три недели в отпуск на остров Крит, то он всё это забудет. Человеческий мозг, похоже, при первой возможности высвобождает оперативную память, сбрасывая её содержимое на ленту, откуда всё это потом очень долго доставать.

Насколько долго? Например, моя компания недавно на три недели бросила всё (а именно разработку программного продукта под кодовым названием CityDesk), чтобы выручить клиента, которому внезапно потребовалось наша помощь. Когда мы вернулись в контору, потребовалась почти неделя, чтобы набрать обычную скорость работы над CityDesk.

Вы лично никогда не замечали, что даешь человеку задание, и он его отлично выполняет, но даёшь два задания одновременно, и результат гораздо хуже? Он либо делает одну работу и забывает про другую, либо пытается делать обе, но настолько медленно, что улитки обгоняют. Это потому, что переключение между программистскими задачами происходит медленно. Если у меня на столе два проекта одновременно, то переключение отнимает часов шесть. При восьмичасовом рабочем дне остаётся два часа производительного времени. Негусто.

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



Оригинал статьи: http://local.joelonsoftware.com/wiki/О вреде многозадачности применительно к людям


Другие статьи Джоэла Спольски (The Joel on Software) на русском языке
Маркетологи vs. Разработчики
Похож ли медленный рост на медленную смерть?
О чем ваша компания?
Студенческие проекты и тайм-менеджмент
Особенности Вайфая на конференциях
Новый Офис Fog Creek
Почему форматы Microsoft Office такие сложные? (И как это обойти)
Речь в Йельском университете 1
Речь в Йельском университете 2
Речь в Йельском университете 3
Письмо о стратегии VI
Семь шагов на пути к восхитительной службе по работе с клиентами
Общая картина
Консалтинг по оценке производительности (из писем)
Измерения продуктивности
В поисках Великих Разработчиков
Не дайте Астронавтам Архитектуры вас запугать
Секрет айсберга
Метод отождествления
Метод экономической мотивации
Командный метод управления
Три метода управления (введение)
А ваш язык программирования так может?
Контракты и соглашения которые не стоит подписывать
Ежедневная сборка - ваш союзник и друг
Моя первая проверка Билла Г
Испытание Удобства и Простоты Использования с Морами
Опасности обучения на Java
Как поставлять что-нибудь по почте
Превращение денег в программное обеспечение, которое работает
Три заблуждения теории вычислительной техники
Достигая тех высот
Выбор даты выпуска
Как заставить неправильный код выглядеть неправильно
Совет студентам изучающим вычислительную технику
Верблюды и песочница
Пожалуйста, сэр, могу ли я получить компоновщик?
Как Microsoft проиграла битву за API
Не просто удобство использования
Абсолютный Минимум, который Каждый Разработчик Программного Обеспечения Обязательно Должен Знать о Unicode и Наборах Символов
Как сделать так, чтобы ваше резюме прочитали
Двоекультурие
Бионический офис
Лорд Палмерстон в программировании
Закон Дырявых Абстракций
О вреде премирования
Пять миров
Огонь и движение
Назад, к основам
Весна в Кэмбридже
О вреде многозадачности применительно к людям
По главной улице без оркестра
Тест Джоэла: 12 шагов к лучшему коду
У Microsoft поехала крыша
Cтратегические заметки III. Позвольте мне отказаться!
Пять (неуважительных) причин не иметь тестеров
Ну откуда все эти (неоригинальные) мысли?
Планирование программного обеспечения малой кровью
Стратегические заметки II: Вопрос о курице и яйце
"Я начальник - ты дурак" и команда клоунов
Искусство проведения интервью
А вот ещё про отпуск
Введение в Восхитительный Дизайн
Для чего нужны тестировщики



Правильный CSS! Valid XHTML 1.0 Transitional