Человеческий фактор в программировании
Шрифт:
Более десяти лет я занимался тем, что обучал людей одним из самых трудных и сложных межличностных и когнитивных навыков — пониманию семей как работающих систем и оказанию помощи тем семьям, которые работали недостаточно хорошо (Constantine, 1986 [10]). Поэтому я знаю, что людям действительно можно помочь изменить их взгляды на окружающий мир и понимание этого мира. На современном жаргоне это называется «сдвигом парадигмы». Однако это происходит не за час, и даже не за день.
В чем же суть всей этой мультисенсорности и мультимодалыгости? Существуют различные стили обучения. Одни люди лучше обучаются через прослушивание, другие — через чтение, третьи — через просмотр.
Какая-то информация запоминается легче и на более длительное время. Запахи могут оставлять в памяти очень долговременные следы даже после однократного вдыхания. Пространственно-моторное запоминание, то есть память о выполненных движениях и действиях, не просто долговечна — она может способствовать вспоминанию мыслей и ощущений, связанных с движениями. Физическое обращение с предметами, манипулирование материалами, которые ясно представляют некоторые идеи, помогает закрепить понятия — при условии, что физические манипуляции непосредственно с ними связаны.
Мультимодальная коммуникация не обязательно должна вовлекать сложные мультимедийные презентации. Например, во время дискуссии, проходившей на конференции в Лондоне, на вопрос о связи между повторным использованием и объектной технологией я не раздумывая ответил с помощью удерживания двух карандашей в виде буквы «L». Таким способом я хотел показать, что эти концепции — ортогональные, то есть не зависят друг от друга. Позже, уступая под градом острых вопросов, я признал взаимосвязь этих концепций. Объектная технология может способствовать более эффективному повторному использованию. Я составил из карандашей широкую букву «V», чтобы показать, что эти концепции связаны друг с другом. Два дня спустя участники конференции все еще обсуждали эту мини-демонстрацию.
Взаимосвязь между повторным использованием и объектной технологией продемонстрировать легко. Хорошая презентация, прежде всего, должна делать простые вещи простыми в изучении. Трудные вещи всегда будут трудными. Сколько бы систем восприятия вы не применяли, вы не сможете изучить объектно-ориентированное проектирование за один час так же, как не сможете изучить за час программирование. За это время вы сможете узнать только упрощенные — некоторые сказали бы «разбавленные» — варианты основных понятий.
Из журнала Software Development, том 1, № 11, ноябрь 1993 г.
29
Вверх по водопаду
Может ли роботам сниться электрическая овца? Преследуют ли менеджеров программных проектов кошмары о прыжках с водопада?
В традиционном виде цикл разработки программного обеспечения проходит через ряд последовательных этапов, начиная от определения требований, анализа, проектирования и заканчивая построением и тестированием. Высокоуровневое проектирование завершается до начала детального проектирования. Анализ задач и проектирование необходимо проводить до рассмотрения вопросов кодирования. Процесс разработки постепенно переходит с верхних уровней абстрагирования к низкоуровневым деталям, от общего и абстрактного к частному и конкретному.
Конечно, на самом деле так обычно не происходит. Так
Разработчики программного обеспечения и другие представители индустрии программирования отличаются тем, что они всегда бегут впереди себя. Едва увидев титульный лист спецификации, они тут же начинают придумывать код или дизайн интерфейса. Анализируя абстрактные сценарии использования, они уже представляют иконки для панели инструментов. При планировании связей между основными модулями они начинают придумывать оригинальные способы применения программного интерфейса.
Так обычно и происходит. По сути, эта зарисовка показывает, как обычные люди обычно решают задачи. В известном смысле они начинают работу с двух концов и двигаются к середине. Они мечутся между целями и средствами и перескакивают от высокоуровневой абстракции к низкоуровневым деталям и обратно.
Но разработчики не обязаны действовать таким образом. В больших и сложных проектах забегание вперед может создать реальные проблемы. В спешке вам и вашему руководителю трудно оценить длительность проекта. Слишком раннее рассмотрение деталей впоследствии может привести к необходимости их изменения, вызывая поток других переделок и исправлений. Кроме того, углубление в детали раньше времени может отвлечь внимание от основной работы.
Традиционно у разработчиков и руководителей проектов было две альтернативы, когда возникал этот импульс забежать вперед. В этом случае они могли либо поддерживать дисциплину и преодолеть этот порыв, либо поддаться ему, натворить дел, а потом опять вернуться на правильный путь. Любой путь связан с риском. Если продолжать работу над текущей задачей и не отвлекаться, то можно потерять или забыть важные и полезные идеи. Если вы всегда спешите и переключаетесь на детали, как только о них подумаете, то вы можете никогда не вернуться в основной поток. А если вернетесь, то можете не обнаружить основу вашего великолепного замысла.
В действительности нам нужна модель рабочего цикла, которая вбирает в себя преимущества всех способов мышления и действий. В то же время такая модель не должна позволять разработчикам становиться врагами самим себе. Сложность заключается в том, как, не нарушая хода решения текущей задачи, собрать достаточное количество информации, которая пригодится впоследствии.
Недавно мой шеф и я работали над дизайном пользовательского интерфейса к апплету для настольной системы. Мы старались действовать как дисциплинированные разработчики, применяя методичную стратегию проектирования интерфейса. Однако мы неоднократно спотыкались о собственное стремление забежать вперед. Мы постоянно обдумывали отличные идеи, связанные с деталями интерфейса и их особенностями. Это происходило в то время, когда нам нужно было заниматься определением абстрактных сценариев, описывающих потребности пользователей.