Програміст
Дмитро Долгов
Народився в 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 здійснюється викладачем і порівнюється зі всіма іншими. Такий підхід можна застосовувати як на лабораторних роботах за методологією програмування, так і в роботах по інших предметах. Проте цей підхід істотно збільшує навантаження, яке лягає на викладача.
На жаль, має місце і тенденція до автоматизації процесу навчання (студент написав лабораторну роботу - запустив - отримав відповідь - записав його в полі введення в автоматичній екзаменаційній програмі - отримав залік). Така автоматизація виключає етап методологічного осмислення програми і жодним чином не формує у студентів правильну стилістику і структуру коду.
І останнє. Я у жодному випадку не хочу, щоб у вас склалася думка, що питанням технології програмування не приділяється уваги. Це не так. У багатьох Вузах поставлені хороші лекційні курси. Але, судячи по якостях молодих фахівців, вони не підтримані лабораторними або практичними заняттями, що дають навики колективної роботи над великими проектами. На це слід звернути особливу увагу.
