Автор: Пользователь скрыл имя, 13 Февраля 2012 в 14:40, статья
Время, когда один программист мог создать полноценный программный продукт, безвозвратно уходит. Требования к качеству разрабатываемого ПО постоянно растут и сейчас уже в большинстве случаев никому не нужна программа без красивого графического интерфейса, документации, официального сайта и службы поддержки.
Коллективное
программирование: достоинства
и недостатки.
«Как
правило, знание создается
общими усилиями, благодаря
слаженным действиям
группы людей, направленным
на достижение общей
цели, или же благодаря
тем проблемам и диалогам,
которые порождаются
различием их точек
зрения» - Габриэль Саломон.
Время,
когда один программист мог создать
полноценный программный
Команда – это гораздо больше, чем просто группа людей. Команда – единое целое и она должна состоять из людей, обладающих необходимыми знаниями и навыками, объединенных одной общей целью. Для эффективной команды важны хорошие командные игроки, а не индивидуалы-суперзвезды. Владение кодом может быть разное: либо все делают все и каждый берет на себя ответственность за проект, либо каждый владеет только отдельным участком кода. В первом случае работа в команде подразумевает существование руководителя – единственного лидера группы, который пользуется уважением и показывает пример участникам команды. Его задачи – осуществлять контроль, принимать ключевые для проекта решения. Члены команды работают над общей задачей, ищут пути ее решения. Каждый добросовестный игрок несет личную ответственность за код программы и считает целесообразным находить и отстаивать лучшие решения проблем. Так между программистами могут возникать споры, а, как известно, в споре рождается истина. Во втором случае члены команды обычно являются специалистами узкого профиля и владеют только отдельным куском кода, они могут и понятия не иметь, что творится в коде его коллег. Такое владение кодом характерно для экстремального программирования (eXtreme Programming, XP). В экстремальном программировании над одной частью программы работают как минимум два специалиста, такая работа вдвоем называется парным программированием. XP совмещает две методики: коллективное владение и программирование парами. Парное программирование – весь код пишут два программиста, работающие за одним компьютером. При этом один сидит за клавиатурой и думает о том, как прямо сейчас реализовать определенный метод, а второй следит за его работой и думает стратегически: станет ли этот способ самым простым и эффективным, не заведет ли он в тупик и так далее. Партнеры меняются ролями, состав пар также динамичен. Так к концу проекта можно побывать в паре со всеми участниками команды. Коллективное владение – метод программирования, при котором любой член команды в любое время может внести изменения в любой кусок кода. В XP ответственность за весь код системы лежит на всех членах команды. И каждый, кто видит, что код можно упростить делает это немедленно.
Программирование парами является распространенной методикой, широко используемой не только командами экстремального программирования. Парная технология на сегодняшний день является одной из наиболее эффективных [1]. За последнее время, этот метод получил немало лестных отзывов, однако скептические отношения тоже имеют место быть. Существует мнение [2], что парное программирование слишком затратное как по времени, так и с финансовой точки зрения, что незачем двум специалистам поручать работу одного. Однако некоторые исследования показали [1], что и затраты, и время увеличиваются на 15%, а полученный в результате программный продукт имеет улучшенный дизайн, более компактный код, меньшее количество ошибок (согласно исследованиям, количество ошибок уменьшается на 15%). Этот уровень качества окупает все первоначальные затраты, благодаря их снижению при отладке программ. Для больших компаний затраты на исправление ошибок достаточно велики, поэтому много дефектов приносят огромные затраты. Так. Например, фирма Intel потратила 475 миллионов долларов, чтобы заменить чипы в процессорах Pentium, запущенных в производство, но урон репутации Intel уже был нанесен [3]. IBM сообщает [1,4], что потратили около 250 миллионов долларов только на устранение 30 000 проблем, о которых заявили их клиенты, то есть одна ошибка обошлась им в 8 000 долларов! Для определения насколько программирование парами оказывается эффективно, проведем некоторые вычисления. Итак, поставим перед собой задачу определить время написания программы, состоящей из 10 000 сток кода, количество ошибок и время на их исправление, в условиях работы программиста-одиночки и пары программистов. Для решения будем использовать известные статистические данные: типичная скорость разработки у одиночки – 50 строк в час; программист совершает 100 ошибок на 1000 строк кода; в процессе разработки программист выявляет около 70% этих ошибок. А также применим вышеупомянутые данные для метода работы в паре: время, затраченное на написание кода, увеличивается на 15%; количество ошибок уменьшается на 15%. Таким образом, один специалист напишет код за 200 часов, совершив при этом 300 ошибок, пара – за 230 при 255 ошибок. Мы видим, что в отличии от одиночного, парное программирование увеличивает время разработки на 30 часов, при этом имеем ошибок на 45 меньше. После написания программный продукт либо отправляется в отдел контроля качества, где проходит тестирование, либо непосредственно отправляется в эксплуатацию. В первом случае, согласно данным статистики [1], на исправление одной ошибки уходит от 4 до 16, во втором – от 33 до 88 часов. Для удобства используем средние величины – 10 и 60 часов соответственно. Получаем, что при исправлении 45 дополнительных ошибок одного разработчика во время тестирования уйдет 450 часов, что в 15 раз больше первоначального увеличения затрат по времени! В другом случае эти ошибки займут 2700 часов, что превышает первоначальные затраты в 60 раз!
На примере задачи становится ясна экономическая обоснованность коллективного программирования. Мы использовали тот факт, что число ошибок снижается на 15%, а так же было упомянуто об улучшении качества разрабатываемого ПО. Но за счет чего это происходит? Это возможно благодаря непрерывной проверке кода. В парной технологии она осуществляется, когда один программист пишет код, а другой следит за ним, отслеживает ошибки и указывает на их наличие. Работая в одиночку, человек может проигнорировать некоторые общепринятые нормы, просто из-за невнимательности, либо же ради экономии времени и сил. Однако, ощущая наблюдение за своей работой, программист вряд ли станет что-то нарушать. Ведь он понимает, что это будет замечено и исправлено, а перед партнером может стать неловко. Коллективное программирование предусматривает постоянную проверку кода членами команды. Так просматривая код, программист отлаживает и упрощает его. Зная, что кто-то из вашей команды будет в ближайшее время просматривать код, который вы сейчас пишете, вы несколько раз подумаете, прежде чем внедрить сложный код. Это еще одна особенность коллективного программирования – сложный код в программе не уживается. Из-за непрерывной проверки, код постоянно упрощается, становится короче, благодаря чему дизайн системы совершенствуется (как известно, чем короче программа, тем лучше ее дизайн). Непрерывная проверка кода обеспечивает меньший коэффициент ошибок. Кроме того, в рамках коллективного программирования в большей степени соблюдаются стандарты кодирования, за счет чего уменьшаются трения между разработчиками. Уже никто из программистов не скажет, что его код с лишком «индивидуален», код будет понятен и другим программистам, так как работа осуществляется в рамках простого дизайна, согласно стандартам кодирования.
Команда программистов должна находиться в одной комнате. Все члены команды различны по своим способностям, умениям, навыкам и квалификации. Важно, что новички будут работать рядом со специалистами. Такая обстановка очень благоприятна для обучения. Но, например, парное программирование – это все-таки не сеанс обучения. Если опытный программист работает в паре с начинающим, он обучает его посредством ответов на его вопросы, однако эти вопросы обычно помогают первому больше вникнуть в смысл написанного и обнаружить ошибки на ранних стадиях. Обычно через пару месяцев разрыв между двумя такими программистами почти не ощущается. Коллективное программирование предусматривает, что все делаю все, ответственность за проект лежит на каждом, поэтому идеи свободно высказываются, обсуждаются, что положительно влияет на опыт каждого. Можно сказать, любой, даже самый неопытный, программист знает что-то, чего не знают другие и готов этим делиться с командой. Возьмем, к примеру, экстремальное программирование: Кент Бек, автор книги «Extreme Programming», сравнивает распространение знаний в такой команде с миской воды, в которую бросили кусочек краски. Так, один человек, узнав что-то новое, обязательно расскажет об этом своему партнеру, потом уже они оба будут рассказывать об этом своим новым партнерам, а они следующим и так далее, пока об этом не будет знать вся команда. Так и кусочек краски постепенно окрасит всю воду в миске.
Теперь вернемся к парному программированию и рассмотрим еще одно важное его достоинство. Когда над одной задачей работает два человека, это снижает риск, связанный с изменением в составе персонала. Так, если один из разработчиков заболеет, уйдет в отпуск или вовсе уволится, это, хотя и подорвет работу проекта, но все-таки не разрушит его вовсе.
Обычно команды хорошо дисциплинированы, потому что их организация и распределение должностей, зависимость выполнения работы от каждого члена коллектива не позволяет нарушать дисциплину, например, устраивать длинные перерывы или задерживаться после работы. Кроме того, поздний уход с работы во многих западных фирмах расценивается, как неумение организовать рабочее время и справится с заданием. Поэтому предусмотрен нормированный рабочий день. Работоспособность работы команды повышается при совпадении биоритмов ее участников.
Выше были рассмотрены преимущественно достоинства коллективного программирования, однако его природа достаточно противоречива. Вообще, не просто организовать эффективную команду. Ведь все люди разные, со своими особенностями общения и характера. Одним программистам нравится коллективная работа из-за ее коммуникабельности. Они так же утверждают, что приобретают уверенность в том, что они делают. Другие приемлют только индивидуальную работу. Вся наша система образования основана на индивидуальном продвижении вперед: учитель ругает тех, кто с кем-то советуется во время работы и поощряет самостоятельную работу; так же и по карьерной лестнице обычно движутся одиночки. Однако в коллективном программировании нужно ощущать себя именно частью команды. Среди программистов нередко встречаются замкнутые необщительные люди, которым сложно в коллективе. Но сложно может быть любому: не всегда людям удается ужиться вместе, преодолеть эмоции, не просто заслужить уважение, которое так необходимо для отличной команды, и проникнуться им к своим коллегам. Такой психологический фактор является далеко не второстепенным в командной работе, ведь прежде чем начать работу, нужно собрать команду, способную ее выполнить.
Для команды важно выполнять то, что надо и то, что будет проще и короче. Поэтому для некоторых программистов это может стать проблемой, в связи с малой вероятностью воплощения своих творческих идей.
Сделаем
некоторое обобщение по характеристикам
коллективного
Достоинства:
Недостатки:
По итогам данной статьи можно сделать некий вывод: коллективное программирование оказывается эффективнее одиночного, все достоинства с лихвой покрывают недостатки. Однако сколько нас, столько разных мнений, возможно, кто-то более знакомый с таким явлением и испытавший его на личном опыте опровергнет такую точку зрения дополнительными доводами против. А возможно, прав окажется и тот, кто скажет: «Самое главное – цель, а не средства ее реализации». Но не стоит забывать, что свои плюсы и минусы есть во всем. Каждый выберет то, что ему важнее: пользоваться коллективным программированием ради получения вышеперечисленных достоинств, либо нет, чтобы не ощущать упомянутых недостатков.
Список используемой литературы: