| Россия, г. Оренбург |
Опубликован: 23.10.2005 | Уровень: специалист | Доступ: платный
Лекция 11:
Обучение методу
Аннотация: Заканчивая наше изучение методологических проблем, обратимся к одному из принципиальных вопросов, стоящих перед компаниями и университетами: как лучше учить тех, кто должен применять объектные технологии. Эта лекция представляет принципы обучения и отмечает типичные ошибки.
В первой части проблема рассматривается с точки зрения лица, организующего профессиональную подготовку в компании, во второй - с позиций профессора университета. Несмотря на то, что речь пойдет о педагогических проблемах профессиональной подготовки, обсуждение касается и тех, кто не занимает указанных позиций и является скорее обучаемым, чем обучающим.
Ключевые слова: ПО, объект, класс, полиморфизм, наследование, динамическое связывание, жизненный цикл проекта, жизненный цикл, создание строки, числитель, значимость, инструментарий, algol-like, верификации программы, VDM, формализм, прогрессирующее, архитектура компьютера, статическая типизация, примитивный тип данных, Hashtable, согласованный базис, computational science, department, FORTRAN, COBOL, RPG, прецедент, undergraduate, study, вариант цикла, управление проектом, представление знаний, параллельное вычисление, формальная спецификация, управление конфигурацией, curriculum, черный ящик, рейтинг, лексический анализ, lexing, YACC, VLSI, CAD, работ, мультимедиа, Pascal, MIT, tools
Профессиональная подготовка (тренинг) в индустрии
Давайте начнем с нескольких общих наблюдений по поводу обучения объектным технологиям профессионалов, уже освоивших другие подходы. Обучение может вестись либо на семинарах, либо согласно внутреннему плану переподготовки, разработанному в компании.
Парадоксально, но задача тренера теперь может быть труднее, чем в середине восьмидесятых, когда к этому методу было привлечено широкое внимание. Тогда он был нов для большинства людей и имел ауру еретика, что всегда привлекает слушателей. Сегодня никто не будет шокирован, если кто-то заявит о своем пристрастии к ОО-методу. От постоянного упоминания в компьютерной прессе - ОО это и ОО то - возник своего рода шумовой эффект, называемый mOOzak. Слова объект, класс, полиморфизм от частого употребления становятся затертыми, они кажутся знакомыми, но широко ли понимаются стоящие за ними концепции? Зачастую нет! Это накладывает на тренера новую ношу - объяснить обучаемым, что они знают не все. Невозможно научить чему-либо человека, если он думает, что он уже это знает.
Единственная стратегия, гарантирующая преодоление этой проблемы, состоит в следующем:
|
Начальный тренинг: стратегия "пройди его дважды"
|
Выполнение этапа T3 кажется странным: применив ОО-метод в реальной разработке, снова слушать тот же курс. Компаниям, занимающимся ОО-обучением, не всегда удается применять эту стратегию, так как она выглядит подозрительно - вам дважды предлагают продать одну и ту же вещь. Но здесь обмана нет.
Понимание концепций по-настоящему приходит во время второй итерации. Хотя первая необходима для обеспечения основы, она не может быть полностью эффективной частично из-за эффекта mOOzak, частично из-за сложностей умозрительного восприятия концепций. Только тогда, когда слушатели сталкиваются день изо дня с ежедневными выборами ОО-конструирования - Нужен ли новый класс для этого понятия? Подходит ли здесь наследование? Следует ли ввести из-за этих двух компонентов новый узел в структуре наследования? Соответствует ли образец из курса моей ситуации? - только после этого они получают необходимую подготовку для правильного восприятия курса. Вторая сессия не будет, конечно же, идентична первой (по крайней мере, вопросы аудитории станут интереснее), она скорее находится на границе между тренингом и консультацией, но она действительно должна представлять вторую итерацию того же основного материала, ни в коей мере не являясь углубленным курсом, следующим за начальным.
|
На практике только наиболее просвещенные компании готовы принять эту стратегию, другие ссылаются на нехватку ресурсов. По моему опыту результат настолько хорош, что заслуживает чрезвычайных усилий. Стратегия является наилучшей из всех мне известных для обучения разработчиков для настоящего понимания ОО-технологии, чтобы они могли эффективно применять ее в интересах компании. |
Следующий принцип говорит о тематике обучения:
|
Принцип Темы Тренинга В начальном курсе в особенности сфокусируйтесь на реализации и проектировании. |
Некоторые полагают, что курс должен начинаться с ОО-анализа. Это грубая ошибка. Понимание ОО-анализа не может придти к новичку в ОО-технологии (разве только в смысле шумового эффекта mOOzak). Для овладения анализом необходимо изучить фундаментальные понятия: класс, контракты, скрытие информации, наследование, полиморфизм, динамическое связывание и тому подобное. Вначале все нужно делать на уровне реализации, где эти понятия непосредственно применяются. Следует практически построить несколько ОО-систем, вначале небольших, а затем наращивать их размер. Все проекты следует довести до завершения. Только после такой схватки врукопашную можно переходить к задаче ОО-анализа и пониманию ее роли в бесшовном процессе ОО-конструирования ПО.
Еще два принципа. Во-первых, не ограничивайтесь вводными курсами:
|
Принцип углубленной учебной программы По меньшей мере 50% бюджета тренинга должно быть резервировано для невводных курсов. |
Наконец, следует учить не только разработчиков:
|
Принцип Тренинга Менеджеров Программа тренинга должна включать курсы для менеджеров, также как и для разработчиков. |
Для компании, адаптирующей ОО-технологию, нереально надеяться на успех, обучая только разработчиков. Менеджеры, независимо от уровня их технической подготовки, должны быть знакомы с основными ОО-идеями, уметь оценивать их влияние на распределение задач, организацию команды, жизненный цикл проекта, экономику разработки ПО. Жизненный цикл обсуждается в следующей лекции (основательно в книгах, ориентированных на менеджеров, таких как [Goldberg 1995], [Baudoin 1996] и [M 1995]).
