|
|
|
SergeCpp |
|
|||
Профиль Группа: Участник Сообщений: 955 Регистрация: 8.8.2005 Где: At Home Репутация: нет Всего: 124 |
Одно из первых дел, которое приходится осваивать при управлении командой программистов, это распределение фронта работ. Что на нормальном языке означает сказать, кому что делать. В разговорном иврите есть соответствующий фразеологический оборот, в примерном переводе означающий "разбрасывание папок" (потому что вы подкидывете папки людям на колени). То, как вы решаете, какие папки окажутся на чьих коленях, может сильно увеличить производительность, если сделать это правильно. А если нет, то может получиться одна из тех неприятных ситуаций, когда никто ничего толком сделать не может и все жалуются, что "сплошной бардак и фиг что тут поделаешь".
Поскольку этот сайт для программистов, для разминки я предложу программистскую задачку. Предположим, что у вас есть две отдельных вычислительных задачи (A и B), которые нужно выполнить. Каждая задача требует для полного выполнения 10 секунд процессорного времени. В вашем распоряжении есть один процессор, и для упрощения будем считать, что других задач в очереди нет. На нашем процессоре многозадачность необязательна. Так что вы можете выполнить вычисления по очереди или использовать переключение между задачами. В последнем случае на нашем конкретном процессоре задачи выполняются по одной секунде за раз, и время переключения пренебрежимо мало. Какой вариант вы выберете? Первая реакция у большинства людей: многозадачность лучше. В обоих случаях для получения обоих ответов придётся ждать 20 секунд. Но давайте подумаем, сколько времени придётся ждать каждого ответа по отдельности. В обоих случаях от момента начала вычислений до получения результата B пройдёт 20 секунд. Но посмотрите на задачу A. При использовании многозадачности с момента начала вычислений до получения её результата прошло 19 секунд... тогда как при последовательной обработке результат был готов через 10. Иными словами, в этом удачно притянутом за уши примере среднее время меньше (15 секунд вместо 19.5) при последовательной обработке, чем при многозадачности. (Вообще-то этот пример не так уж сильно притянут -- он основан на реальной проблеме, которую Джареду пришлось решать на работе). Я сказал, что "время переключения пренебрежимо мало." Вообще-то на настоящем процессоре это какое-то время всё же отнимает... столько, сколько нужно для того, чтобы сохранить состояние регистров процессора одной задачи и загрузить значения для другой. На практике этим действительно можно пренебречь. Но чтобы усложнить себе немного жизнь, вообразим, что переключение между задачами занимает полсекунды. Теперь стало совем плохо... Последовательно = 15.25 секунд Параллельно = 28.75 секунд Теперь... ладно, не смейтесь, я знаю, что это глупость ... что если переключения занимают целую минуту? Последовательно = 45 секунд Параллельно = почти 19 минут! Чем дольше переключение между задачами, тем больше потери времени от многозадачности. Само по себе это не слишком революционная мысль, не правда ли? Скоро я стану получить злые письма от деятелей, обвиняющих меня в том, что я "против" многозадачности. Будут ехидно спрашивать "что, хочется обратно во времена DOS, чтобы обязательно выходить из WordPerfect, прежде чем запустить Lotus 1-2-3?" Но я не про это. Я всего лишь хочу, чтобы вы согласились, что при данном примере: а) последовательная обработка обеспечивает в среднем более быстрое получение результатов, и б) чем дольше переключение между задачами, тем больше потери времени от многозадачности. Хорошо, возвращаемся к более интересной теме управления людьми, а не процессорами. Особенность тут в том, что у программистов переключение между задачами происходит очень, очень, очень долго. Потому что это такое занятие, при котором приходится держать в голове много всякой всячины одновременно. Чем больше, тем быстрее движется работа. Программисту, работающему в полную силу, приходится удерживать в голове миллион разных вещей: названия переменных, структур данных, системных вызовов и вспомогательных функций, которые были ранее написаны и часто используются, даже название подкаталога, где живут исходники. Если послать этого программиста на три недели в отпуск на остров Крит, то он всё это забудет. Человеческий мозг, похоже, при первой возможности высвобождает оперативную память, сбрасывая её содержимое на ленту, откуда всё это потом очень долго доставать. Насколько долго? Например, моя компания недавно на три недели бросила всё (а именно разработку программного продукта под кодовым названием CityDesk), чтобы выручить клиента, которому внезапно потребовалось наша помощь. Когда мы вернулись в контору, потребовалась почти неделя, чтобы набрать обычную скорость работы над CityDesk. Вы лично никогда не замечали, что даешь человеку задание, и он его отлично выполняет, но даёшь два задания одновременно, и результат гораздо хуже? Он либо делает одну работу и забывает про другую, либо пытается делать обе, но настолько медленно, что улитки обгоняют. Это потому, что переключение между программистскими задачами происходит медленно. Если у меня на столе два проекта одновременно, то переключение отнимает часов шесть. При восьмичасовом рабочем дне остаётся два часа производительного времени. Негусто. Выясняется, что если вы поручили кому-то два задания одновременно, скажите спасибо, если этот кто-то "придушит" одну из задач, чтобы получить возможность работать над другой, потому что в этом случае результат будет раньше. Мораль всего этого в том, что не следует давать людям работать более, чем над одной задачей одновременно. Убедитесь в том, что они это знают. Хорошие менеджеры считают своей обязанностью устранение препятствий, мешающих людям концентрироваться на одном деле и добиваться результатов. Когда появляются неожиданные вводные, подумайте, не можете ли вы разобраться с ними самостоятельно, прежде чем поручать программисту, который сидит по уши в коде другого проекта. Джоэл Сполски, перевод Дмитрия Майорова. 12 февраля 2001 Оригинал: Human Task Switches Considered Harmful ... А Дейкстра прав!.. |
|||
|
||||
Sardar |
|
|||
Бегун Профиль Группа: Модератор Сообщений: 6986 Регистрация: 19.4.2002 Где: Нидерланды, Groni ngen Репутация: нет Всего: 317 |
На счёт двух задачь и процессора немного не точно. Переключение процессов позволяет утилизировать простои процессора, т.к. редко какая задача требует 100% загрузки (более 90% десктопный процессор простаивает). Две интенсивные по вычислениям задачи распараллеливать на тредах глупо. Обычно решается пулом тредов, где количество тредов в пуле равно количеству ядер/процессоров в системе. В итоге получаем максимальную производительность на интенсивных, не зависимых друг от друга задачах.
На счёт менеджмента, да, заставлять программиста вести два проекта одновременно есть абсолютная глупость. Хотя если проекты просты и умещаются сразу в голове, то всё получиться, даже интересней -------------------- Опыт - сын ошибок трудных © А. С. Пушкин Процесс написания своего велосипеда повышает профессиональный уровень программиста. © Opik Оценить мои качества можно тут. |
|||
|
||||
skyboy |
|
|||
неОпытный Профиль Группа: Модератор Сообщений: 9820 Регистрация: 18.5.2006 Где: Днепропетровск Репутация: нет Всего: 260 |
где это ты такие простые проекты нашёл? лабораторки студентам, что ли? Полностью согласен с положением в статьи. Сам в ситуации, когда начали проект на Delphi и надо было сделать корректировки к уже немного подзабытому проекту на PHP. Это такая пытка! Хорошо, хоть совсем недолго такое продолжалось... |
|||
|
||||
smartov |
|
|||
свой собственный Профиль Группа: Экс. модератор Сообщений: 4225 Регистрация: 2.2.2006 Где: NJ Репутация: нет Всего: 259 |
Идея статьи правильная только жутко боянистая В смысле того, что думаю каждый программист это прочувствовал на сворем личном горьком опыте.
Тут недалеко есть ещё одна тема по этому поводу. И именно по причинам, приведенным в статье, я счтьаю что каждый менеджер проектов должен хоть побыть девелопером. Иначе он просто не будет чувствовать этих вещей. |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 1 Всего: 61 |
Или доверять своему team lead'у. |
|||
|
||||
mr.DUDA |
|
|||
3D-маньяк Профиль Группа: Экс. модератор Сообщений: 8244 Регистрация: 27.7.2003 Где: город-герой Минск Репутация: нет Всего: 232 |
Попытался девелопить два проекта одновременно. В результате не хочется работать ни над одним.
-------------------- |
|||
|
||||
Wowa |
|
|||
Эксперт Профиль Группа: Админ Сообщений: 15017 Регистрация: 14.9.2000 Где: Винград Репутация: нет Всего: 290 |
Согласен в приципе со статьей. Сам страдаю тем, что веду много проектов одновременно. Буду перестраиваться.
|
|||
|
||||
stron |
|
|||
Консультант Профиль Группа: Комодератор Сообщений: 1654 Регистрация: 17.7.2003 Где: Питер Репутация: нет Всего: 36 |
А мне кажется, что описанныя ситуация очень идеализированна. Согласен с Sardar'ом.
Всё очень сильно зависит от проектов. -------------------- подписи нет |
|||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: нет Всего: 151 |
В случае однотипных проектов (таких, например, как ведение нескольких кастомизаций), никакого вреда от работы на два-три фронта нет. А проектам польза.
-------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: нет Всего: 151 |
smartov, ну так это не недостаток процесса работы с несколькими проектами, а неудачный configuration management данного проекта. У нас вот все лежит в одной системе (в данном случае - ClearCase), и структура кода организована таким образом, что при сборке билдов кастомизационные ветки накатываются поверх ядра. И никаких особенных проблем мы не испытываем. Изменения вносятся только один раз.
-------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
smartov |
|
|||
свой собственный Профиль Группа: Экс. модератор Сообщений: 4225 Регистрация: 2.2.2006 Где: NJ Репутация: нет Всего: 259 |
batigoal, я просто привёл пример того, что даже мелочь может привести к тому, что мы у себя между собой называем "multiple concurrent tasks", имея в виду именно сабж этой темы.
Даже мелочь к этому может привести, и это плохо. Наши американские манагеры никак до этого не допрут. И мне кажется им просто нравится прочесс "все в срачке" - когда все бегают как с загаженными штанами с криками "гипс снимают, клиент уезджает!"... Так что паралельные таски это самый крайний случай и должны применяться как можно реже вообще в принципе в любом случае. Один человек не должен правой ногой красить забор а левой рукой готовить суп. |
|||
|
||||
Wowa |
|
|||
Эксперт Профиль Группа: Админ Сообщений: 15017 Регистрация: 14.9.2000 Где: Винград Репутация: нет Всего: 290 |
||||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: нет Всего: 151 |
Структура папок одинаковая, при сборке преимущество имеют файлы кастомизаций. Т.е. файлы core заменяются одноименными файлами кастомизации, если таковые существуют. Перенос кастомизаций на следующую версию ядра производится при участии всех команд custom-проектов. Процедура мёржа, как правило, тривиальна. -------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
bagira |
|
|||
Эксперт Профиль Группа: Экс. модератор Сообщений: 2858 Регистрация: 25.10.2003 Где: в тайге Уральских гор Репутация: нет Всего: 123 |
Ой. У меня постоянно примерно 5-6 задач... И все срочные! Сейчас вот 3, но это временное явление Одной никогда не бывало, я это даже представить не могу... -------------------- Сегодня ты не бродил, не искал, не любил - можно сказать - и не жил... Ф.Х. Дагларджа (Турция) http://zveriolginovour.ru/ https://vmeste.yandex.ru/zveriolginovour |
|||
|
||||
unicuum |
|
|||
Опытный Профиль Группа: Участник Сообщений: 830 Регистрация: 16.3.2005 Где: Рашка Репутация: 1 Всего: 8 |
Всё это ерунда, что одна задача, что десять. Просто некоторые люди неспособны выполнить даже одну. Но кое в чём я согласен. Как говорил учитель, три дня без программирования и жизнь теряет смысл (молчаливая пустота).
-------------------- обычный день на винграде |
|||
|
||||
|
НА ЗЛОБУ ДНЯ: Дорогие посетители, прошу обратить внимание на то, что новые темы, касающиеся новых вопросов, создаются кнопкой "Новая тема", а не "Ответить"! Любые оффтопиковые вопросы, заданные в текущих темах, будут удалены. Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, arilou. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | УП: Человеческий фактор | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |