Программист в большой компании

Дмитрий Долгов
Родился в 1973 году. Окончил Санкт-Петербургский Государственный Технический Университет (бывший Политехнический Институт) по специальности "Прикладная математика". Более 8 лет проработал в CREAT Studio, где занимал пост главного программиста и начальника отдела программирования. Участвовал в выпуске игр для PC, Playstation 2, Xbox и Dreamcast. В настоящее время работает в отделе игровых и мультимедийных продуктов фирмы "1С".

Последние 9 лет я посвятил индустрии разработки компьютерных игр, пройдя путь от младшего программиста до начальника отдела программирования крупной компании. И большую часть этого времени сталкивался с проблемой поиска квалифицированных кадров. Я публиковал информацию о вакансиях, изучал присылаемые резюме, проводил собеседования и принимал новых программистов на работу.

Одной из основных проблем, возникающих в процессе работы, стала проблема интеграции новых молодых специалистов в команду при практически полном отсутствии у них информации о правилах и принципах коллективной разработки программного обеспечения.

Перейдя на работу в фирму "1С", я понял, что со схожими проблемами сталкиваются все, кто принимает на работу новых программистов - студентов или недавних выпускников ВУЗов. Если же речь идет о команде, которая целиком составлена только из молодых специалистов, последствия могут быть просто фатальными. Уже неоднократно приходилось проводить "экспресс-курсы" для молодых команд-разработчиков. Причем тот хаос, который творится в отделе программирования, часто пытаются выдавать за "нормальный рабочий процесс", хотя он на самом деле вызван отсутствием базовых знаний по методологии программирования.

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

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

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

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

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

Если свести вместе все основные отличия лабораторных и коммерческих работ, получим следующую картину:

Лабораторная работа

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

Коммерческая программа

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

Попробую кратко изложить идеи, которые несколько лет назад стали толчком к активному развитию методологических направлений на кафедре "Прикладная Математика" Санкт-Петербургского Государственного Технического Университета (бывшего Политехнического института).

11 лет назад, будучи студентом третьего курса, я впервые столкнулся с работой в большой компании. Японская фирма "Integra" начала разработку нового программного обеспечения, и часть работы была заказана специалистам из Польши и России (Москвы, Петербурга и Новосибирска). Разработку одного из графических модулей поручили мне. Задача заключалась в генерации списков пространственных вокселей, которые полностью или частично лежат внутри произвольно ориентированной пирамиды зрения.

Несколько дней я изучал очень жесткие стандарты кодирования фирмы "Integra". Затем неделя ушла на обсуждение с заказчиками внешнего программного интерфейса, которым должен был обладать новый модуль. Потом мы долго обсуждали возможные алгоритмы реализации и делали тесты на производительность. И только после этого я приступил к кодированию.

Смысл еще одного аспекта проводимой работы мне был тогда совершенно непонятен. За соседний компьютер посадили моего коллегу, который занялся реализацией альтернативного алгоритма. Его задача была проще - надо было написать самый простой, медленный, но надежный алгоритм генерации списков вокселей. Затем он подключил мой вариант библиотеки и начал запускать программу, сравнивая получаемые результаты. По условиям технического задания, быстрый алгоритм не имел права пропускать какие-то актуальные вокселы, но мог допускать не более 2% ложных (не принадлежащих пирамиде видимости) вокселей. Таким образом, надежный алгоритм генерации списков помогал тестировать мою версию.

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

Выводы:

• Несколько людей могут совместно разрабатывать программное обеспечение, при этом расстояние между ними не является критичным фактором;
• Независимо от используемых методик программирования, обязательно должны существовать этапы постановки технического задания, проектирования, полноценного тестирования, документирования работы и code review;
• Распределенная разработка программного обеспечения имеет свои достоинства. Как минимум, она предполагает активный обмен документацией и тем самым позволяет достаточно быстро и безболезненно передавать разработку из одних рук в другие;
• К сожалению, распределенная разработка, подробное документирование и тестирование каждого модуля занимают дополнительное время;
• Аналогов проделанной работе в учебной программе ВУЗа (на тот момент времени) не существовало.

После окончания института эти выводы легли в основу новых лабораторных занятий по предмету "Технология программирования" для студентов четвертого курса. Основные задачи в этом курсе сводились к следующему:

• Студенты получали техническое задание на разработку небольшой библиотеки классов, которая должна была быть впоследствии "встроена" в большую программную систему;
• Разработка этой библиотеки классов включала в себя обязательный предварительный этап составления спецификации и обсуждения;
• Студент должен был разработать библиотеку классов и набор вспомогательных функций, которые, с одной стороны, предназначены для тестирования этих классов, а с другой - являются примерами, как можно использовать данную библиотеку в своем проекте. Особое внимание уделялось читабельности и стабильности кода, а также документации;
• Финальная сдача работы сопровождалась code review и дополнительным тестированием библиотеки со стороны преподавателя.

Фактически этот лабораторный курс был попыткой сымитировать работу в большой компании или работу "на заказ" для большого проекта в рамках обычных студенческих лабораторных работ - аналогично тому, как велась работа для компании "Integra". Были получены следующие результаты:

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

Кроме непосредственного теоретического и практического курса по технологии программирования, некоторые элементы методологии также включаются в программы других учебных курсов, начиная с самого первого семестра. Вот основные разделы, базовая информация по которым должна быть представлена в учебных программах:

1. Стиль программирования, комментарии, самодокументируемый код. Лекции рекомендуется проводить на первом курсе вместе с лекциями, посвященными любому из языков программирования. Две лекции по этой теме, проведенные на первом курсе в качестве эксперимента (при условии постоянного контроля на практических занятиях), привели к тому, что у всех студентов в течение нескольких недель сформировался грамотный и красивый "почерк" при написании программ для лабораторных работ.

2. Методики программирования, на примерах самых различных моделей жизненного цикла - от каскадной модели до экстремального программирования. Теоретический материал для студентов 3-5 курса. Вопросы его поддержки в лабораторном практикуме к настоящему моменту еще не рассматривались.

3. Принципы создания небольших компонент в рамках большого продукта. Может сопровождаться лабораторными работами по разработке COM-объектов и другими аналогичными задачами.

4. Архитектура программного обеспечения. Функциональная и структурная декомпозиция, принципы сокрытия информации и т.п. Базовые знания о правильном построении структуры программы должны даваться уже на первом курсе при изучении языков программирования. Более глубоко вопрос можно прорабатывать вместе с "Принципами создания небольших компонент".

5. Методология ошибок. Классификация, симптомы, методы поиска и предотвращения. Часть этой информации должна проходить красной нитью через многочисленные существующие курсы (начиная с самого первого семестра). Как отдельный предмет (или как набор систематизирующих и обобщающих лекций) может включаться в программу 3 или 4 курса.

6. Работа с системами контроля версий. Материал для студентов 3-4 курсов. Должен включать в себя рассмотрение наиболее распространенных систем (например, VSS, CVS, SVN), информацию о порядке работы с ветками (branches), метками (labels), списками изменений (changeset) и т.п. Нерешенный вопрос - как организовать лабораторный практикум по этой теме?

7. Начальные сведения об управлении программными проектами. Предположительно, материал для студентов пятого или шестого курсов, обучающихся по магистерской программе. Можно рассматривать этот материал как логическое продолжение курса, посвященного методикам программирования (пункт 2).

Как я уже сказал, одним из ключевых вопросов по многим обозначенным направлениям остается вопрос лабораторного практикума для этого курса. В настоящее время рассматриваются различные новые варианты, например, проведение лабораторных работ, при котором каждый из студентов после разработки программы отдает ее на code review своим товарищам, и они пытаются проанализировать этот код на наличие ошибок, на читабельность и стилистику. Финальный code review осуществляется преподавателем и сравнивается со всеми остальными. Такой подход можно применять как на лабораторных работах по методологии программирования, так и в работах по другим предметам. Однако этот подход существенно увеличивает нагрузку, которая ложится на преподавателя.

К сожалению, имеет место и тенденция к автоматизации процесса обучения (студент написал лабораторную работу - запустил - получил ответ - записал его в поле ввода в автоматической экзаменационной программе - получил зачет). Такая автоматизация исключает этап методологического осмысления программы и никоим образом не формирует у студентов правильную стилистику и структуру кода.

И последнее. Я ни в коем случае не хочу, чтобы у вас сложилось мнение, что вопросам технологии программирования не уделяется внимания. Это не так. Во многих ВУЗах поставлены хорошие лекционные курсы. Но, судя по качествам молодых специалистов, они не поддержаны лабораторными или практическими занятиями, дающими навыки коллективной работы над большими проектами. На это следует обратить особое внимание.