IZONE - http://www.izcity.com/ - бесплатный софт, вэб-сервисы, ресурсы для раскрутки, свежие номера журнала "Internet Zone".

 IZONE 


Microsoft изнутри

Дмитрий СЫТНИК

Уверен, что никакая другая компания не будоражит так сознание пользователей персоналок, как Microsoft. Многотысячная армия журналистов, издателей и авторов книг кормится за счет ее разработок. Сотни страниц исписано как о самой компании, так и о ее продуктах, продажи которых сейчас превышают объем экспорта многих государств! Возможно, за количеством не всегда стоит качество - любимая тема многих "компьютерных" разговоров. Редко встретишь такого юзера (особенно у нас), который не рад бы был разразиться жалобами и проклятиями при первом же упоминании о Microsoft. На самом деле, правда где-то посередине. Во всяком случае, ПК, на котором нет ни одного продукта от Microsoft - такая же редкость, как и искренняя любовь к Microsoft.

Во время разработки Windows'95 команда разработчиков этой системы включала в себя около 200 человек (сравните: над Windows 3.0 трудилось менее 60 человек). Всего же общий объем исходного текста Windows составлял более 13 миллионов строк, из них на комментарии приходилось примерно 1-2% исходного текста. Как тут не вспомнить бедных студентов КПИ, которых преподаватели заставляют отводить порядка 10-20% исходного текста на комментарии, дабы программа была достаточно читаема!
Вообще, Microsoft в течении всего своего существования придерживалась и придерживается принципа "оккамовой бритвы": максимум практичности и минимум лишнего. Куда там до читаемости кода! Тем более, что показывать его никому никто не собирается. Даже за деньги. Исходный текст Windows засекречен, и даже далеко не все разработчики системы имеют к нему полный доступ. Каждый сверчок знай свой шесток!
Всего к 1995 году количество сотрудников Microsoft превышало 20 тысяч. Сюда входило 1850 разработчиков, 1850 тестеров, 400 менеджеров по разработке и 2100 инженеров службы поддержки клиентов.
Весь процесс разработки делится на 4 фазы: планирование проекта, определение целей, приблизительного графика работ, определение общего состава команды разработчиков и разбиение ее на подгруппы.
Разработка проекта
Проект разрабатывается поэтапно; по завершении каждого этапа появляется так называемая промежуточная версия. Итак:
- стабилизация продукта, его тестирование, окончательная компиляция и выпуск pre-версии
- создание документации продукта, рекламирование продукта и выпуск финальной версии.
В процессе проектировки добавляется еще так называемое "буферное" время. Это время, отведенное на исправление всех непредвиденных проблем, возникающих в процессе разработки. Зачастую оно достигает 50% от общего времени разработки.
Только после этого продукт тестируют обычные пользователи. Но это еще не выход продукта. Часто бывает, что на этом этапе продукт заворачивают на дополнительную доработку.
В связи с тем, что все современные программы достаточно сложны, а требования к ним в условиях нынешнего рынка программных продуктов быстро изменяются, одним из основополагающих факторов успеха является скорость написания программы. Поэтому Microsoft использует труд мелких бригад разработчиков. Рабочая группа, работающая над одним проектом, разбивается на множество мелких бригад, занимающихся конкретно поставленной задачей. Бригада может даже состоять из одного единственного человека. К этим бригадам применяется жестко спланированный график работ. При этом, однако, каждый член имеет возможность самовыражения и внедрения своих новых идей. За счет всего этого достигается б(льшая гибкость продукта.
Когда команда разработчиков разрабатывает продукт, она создает его поэтапно. То есть, продукт не разрабатывается сразу с определенной спецификацией, а создается постепенно, мало-помалу обрастая новыми функциями. Это позволяет создавать множество промежуточных функциональных продуктов. Причем, "обезглючивание" производится на каждой стадии готовности продукта: версия предоставляется тестерам и аналитикам, которые высказывают свое мнение о продукте. Так обеспечивается "обратная связь" с рынком.
Естественно, основная проблема из тех, что возникают у разработчиков, - синхронизация работы над проектом, что особенно важно, когда количество бригад достаточно велико. Это достигается за счет разбиения спланированного времени разработки на так называемые контрольные точки, которые фиксируют текущее состояние: отстающие команды "подгоняют" свою работу под общую планку.
Кстати, сроки выхода продукта для менеджеров (и вообще для компании) важнее, нежели его "функциональность". Перед разработкой продукта всю команду знакомят со спецификацией, каковая всесторонне обсуждается. Если впоследствии будет грозить отставание от графика, то от тех функций, которые были запланированы в спецификации, но не были написаны, попросту отказываются. Естественно, основные функции пишутся в первую очередь, отказываются же в основном от "расширенных" функций, пользовательских удобств и от оптимизации продукта.
Иногда случается так, что в процессе разработки от продукта остается лишь половина, и то не вполне соответствующая описанию прототипов в спецификации. Может получиться даже немного иной продукт! Из-за постоянного изменения спецификации и изменения направления основных акцентов при разработке очередной версии продукта почти невозможно повторное использование написанного кода.
Одна бригада разработчиков состоит из менеджера по разработке продукта, четырех-десяти программистов и шести-десяти тестеров. Каждая бригада проводит проектирование, написание и тестирование функций, порученных главным менеджером проекта. Причем, всеми бригадами дается достаточно вольная трактовка изначальной спецификации. Если у кого-либо из программистов возникают новые идеи, то они обсуждаются в бригаде и вводятся в программу. Вольная трактовка только поощряется компанией.
Изменения спецификации часто производятся и самим руководством корпорации при очередном изменении стратегии компании. Правда, никто не ведет их учет - сказывается упомянутое правило Оккама. Единственным источником для понимания всех мелких изменений остаются исходники. Но и они очень скупо откомментированы. В итоге получается множество скрытых, недокументированных функций, в число которых входят и всякие вольности программистов вроде любимых всеми "пасхальных яиц". Во время разработки продукт имеет вид доступной всем командам базы данных, содержащей "контрольную" версию файлов с исходным кодом, которая у них называется Master Version. Процесс разработки продукта сводится к периодической генерации новой версии из частично или полностью готовых компонентов. Если компонент не дописан до конца, то используется предыдущая версия компонента. Весь этот процесс называется "сборкой" - Build. Помните на компактах с Windows приписки типа build 12 и пр.?
Каждый разработчик, приступая к работе, каждый день сначала "скачивает" необходимые ему для работы данные из общей базы (check out). После этого он приступает к написанию, отладке и всякой другой работе с его "участком кода". В любой момент разработчик может выполнить свою сборку продукта и сгенерировать свою версию продукта (private release). Все разработчики используют в качестве инструментария программы, разработанные самой же фирмой. Существуют и так называемые закрытые разработки, которые используются для создания других продуктов. Надо отметить, что инструментарий зачастую не меняется по несколько лет. Даже сейчас в компании хватает разработчиков, пользующихся инструментальными средствами еще 1993-1996 годов - тех, на которых разрабатывалась первая Windows 95. Предполагается, что обучение разработчиков новым методам разработки отнимает слишком много времени и денег, которые лучше потратить непосредственно на разработку нового продукта. Хотя, конечно, и в этой области компания предпринимает определенные действия, но довольно неохотно.
Большинство команд разработчиков физически сосредоточено в одном месте, а именно - в огромном корпоративном центре в Редмонде (мне это сооружение видится окруженным толпами разозленных пользователей, которые целыми днями бастуют и пикетируют). Все разработчики используют Си и Си++, что помогает параллельным группам при обсуждении новых решений находить общий язык. Каждый программист работает в паре со своим тестером, который тестирует все промежуточные и общие версии продукта. Это помогает действительно быстро находить ошибки на ранних стадиях. На этапе тестирования используют новые технологии вроде регрессионного тестирования, а также скрипты тестовых сценариев. Кроме своей прямой обязанности, тестировшик помогает программисту в процессе разработки. Раз в неделю разработчик должен встраивать свою часть кода в общую "эталонную версию" продукта. Затем он должен провести общую сборку. После этого производится всеобщий регрессионный тест, что позволяет быстро выловить основные ошибки к коде. Если обнаружена ошибка, то проект "замораживается", и тестировщиками производится его глобальный анализ. После этого ошибка исправляется разработчиками. Таким образом, "мастер-версия" продукта всегда функционирует без ошибок. Каждый разработчик, если у него готов его участок кода, должен успеть встроить свою часть в общий проект до определенного часа дня: каждый день в определенное время происходит запуск робота-сборщика (build engine), который, следуя определенным сценариям, генерирует рабочую "эталонную" версию продукта, а также все "заказанные" отдельными разработчиками измененные версии.
Надо отметить, что это вам не Hello World компилировать. Полная перекомпиляция серьезного продукта может занять часы. Причем, "эталонная" версия продукта компилируется сразу в несколько версий (PC и/или Mac; европейская, американская и азиатская).
После того как продукт получен, его предлагают протестировать потенциальным пользователям. Для этого выбирается около 100 человек из числа зарегистрированных тестеров, и они проводят тестирование продукта. Это обычные пользователи, зачастую не имеющие специального компьютерного образования. Затем они заполняют специальные анкеты, где отмечают множество факторов, таких как простота использования продукта, количество сбоев при выполнении конкретной процедуры, время, затраченное на достижение определенной цели, и многое другое. Естественно, тестируют они эти продукты не дома, а в офисе компании. Для максимального удобства компания создала целый комплекс - Microsoft Home, обустроенный так, чтобы каждый пользователь мог почувствовать себя "как дома" - для более точной передачи ощущений при работе с готовыми продуктами. Тесты производятся также и в некоторых университетах и компаниях - естественно, под четким надзором работников корпорации, следящих, чтобы продукт не украли. Впрочем, иногда это им не удается.
Все новые мелкие изменения вносятся в продукт в виде дополнительных модулей и заплат. Глобальная перекомпиляция производится при выявлении серьезных ошибок. Исправление ошибки или расширение внутренней возможности чаще всего производится так. Сначала производится фиксация ошибки. Затем определяется функция, ответственная за данную ошибку. Выясняется, что входит в функцию и что надо получить в результате. При исправлении функции производится отлов ситуаций, при которых функция не справляется с данными. Сообразно полученным результатам исходники исправляются с помощью конструкций:
rezult Func(;данные)
{
if(;эти данные1 вызывают ошибку)
{
;вычисляем то, что надо
return rezult;
}
else
if(;эти данные2 вызывают ошибку)
{
;вычисляем то, что надо
return rezult;
}
else
{
;а вот с этими данными справится и старый код
return rezult;
}
}
Таким образом разработчики обходятся без глубокого анализа правильности кода функции или ее алгоритма, а ограничиваются лишь исправлением конкретной ошибки. Конечно, так происходит не всегда, но все же достаточно часто, особенно в различных Servise Pack и Update (стоит, впрочем, отметить, что так поступает не одна Microsoft). Затем старая функция заменяется новой, иногда с использованием перекрывающих модулей. Все это, конечно, приводит к разбуханию кода и падению скорости. Для компании это ничего не значит - по сравнению со сроками выпуска продукта. После того как продукт прошел первичное тестирование, появляется бета-версия, которая рассылается партнерам корпорации, имеющим статус ISV и OEM. И только после этого компания выпускает финальный продукт. Причем, у корпорации есть определенный план, согласно которому каждые 12 месяцев должна появляться исправленная и дополненная версия, а каждые 24 - полностью переработанная и обновленная, с новой архитектурой. Подобный механизм по выбиванию денег из клиентов работает достаточно слаженно: вспомним office 95 - update - office 97 - osr version - office 2000 (вышла в 1999 году). Интересно, что работа службы обслуживания клиентов частично финансируется из бюджета команды разработчиков - таким образом у разработчиков стимулируется повышенное внимание к багам и глюкам своей программы. Следует отметить, что зарплаты у сотрудников отдела разработок динамичны и зависят от многих факторов. И все же, зарплаты здесь - одни из самых высоких. Мне довелось слышать, что каждый год в Microsoft появлется 4-5 новых миллионеров. Просто мафия какая-то!

Источник: http://www.mycomp.com.ua/

 


Copyright © "Internet Zone"info@izcity.com
Копирование и использование данных материалов разрешается только в случае указания на журнал "Internet Zone", как на источник получения информации. При этом во всех ссылках обязательно явное указание адреса вэб-сайта http://www.izcity.com/. При наличии у копируемого материала авторов и источника информации - их также нужно указывать, наряду со ссылкой на нас.